Subject | RE: [IB-Architect] Next ODS change (was: System table change) |
---|---|
Author | Leyne, Sean |
Post date | 2000-11-08T00:45:12Z |
David,
An interesting post, one question though.
I'm not clear, are you saying that to you calculated a page size 1000
times (if so, what page size) or calculated the checksum, once, for a
page of 1000 characters?
If expect that it's the first case, but just want to be sure.
(Also, what speed box did you run this on? - just for purposes of
comparison)
Sean
-----Original Message-----
From: David Berg [mailto:DaveBerg@...]
Sent: Tuesday, November 07, 2000 7:38 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Next ODS change (was: System table
change)
That looks pretty simple and fast (although I wonder if unrolling the
loop
is defeating the optimizer's attempt to use LOOP and REP type code, no
matter, it's not going to make that big a difference - bigger
differences
would be making sure checksum and p are compiled as registers, and
making
sure there's no integer overflow handling code turned on).
One small problem with the algorythm is that it's marking the page as
dirty,
but that's only an issue if you're using memory mapped files, which I
assume
you're not (I've tried memory mapped files, and for my test cases they
were
always slower than managing my own IO buffers).
If something that simple is chewing up that much CPU, then that doesn't
bode
well for compression schemes. In fact, you got me curious, so I did
some
benchmarking. The following tests were run with optimization ON.
Reading
was done after writing, so the data was probably already in memory:
0.3490sec Checksum Memory Block (counter) - 1000 times
0.6820sec Checksum Memory Block (pointer) - 1000 times
0.9020sec Read Memory Block, Pointer - 1000 times
20.4130sec Write Memory Block - 1000 times
Note that I happen to know the compiler does a better job of optimizing
the
counter/index approach over the pointer approach, which is why I did
both
methods. I did not unroll the loop, and I used byte based pointers
instead
of word or long word based pointers (which would have been faster, but I
was
trying to stack the deck towards slow).
-----Original Message-----
From: Ann Harrison [mailto:harrison@...]
Sent: Tuesday, November 07, 2000 4:25 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Next ODS change (was: System table change)
or recommending a solution. The algorithm is pretty simple:
....
old_checksum = page->pag_checksum;
page->pag_checksum = 0;
p = (ULONG*) page;
checksum = 0;
do
{
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
}
while (p < end);
page->pag_checksum = old_checksum;
....
Regards,
Ann
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
An interesting post, one question though.
I'm not clear, are you saying that to you calculated a page size 1000
times (if so, what page size) or calculated the checksum, once, for a
page of 1000 characters?
If expect that it's the first case, but just want to be sure.
(Also, what speed box did you run this on? - just for purposes of
comparison)
Sean
-----Original Message-----
From: David Berg [mailto:DaveBerg@...]
Sent: Tuesday, November 07, 2000 7:38 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Next ODS change (was: System table
change)
That looks pretty simple and fast (although I wonder if unrolling the
loop
is defeating the optimizer's attempt to use LOOP and REP type code, no
matter, it's not going to make that big a difference - bigger
differences
would be making sure checksum and p are compiled as registers, and
making
sure there's no integer overflow handling code turned on).
One small problem with the algorythm is that it's marking the page as
dirty,
but that's only an issue if you're using memory mapped files, which I
assume
you're not (I've tried memory mapped files, and for my test cases they
were
always slower than managing my own IO buffers).
If something that simple is chewing up that much CPU, then that doesn't
bode
well for compression schemes. In fact, you got me curious, so I did
some
benchmarking. The following tests were run with optimization ON.
Reading
was done after writing, so the data was probably already in memory:
0.3490sec Checksum Memory Block (counter) - 1000 times
0.6820sec Checksum Memory Block (pointer) - 1000 times
0.9020sec Read Memory Block, Pointer - 1000 times
20.4130sec Write Memory Block - 1000 times
Note that I happen to know the compiler does a better job of optimizing
the
counter/index approach over the pointer approach, which is why I did
both
methods. I did not unroll the loop, and I used byte based pointers
instead
of word or long word based pointers (which would have been faster, but I
was
trying to stack the deck towards slow).
-----Original Message-----
From: Ann Harrison [mailto:harrison@...]
Sent: Tuesday, November 07, 2000 4:25 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Next ODS change (was: System table change)
>* 10% CPU time for checksums! Wow. I'd suggest a simpler checksumprobably
>algorythm <grin>, but your idea of getting rid of them entirely is
>better yet.For the record, I had nothing to do with identifying the problem
or recommending a solution. The algorithm is pretty simple:
....
old_checksum = page->pag_checksum;
page->pag_checksum = 0;
p = (ULONG*) page;
checksum = 0;
do
{
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
checksum += *p++;
}
while (p < end);
page->pag_checksum = old_checksum;
....
Regards,
Ann
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com