On the Intel Atom, compiled with gcc 4.3.2, examples/xanadu-high-resolution.csd:

Double	Float
622.580	601.777
614.613	576.930
603.486	578.398
608.513	594.795
612.298	587.975
	
	96.03%

This is not a very large difference, and may not even be statistically
significant.

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

That's interesting, With a max  difference of approximately 6%.
Thanks.
Oeyvind

2009/5/24 Michael Gogins :
> On the Intel Atom, compiled with gcc 4.3.2, examples/xanadu-high-resolution.csd:
>
> Double  Float
> 622.580 601.777
> 614.613 576.930
> 603.486 578.398
> 608.513 594.795
> 612.298 587.975
>
>        96.03%
>
> This is not a very large difference, and may not even be statistically
> significant.
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

This is nice to know, although I'm not surprised. Modern processors have 
instructions that work with doubles as fast as those with floats. Using 
doubles will only be significantly slower if you have a large set of 
numbers to process, because the memory cache will miss more often. But 
if I understand correctly CSound works with buffers whose size is 
proportional to the control rate, so they are quite small.

Michael Gogins wrote:
> On the Intel Atom, compiled with gcc 4.3.2, examples/xanadu-high-resolution.csd:
>
> Double	Float
> 622.580	601.777
> 614.613	576.930
> 603.486	578.398
> 608.513	594.795
> 612.298	587.975
> 	
> 	96.03%
>
> This is not a very large difference, and may not even be statistically
> significant.
>
>   

-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

Using GNU R:

> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
> t.test(x=double, y=float)

        Welch Two Sample t-test

data:  double and float
t = 4.2542, df = 6.996, p-value = 0.003778
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 10.80193 37.84407
sample estimates:
mean of x mean of y
  612.298   587.975

We have a p-value of 0.003, which means that the difference is
statistically significant. Is your atom 32 or 64 bit? Is your OS 64
bit? Also, which optimizations did you pass to scons? Did you use
gcc4opt=native?

Saludos,
Felipe Sateler



On Mon, May 25, 2009 at 04:12, Michael Gogins  wrote:
> On the Intel Atom, compiled with gcc 4.3.2, examples/xanadu-high-resolution.csd:
>
> Double  Float
> 622.580 601.777
> 614.613 576.930
> 603.486 578.398
> 608.513 594.795
> 612.298 587.975
>
>        96.03%
>
> This is not a very large difference, and may not even be statistically
> significant.
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Thanks for the statistics. I agree, there is a moderate degree of
statistical significance and the difference in means is probably more
or less what it appears to be.

My options were gcc4opt=pentium-m (which is probably not correct,
should probably be prescott), O2, no frame pointer. The Atom is, I
believe, 32 bit, at any rate the Eeebuntu OS is 32 bit and the
compiler is 32 bit.

I will try with "native" and see what happens.

Regards,
Mike

On 5/24/09, Felipe Sateler  wrote:
> Using GNU R:
>
>> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
>> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
>> t.test(x=double, y=float)
>
>         Welch Two Sample t-test
>
> data:  double and float
> t = 4.2542, df = 6.996, p-value = 0.003778
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
>  10.80193 37.84407
> sample estimates:
> mean of x mean of y
>   612.298   587.975
>
> We have a p-value of 0.003, which means that the difference is
> statistically significant. Is your atom 32 or 64 bit? Is your OS 64
> bit? Also, which optimizations did you pass to scons? Did you use
> gcc4opt=native?
>
> Saludos,
> Felipe Sateler
>
>
>
> On Mon, May 25, 2009 at 04:12, Michael Gogins 
> wrote:
>> On the Intel Atom, compiled with gcc 4.3.2,
>> examples/xanadu-high-resolution.csd:
>>
>> Double  Float
>> 622.580 601.777
>> 614.613 576.930
>> 603.486 578.398
>> 608.513 594.795
>> 612.298 587.975
>>
>>        96.03%
>>
>> This is not a very large difference, and may not even be statistically
>> significant.
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I thought SConstruct passed -O3 -ffast-math and -ftree-vectorize too
when given the gcc4opt parameter. I just did the same test (64bit
Centrino Duo on 64bit Debian), and have the following results:

