Re: Announcing cdrskin-0.7.2

Hi,

> As such, your original gfpow table should have had a size of
> 255 elements, not 256.

Yes. It became obvious when i unrolled it.
I had just estimated its size to produce no
buffer overflows.
The operation % 255 makes index 255 impossible.


> The smallest log is 0.  The largest is 254 (not 255).  So
> the range of sums of pairs of logs is [0-508].  So you actually need
> only 509 elements in the expanded table.

Right indeed. When i looked up the highest
value of gflog, i strayed into gfpow.


> 453        if (a == 0 || b == 0)

I will test your proposals.

Some of my own experiments yielded surprising
setbacks. E.g. i replaced
   gfpow[44 - i]
by
   h45[i]
with a suitable constant array h45[].
This was 7 percent slower !
(I suspect a less fortunate cache situation.)


> In burn_rspc_div, you return -1 if the division is by 0.

This has been replaced by a specialized
burn_rspc_div_3() which divides by (x^1+1).
Less ifs, less array lookups, but no speed-up:

/* Divides by polynomial 0x03. Derived from burn_rspc_div() */
static unsigned char burn_rspc_div_3(unsigned char a)
{
        if (a == 0)
                return 0;
        if (gflog[a] >= 25)
                return gfpow[gflog[a] - 25];
        else
                return gfpow[230 + gflog[a]];
}  

I trust in gcc -O2 that it handles the double
lookup of gfpow[a] properly.
The code swallowed far more obvious workload
improvements without showing speed reactions.


> Looking at next_bit(). 

This only had to work properly once to produce
the initial content of array ecma_130_annex_b[].
No need to make it fast or to question its
C language correctness after it produced the
same pseudo-random string as used in the old
code.


> Several functions unconditionally return 1.
> Why not define the function with a return type of "void"?

I can indeed change the type now that it is
clear that there is only one return value.

------------------------------------------------

I see some potential in parallelization.
We have at least 32 bit for exor operations.
There are two neighbored bytes multiplied by
the same byte simultaneously.

But already now a 1000 MHz CPU can easily feed
a 48x CD stream. I am not aware of faster CD
media. And this stuff is for CD only.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]