I built csound with useGprof=1, run a simple one-oscillator test, then
tried gprof and got an empty profile. Why is that?

----- Original Message ----- 
From: "Steven Yi" 
To: "Michael Gogins" ; "Developer discussions" 

Sent: Wednesday, April 16, 2008 7:42 PM
Subject: Re: [Cs-dev] Vectorization


> Hi Michael,
>
> I'm interested in the profiling results; what profiler are you using
> by the way?  I remember doing profiling a while back using debug
> builds and gprof (the options for that are still in SConstruct), but
> when I did profiling it was more for to try to figure out why the
> Pinkston FM model was really slow at the time, not so much for general
> Csound performance.
>
> I've poked around most of Csound's engine and feel like I know it
> pretty well, especially when I was more actively working on the new
> parser.  If there's any questions that arise about Csound internals
> and how things are allocated, I'd suggest looking at the new parser
> (well, the compile part that translates the AST to the INSTRTXT data
> structs that Csound uses at performance time) to see how things are
> built, as to me it's a bit clearer than reading the old parser code.
>
> steven
>
>
> On Wed, Apr 16, 2008 at 11:27 AM, Michael Gogins  
> wrote:
>> Yes, this is interesting. I have not yet tried unsafe math optimizations, 
>> but will.
>>
>>  I have tried inlining as much code as possible, which in practice means 
>> defining all C++ member functions in the header file. That consistently 
>> produces somewhere between 5% and 15% speedups, right there.
>>
>>  This in is the context of intermittently continuing development of 
>> Silence, an algorithmic composition/software synthesis library of my own 
>> design. Currently, Silence renders audio just slightly faster than 
>> Csound, but this is with hard-coded STK Rhodey C++ instruments. (But 
>> then, my comparison Csound instrument uses the STK Rhodey opcode also, so 
>> the comparison is more fair than it might seem: it mostly compares 
>> instrument allocation and event dispatching). Dynamically defined 
>> instruments will be slower in Silence, perhaps also in Csound (i.e., 
>> using more opcodes in the instr block instead of just calling one opcode 
>> that does all the work). I shall soon know more, as I have finalized my 
>> design of dynamically defined instruments and unit generators in Silence.
>>
>>  It is the usefulness of the profiler in getting this performance that 
>> has decided me to profile Csound. I am very curious to see how much 
>> "slack" there is, how much scope for performance improvements. Most of 
>> Csound's opcodes code looks to be quite efficient, and I am certainly not 
>> going to monkey with the fundamental design of the engine, so I am most 
>> curious about the efficiency of the engine implementation, especially the 
>> kperf loop, event initializers, output drivers, and so on. I don't, 
>> actually, expect much slack but the profiler will, perhaps, point out a 
>> few areas that have not been completely thought through.
>>
>>  Regards,
>>  Mike
>>
>>
>>
>>  -----Original Message-----
>>  >From: Steven Yi 
>>  >Sent: Apr 16, 2008 12:00 PM
>>  >To: Developer discussions 
>>  >Subject: [Cs-dev] Vectorization
>>  >
>>  >Hi All,
>>  >
>>  >There's an interesting thread going on on linux-audio-dev about the
>>  >performance of gcc vectorization code:
>>  >
>>  >http://www.nabble.com/vectorization-td15339532.html#a16720581
>>  >
>>  >The thread started in February but resumed a day or two ago, with
>>  >someone reporting better results with gcc than using assembly.
>>  >
>>  >steven
>>  >
>> 
>>  >-------------------------------------------------------------------------
>>  >This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>  >Don't miss this year's exciting event. There's still time to save $100.
>>  >Use priority code J8TL2D2.
>> 
>>  >http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>  >_______________________________________________
>>  >Csound-devel mailing list
>>  >Csound-devel@lists.sourceforge.net
>>  >https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>>  -------------------------------------------------------------------------
>>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>  Don't miss this year's exciting event. There's still time to save $100.
>>  Use priority code J8TL2D2.
>> 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>  _______________________________________________
>>  Csound-devel mailing list
>>  Csound-devel@lists.sourceforge.net
>>  https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net