float
        94.870
        94.350
        97.430
        95.080
        92.950
double
        76.840
        74.960
        74.450
        76.000
        76.890

Gnu R:

> float <- c(94.870, 94.350, 97.430, 95.080, 92.950)
> double <- c(76.840, 74.960, 74.450, 76.000, 76.890)
> t.test(x=float, y=double)

        Welch Two Sample t-test

data:  float and double
t = 21.7992, df = 7.033, p-value = 1.021e-07
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 17.03726 21.17874
sample estimates:
mean of x mean of y
   94.936    75.828

So it seems like in a 64bit environment doubles is actually much
faster (20%) than floats. I don't know why could this be, anyone have
any possible explanations? Of course it will depend on the test csd,
(I think I have reported lesser gains with trapped.csd). But still I
don't see how it is faster...


Saludos,
Felipe Sateler



On Mon, May 25, 2009 at 12:16, Michael Gogins  wrote:
> Thanks for the statistics. I agree, there is a moderate degree of
> statistical significance and the difference in means is probably more
> or less what it appears to be.
>
> My options were gcc4opt=pentium-m (which is probably not correct,
> should probably be prescott), O2, no frame pointer. The Atom is, I
> believe, 32 bit, at any rate the Eeebuntu OS is 32 bit and the
> compiler is 32 bit.
>
> I will try with "native" and see what happens.
>
> Regards,
> Mike
>
> On 5/24/09, Felipe Sateler  wrote:
>> Using GNU R:
>>
>>> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
>>> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
>>> t.test(x=double, y=float)
>>
>>         Welch Two Sample t-test
>>
>> data:  double and float
>> t = 4.2542, df = 6.996, p-value = 0.003778
>> alternative hypothesis: true difference in means is not equal to 0
>> 95 percent confidence interval:
>>  10.80193 37.84407
>> sample estimates:
>> mean of x mean of y
>>   612.298   587.975
>>
>> We have a p-value of 0.003, which means that the difference is
>> statistically significant. Is your atom 32 or 64 bit? Is your OS 64
>> bit? Also, which optimizations did you pass to scons? Did you use
>> gcc4opt=native?
>>
>> Saludos,
>> Felipe Sateler
>>
>>
>>
>> On Mon, May 25, 2009 at 04:12, Michael Gogins 
>> wrote:
>>> On the Intel Atom, compiled with gcc 4.3.2,
>>> examples/xanadu-high-resolution.csd:
>>>
>>> Double  Float
>>> 622.580 601.777
>>> 614.613 576.930
>>> 603.486 578.398
>>> 608.513 594.795
>>> 612.298 587.975
>>>
>>>        96.03%
>>>
>>> This is not a very large difference, and may not even be statistically
>>> significant.
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I just realized that using doubles may be slower if there are large 
tables, because then a cache miss is more likely. But 
xanadu-high-resolution.csd uses three tables with a size of 65537, with 
doubles that makes about 1.5 MB. Some processors have caches that can 
contain this, others don't.

Mark Van Peteghem wrote:
> This is nice to know, although I'm not surprised. Modern processors 
> have instructions that work with doubles as fast as those with floats. 
> Using doubles will only be significantly slower if you have a large 
> set of numbers to process, because the memory cache will miss more 
> often. But if I understand correctly CSound works with buffers whose 
> size is proportional to the control rate, so they are quite small.
>
> Michael Gogins wrote:
>> On the Intel Atom, compiled with gcc 4.3.2, 
>> examples/xanadu-high-resolution.csd:
>>
>> Double    Float
>> 622.580    601.777
>> 614.613    576.930
>> 603.486    578.398
>> 608.513    594.795
>> 612.298    587.975
>>     
>>     96.03%
>>
>> This is not a very large difference, and may not even be statistically
>> significant.
>>
>>   
>

