Messages in this thread | | | From | Denys Vlasenko <> | Subject | Re: [PATCH 1/1] vsprintf: optimize decimal conversion (again) | Date | Tue, 27 Mar 2012 02:30:35 +0200 |
| |
On Tuesday 27 March 2012 01:18, Denys Vlasenko wrote: > > I don't think Linux runs on anything with BITS_PER_LONG_LONG != 64... > > > > BTW, what about CPUs with slow 32x32 multiplication and/or slow 64-bit > > division? > > Without 32x32->64 multiply, the best we can generate is 4 decimal digits: > we produce next digit by approximating x/10 with (x * 0xcccd) >> 19, > and the first x where it gives wrong result is 81920 if multiply result > is truncated to 32 bits. > With it, we can generate 9 digits using (x * 0x1999999a) >> 32. > > Regrading "slow 64-bit division" - after this patch, 32-bit machines > wouldn't use it at all. Only 64-bit machines will perform 64-bit > division, one per 9 decimal digits (thus, at most three divisions > per one long_long->string conversion). > > In fact, with small change to #ifdefs, all machines with long long <= 64 > bits can use division-less routine. It might be a good thing to try...
Well, apparently it's not a good idea for my Phenom II in 64-bit mode: It's bigger:
text data bss dec hex filename 2395 448 0 2843 b1b test_div64.o 2507 448 0 2955 b8b test_nodiv.o
And slower: Conversions per second: div64: 8:42660000 123:31472000 123456:21748000 12345678:19140000 123456789:20980000 2^32:16948000 2^64:9480000 nodiv: 8:40532000 123:30276000 123456:21172000 12345678:18672000 123456789:13440000 2^32:13440000 2^64:8992000
-- vda
| |