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)
>


------------------------------------------------------------------------------
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

Reply via email to