Hey Namik,
2014-05-06 19:43 GMT+02:00 Namik Karovic <namik.karo...@gmail.com>:
> Hello,
>
> Apologies for not replying earlier, I've been quite busy these last two
> days.
>
>
Don't worry ;)
So far I have been exploring the advantages/disadvantages of using
> QML/QtQuick vs traditional widget based GUI. QML has some great design
> features that could improve the overall user experience and aren't easily
> implemented when using widgets. I was originally planning to develop some
> parts using QML ( animations and charts ) and integrate them with the main
> widget based GUI. However I am now exploring the possibility of doing the
> entire GUI in QML. Suggestions on which approach to choose are welcome.
>
>
Unfortunately, I don't know much about Qt, so I probably couldn't help
here. However, keep in mind that we aim for maximum portability. I would
tend to think that QML is more portable accross languages, and so I would
say go for it, as long as you don't loose portability elsewhere.
Reading through your discussion about expert benchmark setting I see that I
> probably should have spent more time studying the autotuner and benchmark
> codes :/ I understand that there is a great need for expert benchmark
> customization and I hope to succeed in making that part as detailed as
> possible, but there should a certain limit to the extent of details. What
> I'm saying is I'd rather not spend time developing features that will be
> used only a couple of times. Surely there are some details that aren't of
> critical importance?
>
>
> It would be great if you guys could agree on what expert details are of
> greatest priority. I'm going to start studying the autotuner and benchmark
> codes so I can better understand what needs to be done.
>
I think that the most important part of the project is the
intuitiveness/functionnality of the GUI. Keep in mind that most of your
userbase will have a limited amount of time, and that anything beyond
"double-click+coffee break" will probably be ignored ;)
I really believe that there is no need to read any code related to the
auto-tuner, as it is disappearing. Re-implementing an exhaustive search for
one particular size for the GUI will not be a huge challenge, so don't
worry too much about it.
This thread is exclusively dedicated to possible features in the expert
tab, which is not a priority for now (but it's still good to have some
mid-term perspective when starting a project).
That being said, I believe that the "Basic" options should include:
- Benchmarking of as many routines as possible : BLAS, FFT, Solvers, etc...
- Simple exhaustive-search auto-tuning for what supports it : "What could
this hardware ideally give on this problem"
- Export of the benchmark results to an open database
I don't think you should worry about anything else as of now. I'll be
working rather actively on a command-line interface to some advanced
auto-tuning features.
Philippe
> Best regards,
> Namik
>
>
> On Tue, May 6, 2014 at 9:38 AM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
>
>> Hi,
>>
>>
>> > Why is data pointless? I'd rather have only a few datapoints on new
>>
>>> hardware out there rather than having absolutely no data at all.
>>>
>>>
>>> I mean, the data is pretty useful because it tells us about the best
>>> default kernel for large square matrices, but it is not very useful if
>>> we want to build a general input-dependent model, as it requires in my
>>> experience more than 1000 data points.
>>>
>>
>> This is true. So this calls for an hierarchical approach:
>> Level 1: Just a couple of known kernels for a given data size, which are
>> compared on the target machine.
>> Level 2: A full tuning set for one data size on the target
>> Level 3: All ~1000 points for building a model
>>
>> Execution times between these levels vary significantly: While almost all
>> users will go through Level 1 anyway, only a few will have the patience to
>> wait for results on Level 2. Level 3 will be mostly for us to have a
>> 'normalized' process for building performance models. Either way, if others
>> will join (machine learning community?), that would be great!
>>
>>
>>
>> I'd rather refrain from running Python scripts from the benchmark
>>> GUI. This is intended to be an end-user tool. Those interested in
>>> running from Python should take the Python code (i.e. PyViennaCL)
>>> directly.
>>>
>>>
>>> Are you sure? It would not take a lot of efforts to have an optional way
>>> to call the python script with the proper arguments from the auto-tuner,
>>> as long as the user provides the path and that he has all the necessary
>>> dependencies.
>>>
>>
>> The second half of the last sentence is the problem. I expect >80% of
>> users to run on Windows, where anything but a 'double click installer' is a
>> non-standard process. If Namik has time left by the end of the summer, we
>> can look into that, but we first need to focus on our target audience.
>>
>>
>>
>> Such cases are probably only interesting for the 'expert settings'
>>> tab in the GUI, as these parameters only make sense to people who
>>> *really* know what they are doing (and willing to invest the time).
>>> For bloggers, journalists, etc., who just want to quickly get some
>>> performance datapoints for the very latest hardware, this is usually
>>> not of interest. We need to foc
>>>
>>> us on serving the main audience first and then watch out for
>>> fruitful directions on how to extend it further.
>>>
>>>
>>> Of course ! I've been referring to the "expert settings" tab from the
>>> beginning :)
>>>
>>
>> Ah, please say so :-)
>>
>> Best regards,
>> Karli
>>
>>
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
