> > ; >/dev/null time factor 281476419553081 > > 146.60u 0.01s 148.24r factor 281476419553081 > > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > > 1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081 > > Umh how does 'factor' relate to a FPU? > I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in > a raspberrypi, and 0.05s in a sheevaplug, here.
factor on plan 9 uses floating point heavily. rpi has floating point hardware, and the sheeva plug does not. (at least according to the nda docs on the processor i read.) > > (burncycles calculates the digits of pi using a taylor series > > expansion. it uses all the tricks in the book to generate as > > few bits of the result per cycle possible, without being verbose, > > obtuse, or off task. obviously, it was an accident. > > the very fast machines have the advantage of non-emulated > > vlongs, running amd64 kernels) > > What are these emulated vlongs? Would that mean an atom computer would run > relevantly faster i686 code over x86_64 code? i think i said the opposite. amd64 code heavily running vlongs would run faster in long (64-bit) mode. this is because since the registers are 64-bit wide, normal 64-bit arithmatic can be computed directly with machine instructions. with a 32-bit machine, the compiler needs to emulate a 64-bit operation since the registers available are not wide enough. (iirc, there were no atoms in 64-bit mode in the list.) - erik