-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

I think I've heard about this before.

I don't have references for this, but it seems likely to me that 64
bits would be the "native word size" and this would probably extend to
memory bus operations, therefore operations on that size would
probably require fewer instructions and be more optimized on the
chips. The FPU register size may still be 80 bits...

Regards,
Mike

On 5/24/09, Felipe Sateler  wrote:
> I thought SConstruct passed -O3 -ffast-math and -ftree-vectorize too
> when given the gcc4opt parameter. I just did the same test (64bit
> Centrino Duo on 64bit Debian), and have the following results:
>
> float
>         94.870
>         94.350
>         97.430
>         95.080
>         92.950
> double
>         76.840
>         74.960
>         74.450
>         76.000
>         76.890
>
> Gnu R:
>
>> float <- c(94.870, 94.350, 97.430, 95.080, 92.950)
>> double <- c(76.840, 74.960, 74.450, 76.000, 76.890)
>> t.test(x=float, y=double)
>
>         Welch Two Sample t-test
>
> data:  float and double
> t = 21.7992, df = 7.033, p-value = 1.021e-07
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
>  17.03726 21.17874
> sample estimates:
> mean of x mean of y
>    94.936    75.828
>
> So it seems like in a 64bit environment doubles is actually much
> faster (20%) than floats. I don't know why could this be, anyone have
> any possible explanations? Of course it will depend on the test csd,
> (I think I have reported lesser gains with trapped.csd). But still I
> don't see how it is faster...
>
>
> Saludos,
> Felipe Sateler
>
>
>
> On Mon, May 25, 2009 at 12:16, Michael Gogins 
> wrote:
>> Thanks for the statistics. I agree, there is a moderate degree of
>> statistical significance and the difference in means is probably more
>> or less what it appears to be.
>>
>> My options were gcc4opt=pentium-m (which is probably not correct,
>> should probably be prescott), O2, no frame pointer. The Atom is, I
>> believe, 32 bit, at any rate the Eeebuntu OS is 32 bit and the
>> compiler is 32 bit.
>>
>> I will try with "native" and see what happens.
>>
>> Regards,
>> Mike
>>
>> On 5/24/09, Felipe Sateler  wrote:
>>> Using GNU R:
>>>
>>>> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
>>>> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
>>>> t.test(x=double, y=float)
>>>
>>>         Welch Two Sample t-test
>>>
>>> data:  double and float
>>> t = 4.2542, df = 6.996, p-value = 0.003778
>>> alternative hypothesis: true difference in means is not equal to 0
>>> 95 percent confidence interval:
>>>  10.80193 37.84407
>>> sample estimates:
>>> mean of x mean of y
>>>   612.298   587.975
>>>
>>> We have a p-value of 0.003, which means that the difference is
>>> statistically significant. Is your atom 32 or 64 bit? Is your OS 64
>>> bit? Also, which optimizations did you pass to scons? Did you use
>>> gcc4opt=native?
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>>
>>>
>>> On Mon, May 25, 2009 at 04:12, Michael Gogins 
>>> wrote:
>>>> On the Intel Atom, compiled with gcc 4.3.2,
>>>> examples/xanadu-high-resolution.csd:
>>>>
>>>> Double  Float
>>>> 622.580 601.777
>>>> 614.613 576.930
>>>> 603.486 578.398
>>>> 608.513 594.795
>>>> 612.298 587.975
>>>>
>>>>        96.03%
>>>>
>>>> This is not a very large difference, and may not even be statistically
>>>> significant.
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I checked, my tests were built with -march=prescott.

Regards,
Mike

