Perhaps this thread is dead, but have you looked at CUDA? A modern GPU has around 100 times the FPU firepower compared to a modern core duo. Whether you can structure your algorithm to suite the hardware is another question and I could help you with that. CUDA isn't as strong on integer but the multiplier is still damn large. NVIDIA also sells specialized boxes (the Tegra line) specially made for high-speed computing or supercomputer level processing power.
For an easier route that still produces really great results have you tried SSE optimized assembly? If you don't like SSE, have you looked at MMX? Finally, there is a paper out recently on writing CUDA code with Haskell. You might check that out if you are interested. Any of these options should dramatically increase your available computing resources. Forget language speed; that is a stupid metric that lots of people like to waste lots of time on. Using specialized tools in the right situation will increase your speed by orders of magnitude, not factors. I would highly recommend, if something taking a couple days is costing you any money, to take a serious look at one of the four options listed above. Chris On Jan 13, 3:17 pm, Isaac Gouy <igo...@yahoo.com> wrote: > On Jan 13, 4:41 am, "Eric Lavigne" <lavigne.e...@gmail.com> wrote: > > > > > There's also the (in)famous language benchmark > > > > site:http://shootout.alioth.debian.org/ > > > > This is primarily what I was going on. I realize no > > > benchmarking approach is going to be perfect, but > > > this attempt doesn't seem too bad. Is there any > > > reason to be particularly sceptical about results > > > found here? > > > The programs are written by volunteers, so the languages which have people > > that care about the results (and spend more time writing optimized code for > > their language of choice) get a big boost in score. > > It's easy to see which languages have suffered from relative neglect - > they're the ones where most of the programs were written by me and > still haven't been re-written by anyone else :-) > > C# Mono, Mozart/Oz, PHP, Scala > > otoh Scheme programs by Matthew Flatt, Haskell programs by Don > Stewart, Clean programs by John van Groningen, etc - wow! > > > Results are also > > affected by whether relevant libraries (often highly optimized for speed and > > memory) are included in the language's standard library, as third party > > libraries can't be used in shootout submissions. > > Except when they can - pcre, libgmp > > > Also, for many shootout > > problems, the answer can be determined at compile-time, so you are > > potentially testing an aspect of compilation optimization that is not so > > relevant for practical programming problems. > > > I don't know of a better set of benchmark results to look at - I use the > > shootout results myself - but I would take them with a grain of salt. > > In the words of Simon Peyton-Jones - "flawed, but available" > > http://www.haskell.org/pipermail/haskell-cafe/2008-December/052589.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
