On Jul 6, 6:08 pm, Bradbev <brad.beveri...@gmail.com> wrote: > On Jul 6, 4:30 pm, fft1976 <fft1...@gmail.com> wrote:> On Jul 5, 11:42 pm, > Bradbev <brad.beveri...@gmail.com> wrote: > > > > more to modern x86 chips. After you have the best algorithm for the > > > job, you very quickly find that going fast is entirely bound by memory > > > speed (actually latency) - cache misses are the enemy. > > > IME (outside JVM), this depends strongly on the kind of problem you > > are solving as well as your implementation (you need to know how to > > cache-optimize). One can easily think of problems that would fit > > entirely in cache, but take an enormous amount of time. > > What sort of problems did you have in mind? Anything that I can think > of quickly spills the cache. >
For an extreme example, just about any NP-complete, NP-hard, EXP-hard problem may do. Who wins at checkers assuming perfect play: black or white? Answering this requires little memory and "lots" of time. Of course, a program does not need to fit in cache not to be memory- bound. --~--~---------~--~----~------------~-------~--~----~ 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 Note that posts from new members are moderated - please be patient with your first post. 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 -~----------~----~----~----~------~----~------~--~---