On 5/25/09, Michael Gogins  wrote:
> I think I've heard about this before.
>
> I don't have references for this, but it seems likely to me that 64
> bits would be the "native word size" and this would probably extend to
> memory bus operations, therefore operations on that size would
> probably require fewer instructions and be more optimized on the
> chips. The FPU register size may still be 80 bits...
>
> Regards,
> Mike
>
> On 5/24/09, Felipe Sateler  wrote:
>> I thought SConstruct passed -O3 -ffast-math and -ftree-vectorize too
>> when given the gcc4opt parameter. I just did the same test (64bit
>> Centrino Duo on 64bit Debian), and have the following results:
>>
>> float
>>         94.870
>>         94.350
>>         97.430
>>         95.080
>>         92.950
>> double
>>         76.840
>>         74.960
>>         74.450
>>         76.000
>>         76.890
>>
>> Gnu R:
>>
>>> float <- c(94.870, 94.350, 97.430, 95.080, 92.950)
>>> double <- c(76.840, 74.960, 74.450, 76.000, 76.890)
>>> t.test(x=float, y=double)
>>
>>         Welch Two Sample t-test
>>
>> data:  float and double
>> t = 21.7992, df = 7.033, p-value = 1.021e-07
>> alternative hypothesis: true difference in means is not equal to 0
>> 95 percent confidence interval:
>>  17.03726 21.17874
>> sample estimates:
>> mean of x mean of y
>>    94.936    75.828
>>
>> So it seems like in a 64bit environment doubles is actually much
>> faster (20%) than floats. I don't know why could this be, anyone have
>> any possible explanations? Of course it will depend on the test csd,
>> (I think I have reported lesser gains with trapped.csd). But still I
>> don't see how it is faster...
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>>
>>
>> On Mon, May 25, 2009 at 12:16, Michael Gogins 
>> wrote:
>>> Thanks for the statistics. I agree, there is a moderate degree of
>>> statistical significance and the difference in means is probably more
>>> or less what it appears to be.
>>>
>>> My options were gcc4opt=pentium-m (which is probably not correct,
>>> should probably be prescott), O2, no frame pointer. The Atom is, I
>>> believe, 32 bit, at any rate the Eeebuntu OS is 32 bit and the
>>> compiler is 32 bit.
>>>
>>> I will try with "native" and see what happens.
>>>
>>> Regards,
>>> Mike
>>>
>>> On 5/24/09, Felipe Sateler  wrote:
>>>> Using GNU R:
>>>>
>>>>> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
>>>>> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
>>>>> t.test(x=double, y=float)
>>>>
>>>>         Welch Two Sample t-test
>>>>
>>>> data:  double and float
>>>> t = 4.2542, df = 6.996, p-value = 0.003778
>>>> alternative hypothesis: true difference in means is not equal to 0
>>>> 95 percent confidence interval:
>>>>  10.80193 37.84407
>>>> sample estimates:
>>>> mean of x mean of y
>>>>   612.298   587.975
>>>>
>>>> We have a p-value of 0.003, which means that the difference is
>>>> statistically significant. Is your atom 32 or 64 bit? Is your OS 64
>>>> bit? Also, which optimizations did you pass to scons? Did you use
>>>> gcc4opt=native?
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>>
>>>>
>>>> On Mon, May 25, 2009 at 04:12, Michael Gogins
>>>> 
>>>> wrote:
>>>>> On the Intel Atom, compiled with gcc 4.3.2,
>>>>> examples/xanadu-high-resolution.csd:
>>>>>
>>>>> Double  Float
>>>>> 622.580 601.777
>>>>> 614.613 576.930
>>>>> 603.486 578.398
>>>>> 608.513 594.795
>>>>> 612.298 587.975
>>>>>
>>>>>        96.03%
>>>>>
>>>>> This is not a very large difference, and may not even be statistically
>>>>> significant.
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Another possible (related?) explanation is that the fpu might only
operate on a single size (80 bits, apparently), so the conversion
operation might be more expensive for the 32-80 step than 64-80.

Saludos,
Felipe Sateler



