<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Yes, makes perfect sense, hmmm... there's probably a way to avoid so many sqrt calls.</div></div></blockquote><div><br></div><div style>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.</div>
<div style> <br></div><div style>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?</div>
<div> <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div></div><div>How do you like Go? How is the performance on this code?</div></div></blockquote><div><br></div><div style>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:</div>
<div style><br></div><div style>######</div><div style><div>bash-3.2$ time go build euler210.go </div><div>real<span class="" style="white-space:pre"> </span>0m0.193s</div><div>user<span class="" style="white-space:pre"> </span>0m0.152s</div>
<div>sys<span class="" style="white-space:pre"> </span>0m0.037s</div><div><div><br></div><div>bash-3.2$ time ./euler210 </div><div>15981747679237090</div><div><br></div><div>real<span class="" style="white-space:pre"> </span>0m0.117s</div>
<div>user<span class="" style="white-space:pre"> </span>0m0.112s</div><div>sys<span class="" style="white-space:pre"> </span>0m0.003s</div></div><div><div><br></div><div><div>bash-3.2$ time raco make euler210.rkt</div><div>
<br></div><div>real<span class="" style="white-space:pre"> </span>0m0.291s</div><div>user<span class="" style="white-space:pre"> </span>0m0.211s</div><div>sys<span class="" style="white-space:pre"> </span>0m0.058s</div></div>
<div><div>bash-3.2$ time racket euler210.rkt</div><div>15981747679237090</div><div><br></div><div>real<span class="" style="white-space:pre"> </span>0m0.803s</div><div>user<span class="" style="white-space:pre"> </span>0m0.736s</div>
<div>sys<span class="" style="white-space:pre"> </span>0m0.037s</div></div><div>######</div><div></div></div><div><br></div><div style>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.</div>
</div></div></div></div>