Hi Namik, thanks for the first prototype. As sending files around is rarely efficient, I created a repository for the GUI: https://github.com/viennacl/viennacl-benchmark-gui where you have push permissions. Please populate it with the necessary files (no auto-generated files, try to avoid dumping external dependencies and large binary files, document the build process, etc.).
Also, please consider an automated CMake build, as this makes dependency checks much easier as compared to manually editing Makefiles :-) I found a couple of relative paths in the Makefile, so I decided to postpone further attempts until the build process is improved and better documented. No worries, this is a normal thing to do in such an early stage of a project, yet it will save all of us a lot of time in the long run. Some comments on the points you raised: > -QML visualization: I used QChart.js > <http://jwintz.me/blog/2014/02/15/qchart-dot-js-qml-binding-for-chart-dot-js/> > which > implements Chart.js <http://www.chartjs.org/>. QChart.js is a QML > binding for Chart.js > -C++ visualization: I found a great plotting library QCustomPlot > <http://www.qcustomplot.com/> which not only offers large amounts of > plots and charts, but also has excellent documentation easily integrated > with QtCreator. Neat! :-) > On the C++ side, its as easy as adding qcustomplot.h and qcustomplot.cpp > to the project. > -Communication with C++ code > I've encountered a bug in Qt when using QCustomPlot. When using Qt<5, in > my case 4.8.5, everything work fine. But when using any Qt>=5 ( I tried > 5.0.2 and 5.2 ), I get a OpenGL compile error > in QtGui\qopenglversionfunctions.h . After looking it up, I found out it > was reported at https://github.com/go-qml/qml/issues/56 and currently > the best fix is to comment the whole trouble-making line 785 ( void > (QOPENGLF_APIENTRYP MemoryBarrier)(GLbitfield barriers); ). This bug was > supposedly fixed in Qt 5.2, but it seems it's still here. > After fixing this issue, everything worked perfectly and QCustomPlot > behaved like a normal Qt class. Okay, as long as we know how to address it and point users to it, this should be manageable. On the other hand, it shows that one should be careful with not adding too many external dependencies, as these kinds of issues scale up with the number of dependencies. > -Functionality: > QChart.js is very simple and not too rich with functionality. > QCustomPlot on the other hand is a beast of a library, with a ton of > features and options. In the long run it's probably better to stick with only one of the two, but let's first see which one provides better functionality. > -Licensing > QChart.js: MIT license > QCustomPlot: MIT license Good :-) > -Source code size > QChart.js: around 65 KB > QCustomPlot: whooping 884 KB I don't think this is significant, as the Qt dependency is much more heavyweight ;-) > Well, not that I've spent so much time exploring QML, its time to bring > out the dealbreaker. QChart.js does not support dynamic update of > charts. That means there's no changing the graph data once it's loaded, > so I had to do a dirty trick to make it work: delete the whole graph, > then repaint a new one with new data in its place. I can sya how much > will this affect performance, but I'm pretty sure it's not going to be > satisfactory. Well, QCustomPlot might as well just redraw the whole graph internally. We don't need 60 frames per second, so maybe it still fits our purposes. > TL:DR > My final verdict would be to play it safe, and go full C++. QCustomPlot > has fantastic features and awesome documentation, and it would be a > shame not to use it. > QML, on the other hand, does have some nice features, but it seems it's > not worth the trouble ( or I just picked the wrong javascript library ). Let's see how things develop... > P.S In viennacl/tools/sha1.hpp line 209: u_int32_t hash[5]; couldn't be > compiled on my MinGW 4.8 32bit and Windows 7 Ultimate 64bit. I changed > it to: uint32_t hash[5]; and it worked. It seems to be a bug in MinGW. As far as I can tell, u_int32_t is not defined in a Windows environment, whereas uint32_t is defined in C99 and available with Visual Studio 2010 and above. Apparently the SHA1 library Philippe added isn't as portable as we would like it to be, primarily because of some type deficiencies in older C and C++ standards. > Is it ok for me to continue using uint32_t ? They seem the same to me. Yes, this is okay. Consider pushing a fix to viennacl-dev. > P.S.S I encountered an issue when trying to use vector.cpp benchmark. > When including benchmark-utils.hpp I'd get an error: multiple definition > of printOps function and couldn't compile. I assume I'm using it wrong ( > I basically just copied and pasted vector.cpp into a QObject class like > I did with copy.cpp ) This is due to printOps being an 'ordinary' function with external linkage. To fix this, add 'inline' in front of it, or only compile it in one compilation unit (by moving the declaration into a header file and the definition into a .cpp file) Best regards, Karli ------------------------------------------------------------------------------ The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
