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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
