[racket] Racket 5.3.4, 32-bit slow?

Hi again Danny,

Very interesting note, thanks for the details.  The problem is a slightly
easier version of one the ProjectEuler.net problems (see here:
http://projecteuler.net/problem=210)  Basically the hard part of the
problem is finding the grid points that fall in a circle with origin at
(12500000, 12500000) with radius = ldiv8xrad2 (sqrt(2)*100000000/8).

-Joe


On Tue, Jun 4, 2013 at 4:20 PM, Danny Yoo <dyoo at hashcollision.org> wrote:

>
> 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/082fb058/attachment.html>