[racket] Racket 5.3.4, 32-bit slow?

> Yes, makes perfect sense, hmmm... there's probably a way to avoid so many
> sqrt calls.
>

This probably won't help.  No individual iteration in that inner loop is
beyond 32 bits.  The accumulated sum itself is what grows beyond the bounds
of a 32-bit representation.  Reducing the number of sqrt calls is likely
not to noticeably improve the runtime performance on 32-bit platforms: the
dominant part of your runtime is the fact that bignum operations will not
be constant time for the quantities your program is working with.

If you can tell us more about the problem domain, maybe we can suggest
improvements.  It looks like it's a numerical computation of something.  Do
you need the result to be exact?  What is it actually computing, and why?



How do you like Go?  How is the performance on this code?
>

I can't say anything too informed about it yet.  I just started learning it
a few days ago.  As far as compile and run times are concerned, here's what
I see:

######
bash-3.2$ time go build euler210.go
real 0m0.193s
user 0m0.152s
sys 0m0.037s

bash-3.2$ time ./euler210
15981747679237090

real 0m0.117s
user 0m0.112s
sys 0m0.003s

bash-3.2$ time raco make euler210.rkt

real 0m0.291s
user 0m0.211s
sys 0m0.058s
bash-3.2$ time racket euler210.rkt
15981747679237090

real 0m0.803s
user 0m0.736s
sys 0m0.037s
######

Note that my Go version is "cheating" in a sense: I kept changing the size
of the numeric representations until I stopped seeing differences from the
canonical Racket version.  What I've got is not backed by any kind of
numeric tower.  If I were to really write it in a way that tries to do a
better job at preserving the meaning of the program, I'd need to add a
whole bunch of references to Go's math/big library, and be very careful in
doing so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130604/7ea72d96/attachment-0001.html>