At Mon, 25 Jul 2011 08:05:46 -0400, Sam Tobin-Hochstadt wrote:
> On Mon, Jul 25, 2011 at 7:51 AM, Matthew Flatt wrote:
> >
> > Here are some timings for 1000 iterations on 2^20-element inputs
> > (32-bit mode, Mac Book Pro 2.53 GHz):
> >
> > C as above, gcc -02 : 1409
> > C with indire
On Mon, Jul 25, 2011 at 7:51 AM, Matthew Flatt wrote:
>
> Here are some timings for 1000 iterations on 2^20-element inputs
> (32-bit mode, Mac Book Pro 2.53 GHz):
>
> C as above, gcc -02 : 1409
> C with indirections, gcc -O2 : 4041
> C as above, gcc -O0 : 6425
> C with ind
At Sat, 23 Jul 2011 14:42:15 -0400, John Clements wrote:
> This C code adds the content of one buffer to another one, with no checking.
> The corresponding racket code runs about 10x slower. Do you folks think that
> it
> should be possible to do better? (One salient fact: these are
> shorts--
Is the C code compiled to vectorised assembler? That could account for
a factor of about 4-16 depending.
N.
On Sat, Jul 23, 2011 at 7:42 PM, John Clements
wrote:
> This C code adds the content of one buffer to another one, with no checking.
> The corresponding racket code runs about 10x slower
On Jul 23, 2011, at 2:46 PM, Robby Findler wrote:
> What is the data you're using to represent the shorts in Racket?
#s.
John
>
> Robby
>
> On Sat, Jul 23, 2011 at 1:42 PM, John Clements
> wrote:
>> This C code adds the content of one buffer to another one, with no checking.
>> The corre
What is the data you're using to represent the shorts in Racket?
Robby
On Sat, Jul 23, 2011 at 1:42 PM, John Clements
wrote:
> This C code adds the content of one buffer to another one, with no checking.
> The corresponding racket code runs about 10x slower. Do you folks think that
> it shoul
6 matches
Mail list logo
