From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 26 Jan 2013 14:18:38 +0100 From: =?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130126131838.GO2324@vicerveza.homeunix.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> <20130126115921.GN2324@vicerveza.homeunix.net> <2e57f08dc5638296a1c526f518b45770@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2e57f08dc5638296a1c526f518b45770@brasstown.quanstro.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0f2a4f78-ead8-11e9-9d60-3106f5b1d025 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 > >=20 > > 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. >=20 > 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 situati= ons can happen with code that uses floating point operations: - run code with FPU instructions, emulated by the kernel through exceptio= ns - 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) > >=20 > > What are these emulated vlongs? Would that mean an atom computer woul= d run > > relevantly faster i686 code over x86_64 code? >=20 > i think i said the opposite. amd64 code heavily running vlongs > would run faster in long (64-bit) mode. this is because since the regi= sters > 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 wid= e > enough. >=20 > (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 to= o slow microcode or something like that. Best regards, Llu=EDs.