I don't see speedup!

[mrez]

Hi,

I am trying couple of optiml examples and I am increasing sample data and then with delite command I am trying -t # or --cpp # to see speedup but everytime the "[METRICS]: Time for component all" shows bigger time for higher number of threads. Am I missing something?

Also is there any documentation for benchmark scripts in delite?!

Thanks in advance!

[mrez]

I got it. With tic toc approach I can get the timing. But I don't understand what is the METRICS times that gets printed everytime means.

[mrez]

I am still very baffled by this. Whatever I do (like matrix multiplication) and then increase the thread number (delite ... -t #) I still get worst performance. I do not know what I am doing wrong!

On Sunday, November 9, 2014 11:45:46 PM UTC+1, mrez wrote:

[Arvind Sujeeth]

Hi,

Parallel speedup depends on a number of factors, for example: physical hardware resources (number of available cores), sequential bottlenecks in your application, arithmetic intensity (the ratio of compute to memory operations), data size, etc. In general, if you use OptiML functional operators, and compile and run on parallel hardware, you should see at least some speedup, but as you can see, things can still go awry.

We are actually working on a visual debugger that can help you easily diagnose and fix these issues. Jithin, is there a prototype released for people to play with yet?

cheers,
Arvind

--
You received this message because you are subscribed to the Google Groups "OptiML" group.
To unsubscribe from this group and stop receiving emails from it, send an email to optiml+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jithin Thomas]

There is a version of the debugger in the github repo (<DELITE_REPO/profiler>) - but this may be unstable. You could give it a try nonetheless.

I'm working on pushing out a more stable prototype by early next week - with updated documentation about how to use the debugger and the different data points available.

Best,

Jithin

[mrez]

Thanks for mentioning these points but I already knew them. My problem is I am writing a simple for that was suppose to parallel and then use multi thread with -t # then it runs slower. And I am using delitc on Compiler trait and delite for running.

[mrez]

thanks Jithin, This can help me a lot.

[mrez]

As a more complete example. I am doing these two on a quad core machine with 16GB ram.

delite LogRegCompiler ~/workspace/local/data/data.dat ~/workspace/local/data/label.dat -t 1

delite LogRegCompiler ~/workspace/local/data/data.dat ~/workspace/local/data/label.dat -t 4 

They both show me the same speed:

-t 1

[METRICS]: Time for component all: 106...s                                                                                                      
[METRICS]: Time for component app: 2...s

-t 4

[METRICS]: Time for component all: 102....
[METRICS]: Time for component app: 3....s

[Jithin Thomas]

I've checked in the latest version of the debugger prototype into the github repo.

Please checkout the 'debugger' branch of hyperdsl in order to profile the app and to use the debugger.

The debugger can be found under <hyperdsl_root>/delite/profiler.

Instructions on opening the debugger, uploading the inputs, etc. are provided in a README.md file within the same directory.

NOTE: The debugger has been tested only on Chrome browsers yet.

Let me know if you run into some issues.

cheers,

Jithin