I was too hasty. I meant, changing sampling rate would be an excellent test. Changing ksmps might change the swapping behavior of the software, so tests run at different sr should be run at identical ksmps.

The methodology then would be to prepare real-time piece that almost but not quite fails to work at 22 KHz, then increment sr until it does fail. This should be done with useDouble=0 and useDouble=1. Then dividing the srs will give the relative efficiency.

Regards,
Mike

-----Original Message-----
From: vanDongen/Gilcher 
Sent: Nov 8, 2005 5:42 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] 64 bit load test, was CVS Reorganization Request

On Tuesday 08 November 2005 04:41, Michael Gogins wrote:
> Yes, changing ksmps would be an excellent test.
>
> Regards,
> Mike
>
 I wouldn't be surprised that at a lower ksmps the cpu load would actually get 
close to each other. I found that with some of my orcs perform better at 
ksmps=16 than at ksmps=64. Cache issues obviously. 

regards

Gerard


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This brings up an interesting point; what about orchestras that are 
relatively simple but contain UDO's that utilize the local ksmps 
feature and subsequently implement ksmps that is significantly less 
than the global orchestra ksmps? Is this likely to have a significant 
effect on performance? BTW, typically I find that it does indeed sound 
better to compile and compose with 64-bit binaries and plugin libraries 
(especially with the PVS and scanned synth opcodes!!

An example of the question I am asking, "will multiple instances of 
this UDO affect more drastically a 64 bit compiled version of Csound 
than a version compiled for 32 bit precision because of the local ksmps 
feature of the UDO?":




sr		=	44100
kr		=	441
ksmps	=	100
nchnls	=	2

/*--- ---*/

		opcode	decimator, a, akk
	setksmps	1
ain, kbit, ksrate		xin

kbits    = 2^kbit				; Bit depth (1 to 16)
kfold    = (sr/ksrate)			; Sample rate
kin      downsamp  ain				; Convert to kr
kin      = (kin + 32768)			; Add DC to avoid (-)
kin      = kin*(kbits / 65536)		; Divide signal level
kin      = int(kin)				; Quantise
aout     upsamp  kin				; Convert to sr
aout     = aout * (65536/kbits) - 32768	; Scale and remove DC

a0ut     fold  aout, kfold			; Resample

	xout      a0ut

		endop

/*--- ---*/

		instr	1

kbet	ctrl7	1, 1, 1, 16
kser	ctrl7	1, 7, 11025, 44100

asig	diskin2	"/loops/dl_break2.aif", 1, 0, 1

aout	decimator	asig, kbet, kser

	printk2	kbet
	printk2	kser

	outs	aout, aout

		endin

/*--- ---*/


i1	0	100

e




On Nov 8, 2005, at 10:04 AM, Michael Gogins wrote:

> I was too hasty. I meant, changing sampling rate would be an excellent 
> test. Changing ksmps might change the swapping behavior of the 
> software, so tests run at different sr should be run at identical 
> ksmps.
>
> The methodology then would be to prepare real-time piece that almost 
> but not quite fails to work at 22 KHz, then increment sr until it does 
> fail. This should be done with useDouble=0 and useDouble=1. Then 
> dividing the srs will give the relative efficiency.
>
> Regards,
> Mike
>
> -----Original Message-----
> From: vanDongen/Gilcher 
> Sent: Nov 8, 2005 5:42 AM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] 64 bit load test, was CVS Reorganization Request
>
> On Tuesday 08 November 2005 04:41, Michael Gogins wrote:
>> Yes, changing ksmps would be an excellent test.
>>
>> Regards,
>> Mike
>>
>  I wouldn't be surprised that at a lower ksmps the cpu load would 
> actually get
> close to each other. I found that with some of my orcs perform better 
> at
> ksmps=16 than at ksmps=64. Cache issues obviously.
>
> regards
>
> Gerard



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Using my real time ensemble, a whole wack of stuff in there.
-+rtaudio=alsa -odac -d -m0 -b64 -B256 --expression-opt

sr=44100, nchnls=2 on AMD64 3000+
32 bit:
ksmps=64, 	70% cpu
ksmps=48	76%
ksmps=40	80.5%
ksmps=32 	88%
ksmps=24	99-99.9% starts glitching out, unusable
ksmp=16		trash

64 bit:
ksmps=64, 	83%
ksmps=48	92.5%, stable, but glitches if watching top
ksmp=40		99%, starts glitching out, unusable	
ksmps=32 	trash

Iain


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net