On Sat, Jan 26, 2013 at 07:12:50AM -0500, erik quanstrom wrote: > > > ; >/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.)
Ah, all clear. Thank you! I just thought of some discrepancy that can happen around linux/gnu, that could be applied in your example. On a processor without FPU, these two situations can happen with code that uses floating point operations: - run code with FPU instructions, emulated by the kernel through exceptions - run code compiled without FPU instructions, with floating point as non-FPU code. The former runs quite slower than the latter. > > > (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.) Ok, thank you very much! I understood as if you had listed a 64-bit mode atom, and these having some peculiar implementation of 64-bit operations (as too slow microcode or something like that. Best regards, Lluís.
