Front page | perl.perl5.porters |
Postings from January 2012
Re: [rt.cpan.org #73623] [perl #107326] perl's unicode conversion fails when iconv succeeds
Thread Previous
|
Thread Next
From:
Linda Walsh
Date:
January 4, 2012 13:34
Subject:
Re: [rt.cpan.org #73623] [perl #107326] perl's unicode conversion fails when iconv succeeds
Message ID:
4F04C5D6.4030500@tlinx.org
Eric Brine wrote:
> On Tue, Jan 3, 2012 at 6:09 PM, Linda Walsh <perl-diddler@tlinx.org
> <mailto:perl-diddler@tlinx.org>> wrote:
>
> If you are Networking, you used network byte order.� If you are
> doing processing
> on the same machine, you use native byte order.
>
> To do otherwise is to incur horrible inefficiencies.
>
>
> Reading UTF-16le:
>
> UV c;
> c = *(p++);
> c |= *(p++) << 8;
----
Wouldn't your target be a buffer pointer?
I.e. because you are converting from one buffer
to another? (and I always get chided for not showing
my work...)
So that , above is really *c = *(p++) ... etc...
Except that if the count is large, or greater than 4 (normal case) on
LE machines, you do 4 at a time and skip the shifts(<<) and ors(|):
if you are on a 64bit machine, then
if w=cc, (1word composed of 2 chars) and d=ww, and q=dd
if w=cc, and d=ww, then to unpack your LE string, You'd divide the length
by 8 so on a 96 meg file I like I was using, you'd
do 12million *1 store on of course you'd make sure it was aligned
on a 64-bit boundary... thus you incur no SIGBUS's that have to be
handled in hardware that slow you down.
0 SIGBUS handles/loop (done in hw on intel, but you can turn off the HW
handling and have it take a SIGBUS for any non-aligned data, and you'll
realize
how much data is pushed around unaligned, taking at least twice as long just
for the memory accesses, not counting the SIGBUS service time (even if it is
in HW)...
1 load, 1 store, and 2 adds/loop *12 million loops (96meg data)
*(q++)=*((unsigned int)q++) for any count >=8
that's 1 assign,
vs.
*(c++) = *(p++) << 8;
*(c++) |= *(p++);
*(c++) = *(p++) << 8;
*(c++) |= *(p++);
*(c++) = *(p++) << 8;
*(c++) |= *(p++);
*(c++) = *(p++) << 8;
*(c++) |= *(p++);
at least 14 SIGBUS events/loop + (1 will liekly line up on each side, but
7/8 times they won't.
vs. 8 loads and stores
+ 16 adds, + 8 shifts, masks and ors. (the mask is implicit if you are
using a character data type. -- because has to be loaded into a register
from memory first and the top 24 or 56 bits of memory (32/64 bit) have to
be masked off to get you your byte.
There might be more masks depending on the types, but lets just
call it 1,
so 8 load & stores, 16 add/loop, 16 mask and 16 ORS,
The or's mask and adds are likely close to each other in speed (
with in an order of magnitude... so 48 of those.
the 8 loads & stores
Well so far we are at 8 times as many loads and stores 700% overhead
and 48 int-ops, vs. 2, or 24 times as many, (2300% overhead),
+ SIGBUS... overhead... 14/loop .. each penalizes a load /store at least
by 2x, (has to hit 2 memory positions,
so our 8 storeloads get penalized by ***minimum*** (assuming
0 time to process the SIGBUS and just load memory), ) an extra 14/loop,
so that's really 22 v 2 = load-n-stores, or 11x, that's 1000% overhead...
so the 1000% + the intops 2300 -> 3300% overhead/loop or 35x slower.
>
> I don't see anything platform-dependent or any "horrible inefficiencies".
You don't call a 35X slowdown, or 3300% overhead 'horrible'?
Geez....
Might want to re-examine the bad code ...
Considering it has to be done for all the chars, just the 4x reduction
in loop iterations, would be a bonus., let alone removal of all those
extraneous ops...
Being able to examine code like the above is a main reason why
everyone should have basic computer science education in this day and age,
though a degree is helpful...
(though the market doesn't pay for it, cause they don't car about a 35x
slowdown).
Consumers can just wait...
Thread Previous
|
Thread Next