search

stanford-ppl / Delite

The Delite Git Repo
http://ppl.stanford.edu
216 stars 43 forks source link

Debugger #37

Closed JithinThomas closed 10 years ago

JithinThomas commented 10 years ago

(i) Fixes for SourceContext(most importantly, change in reflectMirrored function calls - now, an additional SourceContext parameter is passed in)

(ii) Added a MemoryProfiler

(iii) Added instrumentation to track the sync barrier calls made by the kernels

(iv) Changed the format of profileData.js (which is the output of the --profile flag)

kjbrown commented 10 years ago

We should guard all of the timing / logging code generated by the framework and runtime with some kind of debugMode flag in Config so that we don't pay for the cost of logging during performance runs.

JithinThomas commented 10 years ago

The timing code is generated only if the --profile flag is used when invoking delite. Using that flag sets Config.profile which results in instrumentation code being inserted.

Let me know if you find cases where the instrumentation is being used even if --profile is not used

kjbrown commented 10 years ago

I was looking particularly at the codegen for DeliteArray.scala, which appears to always log allocations, and ScalaSyncGenerator.scala, which appears to always time the locking overheads. I haven’t checked carefully if there are any others.

—Kevin

On Apr 16, 2014, at 6:26 PM, Jithin Thomas notifications@github.com wrote:

The timing code is generated only if the --profile flag is used when invoking delite. Using that flag sets Config.profile which results in instrumentation code being inserted.

Let me know if you find cases where the instrumentation is being used even if --profile is not used

— Reply to this email directly or view it on GitHub.

JithinThomas commented 10 years ago

Oh.. you're right. Sorry. That was my bad. I'll fix that and check in the change by tonight.

Thanks for pointing that out!