> I find it particularly disturbing that merely changing the order in which 
> the bytes reside in memory produces a 50x speedup.

If you get the bytes in the "wrong" order then the CPU is going to be 
stalled the whole time waiting for fetches from normal RAM.  Get them in the 
"right" order and the CPU can whizz through at full speed, while the cache 
is updated almost in parallel from normal RAM.

> This practically guarantees that no high-level programming language can 
> ever be fast.

Surely the compiler just needs to be a bit clever about how it does stuff?

> Question: How much faster does this go on the GPU? [I'm going to stick my 
> neck out and say it'd take longer to transfer the data to the GPU than to 
> actually do the calculation.]

According to Wikipedia the PCIx bus is 1064 MB/s, but I don't know if that 
would be the limiting factor or not.

Anyway I found this:

http://graphics.stanford.edu/papers/gpumatrixmult/

It seems that an ATI X800XT can beat a P4 3GHz, but I have no idea how 
today's latest hardware would work out.

> Do any current GPUs support double-precision yet?

Not very many, only really on the ones focussed for non-graphics work.

>> Next assignment, do the same activity on the inverse matrix function :-)
>
> Hehehe, yeah... I'm guessing that's going to be a tad slower. ;-)

But also an important part of lots of simulation software.

> Well, the initial version took "only" 5 hours on a dual quad-Xeon 3.15 GHz 
> server. How slow can it possibly be on my ancient 32-bit single-core AMD 
> Athlon 1700+ 1.5 GHz? :-P

I think the initial version was only using a single core.  Also does Haskell 
do any of the optimisations at all mentioned, or is it basically going to be 
comparable performance to the initial version?

Post a reply to this message