Thank you. That was incredibly informative. I'll think about it ways to
implement a benchmark as I continue my work in parallel.
On Sat, Aug 2, 2014 at 4:10 AM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
> Hi again,
>
>
> > As a follow-up to my earlier email, which is likely still sitting in the
>
>> queue do to its large size [sorry ;-) ], I wanted to ask a question
>> regarding the iterative solvers.
>>
>> Will the GUI support benchmarking the iterative solvers? I see they are
>> not part of an official benchmark. I would be happy to work on setting
>> that up and enhancing a version of the iterative.cpp tutorial to support
>> a benchmark reporting either elapsed time or GFLOPS, with the former
>> being trivial. We could easily normalize or convert the time to a score
>> if you want to go that route such that the > the number the better. The
>> majority of my ViennaCL interest is in solving Newton-Raphson problems
>> where the conjugate gradient solver is a great help to me. For selfish
>> reasons, bringing that to higher prominence through the public
>> benchmarks would be nice.
>>
>
> Namik set up a set of benchmarks for iterative solvers, but ultimately I
> asked him to suspend these for the time being. I try to summarize my
> rationale:
>
> * There are a bunch of variations possible: Which solver to use, which
> sparse matrix format to use, which preconditioner to use. Certain
> combinations do not make sense (such as running CG on a nonsymmetric
> system), but this is hard to detect automatically and would require a big
> share of effort.
>
> * SpMV: CG and BiCGStab are predominantly limited by the sparse
> matrix-vector product if there are more than ~10 entries per row and more
> than ~100k rows/columns in the matrix. Thus, we can already provide
> valuable information to the user by just providing benchmark results for
> the sparse matrix-vector product, for which we also have the
> download-option to the MatrixMarket.
>
> * uBLAS: Certain preconditioners in ViennaCL such as AMG and SPAI
> currently depend on uBLAS, which has turned out to be a terrible
> dependency. These preconditioners need to be altered first to work without
> uBLAS both for efficiency and portability reasons.
>
> * Timing: There are only a few more weeks in GSoC left, so we need to have
> a rounded package for a release soon. Although we all hope that Namik will
> continue working on the benchmark after GSoC, we need to get more user
> feedback by having a first decent release.
>
> In the long term I expect that the iterative solvers will make it again
> into the benchmark GUI and provide the possibility for the user to
> automatically determine the best choice of {solver, preconditioner, sparse
> matrix format}. My research work also involves the solution of sparse
> systems, so this part certainly won't be forgotten... :-)
>
> Do you have further ideas on how to set up a good benchmark for iterative
> solves? I guess you have already heard about the HPCG benchmark, which
> turned out to be quite a tricky beast to set up reasonably because
> ultimately iterative solvers ultimately end up being fairly
> problem-specific. We will certainly have to deal with such complexity and
> variations within a benchmark GUI....
>
> Best regards,
> Karli
>
>
>
>> On Fri, Aug 1, 2014 at 7:17 PM, Matthew Musto <matthew.mu...@gmail.com
>> <mailto:matthew.mu...@gmail.com>> wrote:
>>
>> Karli,
>>
>> Before I get into the latest CMake drama. I wanted to ask a
>> question about:
>>
>>
>> >> 1.) Boost: Namik, can you please remove all use of Boost
>> (sources plus
>> >> build system files)? This is just required at very few
>> locations, mostly
>> >> sparse stuff, so it shouldn't be a big deal. I'll commit some
>> matrix
>> >> generation code soon, which will allow us to get rid of all the
>> IO and
>> >> the testdata files, which is the primary use of Boost.
>>
>> Does that mean that boost's compressed_matrix will not be supported
>> by the gui benchmark algorithm? Should I be using ell_matrix
>> instead for my sparse matrices? I ask, because the focus of all of
>> my research and development is on sparse matrices and I have relied
>> heavily upon compressed_matrix up till now. Which is why I was so
>> distraught to find out at ublas will be broken in boost 1.56. But
>> that is a conversation for another day.
>>
>> Now onto CMake builds. Historically, I was apparently incorrectly
>> downloading the zip file and making my own folder structure.
>> Cloning makes things much much easier and allowed me to download
>> libarchive automatically. I realize zlib is not working yet, but I
>> thought I would send you my CMake output with a clean build
>> directory for your reference in case you see other issues.
>>
>> Thanks,
>> -Matt
>>
>> The C compiler identification is MSVC 18.0.30501.0
>>
>> The CXX compiler identification is MSVC 18.0.30501.0
>>
>> Check for working C compiler using: Visual Studio 12 2013 Win64
>>
>> Check for working C compiler using: Visual Studio 12 2013 Win64 --
>> works
>>
>> Detecting C compiler ABI info
>>
>> Detecting C compiler ABI info - done
>>
>> Check for working CXX compiler using: Visual Studio 12 2013 Win64
>>
>> Check for working CXX compiler using: Visual Studio 12 2013 Win64 --
>> works
>>
>> Detecting CXX compiler ABI info
>>
>> Detecting CXX compiler ABI info - done
>>
>> CMake Error at CMakeLists.txt:56 (add_subdirectory):
>> The source directory
>>
>> C:/viennacl-benchmark-gui-master/viennacl-benchmark-gui/external/zlib
>>
>>
>>
>> does not contain a CMakeLists.txt file.
>>
>> Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
>>
>> Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
>>
>> ...
>> removed a bunch of noise...
>> ...
>>
>>
>> Checking support for ARCHIVE_CRYPTO_SHA384_OPENSSL
>>
>> Checking support for ARCHIVE_CRYPTO_SHA384_OPENSSL -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_OPENSSL
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_OPENSSL -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_MD5_LIBMD
>>
>> Checking support for ARCHIVE_CRYPTO_MD5_LIBMD -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD
>>
>> Checking support for ARCHIVE_CRYPTO_RMD160_LIBMD -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD
>>
>> Checking support for ARCHIVE_CRYPTO_SHA1_LIBMD -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD
>>
>> Checking support for ARCHIVE_CRYPTO_SHA256_LIBMD -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_LIBMD -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_MD5_WIN
>>
>> Checking support for ARCHIVE_CRYPTO_MD5_WIN -- found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA1_WIN
>>
>> Checking support for ARCHIVE_CRYPTO_SHA1_WIN -- found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA256_WIN
>>
>> Checking support for ARCHIVE_CRYPTO_SHA256_WIN -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA384_WIN
>>
>> Checking support for ARCHIVE_CRYPTO_SHA384_WIN -- not found
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_WIN
>>
>> Checking support for ARCHIVE_CRYPTO_SHA512_WIN -- not found
>>
>> Generating
>> C:/viennacl-benchmark-gui-master/build/external/
>> libarchive/libarchive/test/list.h
>>
>> CMake Warning (dev) at external/libarchive/cat/CMakeLists.txt:29
>> (GET_TARGET_PROPERTY):
>> Policy CMP0026 is not set: Disallow use of the LOCATION target
>> property.
>> Run "cmake --help-policy CMP0026" for policy details. Use the
>> cmake_policy
>> command to set the policy and suppress this warning.
>>
>> The LOCATION property should not be read from target "bsdcat". Use the
>> target name directly with add_custom_command, or use the generator
>> expression $<TARGET_FILE>, as appropriate.
>>
>> This warning is for project developers. Use -Wno-dev to suppress it.
>>
>> Generating
>> C:/viennacl-benchmark-gui-master/build/external/
>> libarchive/cat/test/list.h
>>
>> CMake Warning (dev) at external/libarchive/tar/CMakeLists.txt:42
>> (GET_TARGET_PROPERTY):
>> Policy CMP0026 is not set: Disallow use of the LOCATION target
>> property.
>> Run "cmake --help-policy CMP0026" for policy details. Use the
>> cmake_policy
>> command to set the policy and suppress this warning.
>>
>> The LOCATION property should not be read from target "bsdtar". Use the
>> target name directly with add_custom_command, or use the generator
>> expression $<TARGET_FILE>, as appropriate.
>>
>> This warning is for project developers. Use -Wno-dev to suppress it.
>>
>> Generating
>> C:/viennacl-benchmark-gui-master/build/external/
>> libarchive/tar/test/list.h
>>
>> CMake Warning (dev) at external/libarchive/cpio/CMakeLists.txt:39
>> (GET_TARGET_PROPERTY):
>> Policy CMP0026 is not set: Disallow use of the LOCATION target
>> property.
>> Run "cmake --help-policy CMP0026" for policy details. Use the
>> cmake_policy
>> command to set the policy and suppress this warning.
>>
>> The LOCATION property should not be read from target "bsdcpio". Use
>> the
>> target name directly with add_custom_command, or use the generator
>> expression $<TARGET_FILE>, as appropriate.
>>
>> This warning is for project developers. Use -Wno-dev to suppress it.
>>
>> Generating
>> C:/viennacl-benchmark-gui-master/build/external/
>> libarchive/cpio/test/list.h
>>
>> Boost version: 1.54.0
>>
>> Found OPENCL: C:/Program Files (x86)/AMD APP
>> SDK/2.9/lib/x86_64/OpenCL.lib
>>
>> Configuring incomplete, errors occurred!
>>
>> See also
>> "C:/viennacl-benchmark-gui-master/build/CMakeFiles/CMakeOutput.log".
>>
>> See also
>> "C:/viennacl-benchmark-gui-master/build/CMakeFiles/CMakeError.log".
>>
>>
>>
>>
>>
>> On Fri, Aug 1, 2014 at 11:12 AM, Karl Rupp <r...@iue.tuwien.ac.at
>> <mailto:r...@iue.tuwien.ac.at>> wrote:
>>
>> Hi guys,
>>
>> okay, so the libarchive and zlib issues should be (mostly)
>> fixed. Both
>> can be linked statically. Namik just pushed a version which
>> allows to
>> also build it dynamically. Will this work sufficiently well? We
>> will
>> have to make sure Windows finds these dlls, which is
>> cumbersome... Any
>> ideas how to ensure this? Copying the .dll files to the .exe?
>>
>> There are three things left to make everything really smoothly:
>>
>> 1.) Boost: Namik, can you please remove all use of Boost
>> (sources plus
>> build system files)? This is just required at very few
>> locations, mostly
>> sparse stuff, so it shouldn't be a big deal. I'll commit some
>> matrix
>> generation code soon, which will allow us to get rid of all the
>> IO and
>> the testdata files, which is the primary use of Boost.
>>
>> 2.) viennacl/: I'll add viennacl-dev as a submodule in external/,
>> so
>> that a user does not have to specify the path manually with CMake.
>>
>> 3.) libarchive+zlib: It seems like in the current build setup
>> the zlib
>> is not enabled in libarchive, as it tries to run 'gzip' as a
>> fallback.
>> Namik, can you please have a look at that?
>>
>> I'll be online in our IRC channel during the next hours, so
>> let's get
>> this fixed quickly and enjoy a nice build system then :-)
>>
>> Best regards,
>> Karli
>>
>>
>>
>>
>>
>> (message truncated)
>>
>>
>
--
--------------------
Matthew Musto
matthew.mu...@gmail.com
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
