Hi, thanks for your comments and the issue scheduling :-)
> -benchmarking with a custom sparse matrix now works with some > matrices, > but not all; at least now it doesn't crash the program... > > > This is presumably due to the matrix market format. Matrices with > scalar type 'complex' or with pattern type 'pattern' are not > supported. Can you add an error message stating this? Something like > "The matrix market reader cannot read the provided file. Only > real-valued matrices in coordinate-format are supported." > > > Does the matrix reader provide different error codes for different > reading errors? Unfortunately not, and I can't change this without breaking user code in ViennaCL 1.x.y. :-( > I see that it prints "supports only real valued floating > point arithmetic" to the console, so I should cover all possible error > types if there's more than one. A generic error message in an alert box which covers the possible causes of the failure is presumably the best we can do, unless you want to manually inspect the matrix-market file. > -matrixmarket: reconnect the "download & run" functionality now that > benchmarking with custom sparse matrices does not crash the program. > Also, show the achieved result inside the matrixmarket table. > The idea > is to make it work like this: you find a nice matrix, hit download & > run, the program downloads the matrix, runs a benchmark with your > matrix, and shows the result next the "download&run" button. It > would be > good if we could avoid switching to the "benchmark" screen during > execution, and make it so that users don't need to leave the > "matrixmarket" screen at all. > > > Hmm, I think it is interesting for the user to see which sparse > matrix type works best for the particular sparse matrix. Unless we > can provide the full results from the 'sparse' tab in the > MatrixMarket, I'd rather refrain from it for now. > > > By "full results" do you mean those 7 tests that comprise the "sparse > benchmark" (HYB, ELL, CSR and others)? Showing 7 results instead of 1 > isn't a big a problem. I'd just have to play around the matrix table > layout to make 'em all fit properly. Yes, I'm referring to the results for each of these ~7 sparse matrix formats. > -some minor "face-lifting" procedures: Qt isn't very friendly > when it > comes to customizing the looks of widgets. That's why some > buttons and > tabs might look a bit wrong (depending on your platform). This > isn't a > significant issue, but still needs to be looked at. > > > I fixed a couple of these issues by removing hard-wired margins and > such. The home screen still has some layout issues, see screenshot. > > > About the hard-wired margins: when a result (bar graph) is too large to > fit on the plot, it goes out of bounds. Since the result value label is > "appended" to the end of the result bar, it goes out of bounds together > with the bar and cannot be displayed. The hard-wired margins were there > to ensure the labels will be displayed even if the result bar gets too > big. This kind of label rendering behavior is pretty weird if you ask > me, but that's how it is. Your solution to hard-code the axis range from > 0.1 to 5000 should work for now, but the labels will disappear if the > result gets close to that 5k mark. But I guess that's not a big problem > at the moment since 5k is currently not reachable (or is it?). 5K is presumably out of reach for another year or two, which should be sufficient for the lifespan of the 1.0.0 GUI. I think I'll update it to 10 TFLOPs just to be on the safe side. > As for the home screen layout issues and widget display bugs: like I > said, Qt turns into a spoiled brat as soon as you start messing with the > looks of its widgets. I can't say if it will be possible to make it look > good on all platforms. Lots of testing will be needed to ensure it looks > as it should on every platform... Yeah, cross-platform GUIs are always a hassle... We should make it as good as possible given the available time, but not delay it indefinitely. An ugly GUI that is released is still more useful than the most beautiful GUI that never gets released ;-) > And that empty space in the home > screen should be definitely used for something, I just don't know what :D Maybe arrange the device information in two columns? > Some more thoughts (some are trivial to fix): > - Result tabs: Can these tabs be renamed to "Dense > Matrix-Matrix-Products", "Host-Device Copy", "Sparse Matrix-Vector > Product", and "Vector Operations", respectively? I tried to do that, > but it seems like the current strings have some further meaning for > the program control flow (fix this?)? > > > You mean the detailed test results tab names in the bottom? I don't > recall their strings being important to the program flow control. Maybe > I hard-coded something for testing purposes but forgot to fix it > afterwards... Yes, these. There is some strings-to-numbers-to-strings in the code, which presumably is the reason why I couldn't change the string without running into seg-faults. > - I think it makes more sense for the BLAS 3 benchmark to scan > through different matrix sizes, rather than using a fixed size. The > benchmark just stops when a kernel run starts to take more than, > say, a second. This ensures that the benchmark does not get stuck on > mobile hardware, which is far slower than high-end desktop hardware > and for which we may not have good kernels yet. I'll take care of this. > > > Hmm, keep in mind that we need still need to make a "standardized" > benchmark configuration for the standard benchmark mode. Using different > matrix sizes for different hardware is not a very "standardized" thing > to do. We can still standardize that to "Go up to matrix sizes of M-by-M, but don't exceed an execution time of N seconds". M=2k and N = 5 seems reasonable. > - Results summary: Rather than providing an average, I think that > taking the best results makes more sense. For example, for the > sparse bench a user is really not interested in how many FLOPs are > obtained on average, but how many FLOPs the fastest matrix type > provides. Also an easy fix :-) > > > Heh, originally I made it so that the best result is shown in the > "result summary" graph. But then you said it might be better to use > median values so I went with that :) Twas probably a misunderstanding, > very easy to fix =) Presumably a misunderstanding: Each value in the plots should be the median of the BENCHMARK_RUNS. ;-) For the summary it just causes confusion if we report '100 GFLOPs' but then the tab reports up to '150' ;-) > The final 'big TODO' is, of course, to provide a reasonably > automated packager to ship executables for Windows and Linux. I'm > less worried about Linux, because OpenCL can typically be found in a > system path. However, getting this to work with Windows might be > quite tricky, since a user might have the OpenCL lib installed at > whatever path. Either way, I reserved the weekend for this, so we > should be able to release early next week. (I can't postpone the > release, I'm totally filled with other work until the end of the > year then.) > > > Noob question: can't we package those OpenCL libs with our program, or > are those libs specific to each user's CPU/GPU manufacturer? What I'm > trying to ask is this: do users need to have a specific OpenCL SDK > installed (for example, I had to install AMD APP SDK separately for > development purposes), or is there a "general purpose" OpenCL lib that > anyone can use with any hardware and that also happens to be easily > package-able? Unfortunately there is no fully portable OpenCL SDK available, each of them is either vendor- or device-specific. And even if there were a fully portable OpenCL SDK with good performance, we probably would run into severe licensing issues if we package them. > As for an automated packager, we could use Qt Installer Framework > <http://qt-project.org/doc/qtinstallerframework-1.4/index.html>. I've > never used before, but considering the good documentation I don't think > it'll be a problem. Looks neat, thanks! Best regards, Karli ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
