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