Re: [ViennaCL-devel] Benchmark GUI Midterm Report
Hi,
I merged Qt4 and Qt5 CMakeFiles into a single file. I've added a variable
lets you choose between using Qt5 and Qt4. I don't know if its a good
solution, but it seems to work well enough. I also tried enabling OpenCL in
both CMake and QMake builds, but that didn't go so well.
For QMake, I tried using OpenCL by hard coding the include and library
paths and setting QMAKE_CXXFLAGS += -DVIENNACL_WITH_OPENCL. That resulted
in 6 multiple definitions
of viennacl::linalg::double_float_conversion_program; a couple hundreds of
'Cannot get section contents - auto-import exception' (whatever that
meant); an undefined reference to 'clRetainCommandQueue@4'; and a bad reloc
address. I tried setting QMAKE_CXXFLAGS += -lOpenCL but that didn't do
anything.
For CMake, I use ViennaCL's FindOpenCL.cmake to find_package(OpenCL REQUIRED);
then include_directories(${OPENCL_INCLUDE_DIR}) and
link_directories(${OPENCL_LIBRARIES}); then set(CMAKE_CXX_FLAGS
${CMAKE_CXX_FLAGS} -DVIENNACL_WITH_OPENCL); and finally add
${OPENCL_LIBRARIES} to target_link_libraries. This resulted in 4
multiple definitions of
viennacl::linalg::double_float_conversion_program; and a mysterious
error - file not recognized: File format not recognized for
OpenCL.dll.
I don't know what else to try and could use some help.
Are you referring to a splash screen at startup? I've got a draft splash
screen somewhere, which I can adapt to the ViennaCL benchmark GUI. Totally
unimportant in terms of functionality, yet easy to integrate and provides
quite a professional touch.
Well, I imagined the home screen as a starting point for the
benchmark, the first thing you see when the program starts. A splash
screen on startup would be great. I'm thinking we might put some of
the following on it:
-it would be nice to show some system info on it, like hardware specs.
-show the user's benchmark highscore
-maybe show some info on ViennaCL (self marketing?).
I know it might not seem very appealing, but to me it feels like the
home screen could be a good addition. What's your take on this matter?
As for the meeting, I don't have any particular obligations next week,
so pretty much any time will do.
Oh, and one more thing. I revisited the Heisenbug (again). I found out
that the bug occurs only on CG solver (ILU0 preconditioner) via
ViennaCL, compressed_matrix part of the solver benchmark. Omitting
this test results in proper execution of the benchmark. Whether or not
this is a problem of matrix file reading I can't say. What concerns me
is that this bug might occur even when we start using on-the-fly data
generation. If that happens, I really don't know what to do.
Regards, Namik
On Wed, Jun 25, 2014 at 3:44 PM, Karl Rupp r...@iue.tuwien.ac.at wrote:
Hi,
This is a report on what was done so far, and what remains to be done on
the Benchmark GUI project.
Quick overview of what was done so far:
-all benchmarks implemented and runnable from the GUI
-result visualization of benchmarks
-UI menu and navigation
-CMake build system
Good, this is a solid foundation for the second half of GSoC. :-)
What remains to be done:
(I'll provide short comments on each of the items)
-use on-the-fly benchmark data generation (shipping and using separate
files is currently bugged for solver benchmark in Qt5 release mode, but
works in debug mode - the Heisenbug)
I can provide that soon.
-threaded benchmarks (waiting for the Heisenbug work-around)
Ideally gets fixed without dedicated coding for this one ;-)
-merge Qt4 and Qt5 CMake files into a single CMakeLists.txt file
Shouldn't be too hard - just the testing with multiple
installations/machines is a bit tedious.
-basic view (still trying to design a simple and appealing UI)
Suggestion: Focus on two quantities: GFLOP/sec for compute-limited
operations (matrix-matrix multiplications) and GB/sec for
memory-bandwidth-limited operations. Anything else can probably go into the
expert mode...
-expert view (gonna need some info on what to put into the expert view)
'Fundamental' quantities of interest:
GFLOP/sec over data size
GB/sec over data size
PCI-Express bandwidth
Latencies (OpenCL API, single byte transfers, etc.)
Compound operations like the QR factorization or the iterative solvers are
harder for users to comprehend, as they involve a combination of the
fundamental quantities above. Still, I think it's useful to have these as
experts can use these to derive estimates about how fast their machine will
perform for certain operations.
-benchmark execution animation (ready/running/finished)
Simple status updates should be sufficient (Running benchmark X of Y
total, estimated time remaining)
-user input of benchmark matrices (custom sizes, matrix market)
yes, this is super-handy :-)
-home screen design (thought it might be nice to have a home/welcome
screen, but have no idea what to put in it :D suggestions highly needed
on
Re: [ViennaCL-devel] Benchmark GUI Midterm Report
Hi, This is a report on what was done so far, and what remains to be done on the Benchmark GUI project. Quick overview of what was done so far: -all benchmarks implemented and runnable from the GUI -result visualization of benchmarks -UI menu and navigation -CMake build system Good, this is a solid foundation for the second half of GSoC. :-) What remains to be done: (I'll provide short comments on each of the items) -use on-the-fly benchmark data generation (shipping and using separate files is currently bugged for solver benchmark in Qt5 release mode, but works in debug mode - the Heisenbug) I can provide that soon. -threaded benchmarks (waiting for the Heisenbug work-around) Ideally gets fixed without dedicated coding for this one ;-) -merge Qt4 and Qt5 CMake files into a single CMakeLists.txt file Shouldn't be too hard - just the testing with multiple installations/machines is a bit tedious. -basic view (still trying to design a simple and appealing UI) Suggestion: Focus on two quantities: GFLOP/sec for compute-limited operations (matrix-matrix multiplications) and GB/sec for memory-bandwidth-limited operations. Anything else can probably go into the expert mode... -expert view (gonna need some info on what to put into the expert view) 'Fundamental' quantities of interest: GFLOP/sec over data size GB/sec over data size PCI-Express bandwidth Latencies (OpenCL API, single byte transfers, etc.) Compound operations like the QR factorization or the iterative solvers are harder for users to comprehend, as they involve a combination of the fundamental quantities above. Still, I think it's useful to have these as experts can use these to derive estimates about how fast their machine will perform for certain operations. -benchmark execution animation (ready/running/finished) Simple status updates should be sufficient (Running benchmark X of Y total, estimated time remaining) -user input of benchmark matrices (custom sizes, matrix market) yes, this is super-handy :-) -home screen design (thought it might be nice to have a home/welcome screen, but have no idea what to put in it :D suggestions highly needed on this one) Are you referring to a splash screen at startup? I've got a draft splash screen somewhere, which I can adapt to the ViennaCL benchmark GUI. Totally unimportant in terms of functionality, yet easy to integrate and provides quite a professional touch. -benchmark result upload (will use JSON format; Qt5 has native support for JSON, Qt4 will require a third-party library) I expect that it is sufficient to rely on Qt5 at this point and disable it for Qt4 builds. As our precompiled binaries will use Qt5, most users will have this piece of functionality available then. -additional features of my proposal: My Results and Online Result Database (My Results won't be a problem, Online Result Database could be tricky) This should have lower priority in favor of the issues above :-) -collecting sample results for comparison (first need to establish a formula for determining final benchmark score) For FLOPs and GB/sec this is fairly easily obtained from the usual consumer datasheets. -installer Yep, this is super-important for Windows-based users. That's all I can think of, hope I didn't miss anything. The UI development is going a bit slower than I anticipated. Styling and customizing Qt's widget behavior isn't very straight-forward. Until now, I've only dealt with stock widgets, so styling them is new to me (then again, lots of things are new to me in this project). So far I'm very satisfied with the development flow. My proposal's timeline was very loose, and the project is going ahead of schedule. I've pushed the initial design of UI menu to GitHub. From now on I'll be needing community feedback and suggestions on the design. Here's a quick screenshot for those who can't afford to build and run it on their machine: http://pokit.org/get/img/8b45999c8078fd263aad5f31a9f47154.jpg I like the sidebar on the left :-) My original design idea was to make a futuristic, Star Wars/Star Trek themed UI. Use the force, Namik ;-) Luckily, the Qt widgets weren't very co-operative. I say luckily because it would probably be very cheesy and highly inappropriate. So I decided on a more conventional UI. I must admit I did borrow some ideas from Qt Creator IDE (I really like Qt Creator). I think that's about enough typing for one email. :) Thanks! Best regards, Karli -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ ViennaCL-devel mailing list
