some more OSX 10.3 benchmarks (G4 550, single proc, 256)

> csound examples/trapped.csd
Elapsed time at end of performance: real: 59.542s, CPU:
43.900s

>csound examples/trapped.csd  -n
Elapsed time at end of performance: real: 44.565s, CPU:
34.900s

after commenting out csound.c lines 513-6

>csound examples/trapped.csd
Elapsed time at end of performance: real: 53.462s, CPU:
37.720s

>csound examples/trapped.csd -n
Elapsed time at end of performance: real: 38.795s, CPU:
29.340s

Commenting out that bit does make a difference, but not
crucial; does
it make a difference to have that bit of code? Writing
to disk seems to take a good chunk of processing time
though.
Can this be improved (again, not crucial for RT)?

Btw: all this is with gcc3opt=7400, which seems to improve
things.
I'm not sure about AltiVec. I don't think it makes any
difference.

Victor


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:
> some more OSX 10.3 benchmarks (G4 550, single proc, 256)
> 
> 
>>csound examples/trapped.csd
> 
> Elapsed time at end of performance: real: 59.542s, CPU:
> 43.900s
> 
> 
>>csound examples/trapped.csd  -n
> 
> Elapsed time at end of performance: real: 44.565s, CPU:
> 34.900s
> 
> after commenting out csound.c lines 513-6
> 
> 
>>csound examples/trapped.csd
> 
> Elapsed time at end of performance: real: 53.462s, CPU:
> 37.720s
> 
> 
>>csound examples/trapped.csd -n
> 
> Elapsed time at end of performance: real: 38.795s, CPU:
> 29.340s
> 
> Commenting out that bit does make a difference, but not
> crucial; does
> it make a difference to have that bit of code? Writing
> to disk seems to take a good chunk of processing time
> though.
> Can this be improved (again, not crucial for RT)?
> 
> Btw: all this is with gcc3opt=7400, which seems to improve
> things.
> I'm not sure about AltiVec. I don't think it makes any
> difference.
> 
> Victor
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> >csound examples/trapped.csd -n
> 
> Elapsed time at end of performance: real: 38.795s, CPU:
> 29.340s

This is now getting better. Did you disable messages with
-d -m128 -H0, and did you use --expression-opt ?

> Commenting out that bit does make a difference, but not
> crucial; does it make a difference to have that bit of code ?

It is needed for error handling. However, you may try replacing
the call to csoundPerformKsmps with csoundPerformBuffer in
frontends/csound/csound_main.c (assuming that you use the standard
command line frontend): this way, setjmp() will be called only
once per -b samples and not every ksmps samples. Of course for this
to make difference, -b needs to be higher than ksmps.

> Writing to disk seems to take a good chunk of processing time
> though.
> Can this be improved (again, not crucial for RT)?

If you did not already try to set higher buffer sizes, then something
like -b 1024 (or even higher, the default is 256) may improve disk rendering.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net