On Mon, May 25, 2009 at 21:32, Michael Gogins  wrote:
> I think I've heard about this before.
>
> I don't have references for this, but it seems likely to me that 64
> bits would be the "native word size" and this would probably extend to
> memory bus operations, therefore operations on that size would
> probably require fewer instructions and be more optimized on the
> chips. The FPU register size may still be 80 bits...
>
> Regards,
> Mike
>
> On 5/24/09, Felipe Sateler  wrote:
>> I thought SConstruct passed -O3 -ffast-math and -ftree-vectorize too
>> when given the gcc4opt parameter. I just did the same test (64bit
>> Centrino Duo on 64bit Debian), and have the following results:
>>
>> float
>>         94.870
>>         94.350
>>         97.430
>>         95.080
>>         92.950
>> double
>>         76.840
>>         74.960
>>         74.450
>>         76.000
>>         76.890
>>
>> Gnu R:
>>
>>> float <- c(94.870, 94.350, 97.430, 95.080, 92.950)
>>> double <- c(76.840, 74.960, 74.450, 76.000, 76.890)
>>> t.test(x=float, y=double)
>>
>>         Welch Two Sample t-test
>>
>> data:  float and double
>> t = 21.7992, df = 7.033, p-value = 1.021e-07
>> alternative hypothesis: true difference in means is not equal to 0
>> 95 percent confidence interval:
>>  17.03726 21.17874
>> sample estimates:
>> mean of x mean of y
>>    94.936    75.828
>>
>> So it seems like in a 64bit environment doubles is actually much
>> faster (20%) than floats. I don't know why could this be, anyone have
>> any possible explanations? Of course it will depend on the test csd,
>> (I think I have reported lesser gains with trapped.csd). But still I
>> don't see how it is faster...
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>>
>>
>> On Mon, May 25, 2009 at 12:16, Michael Gogins 
>> wrote:
>>> Thanks for the statistics. I agree, there is a moderate degree of
>>> statistical significance and the difference in means is probably more
>>> or less what it appears to be.
>>>
>>> My options were gcc4opt=pentium-m (which is probably not correct,
>>> should probably be prescott), O2, no frame pointer. The Atom is, I
>>> believe, 32 bit, at any rate the Eeebuntu OS is 32 bit and the
>>> compiler is 32 bit.
>>>
>>> I will try with "native" and see what happens.
>>>
>>> Regards,
>>> Mike
>>>
>>> On 5/24/09, Felipe Sateler  wrote:
>>>> Using GNU R:
>>>>
>>>>> double <- c(622.58, 614.613, 603.486, 608.513, 612.298)
>>>>> float  <- c(601.777, 576.93, 578.398, 594.795, 587.975)
>>>>> t.test(x=double, y=float)
>>>>
>>>>         Welch Two Sample t-test
>>>>
>>>> data:  double and float
>>>> t = 4.2542, df = 6.996, p-value = 0.003778
>>>> alternative hypothesis: true difference in means is not equal to 0
>>>> 95 percent confidence interval:
>>>>  10.80193 37.84407
>>>> sample estimates:
>>>> mean of x mean of y
>>>>   612.298   587.975
>>>>
>>>> We have a p-value of 0.003, which means that the difference is
>>>> statistically significant. Is your atom 32 or 64 bit? Is your OS 64
>>>> bit? Also, which optimizations did you pass to scons? Did you use
>>>> gcc4opt=native?
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>>
>>>>
>>>> On Mon, May 25, 2009 at 04:12, Michael Gogins 
>>>> wrote:
>>>>> On the Intel Atom, compiled with gcc 4.3.2,
>>>>> examples/xanadu-high-resolution.csd:
>>>>>
>>>>> Double  Float
>>>>> 622.580 601.777
>>>>> 614.613 576.930
>>>>> 603.486 578.398
>>>>> 608.513 594.795
>>>>> 612.298 587.975
>>>>>
>>>>>        96.03%
>>>>>
>>>>> This is not a very large difference, and may not even be statistically
>>>>> significant.
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>