Log2 all through the kernel?
Am Mittwoch, den 10.08.2005, 16:23 +0300 schrieb Stauros Passas:
Quoted 4 lines
Accurate logarithm algorithms are costly,and I don't think are needed from kernel developers, usually a approximation is enough. So if u want something realy accurate,
u must look how it is implemented on libc.
No, I'm pretty find with a bit-shifted implementation - my question is:
Why is there not a single implementation that fits most people's needs? The way log2 functions and macros are interpersed throughout the kernel looks very spaghetti to me - everyone brewing his own one.
Wouldn't it be more sensible to supply one portable one, with bit shifts, and people with a need for O(1) timing could implement it using an array?
Quoted 11 lines
The easiest(and fastest) way to compute a logarithm (with or without base 2) is to make bit shifts.
Quoted 5 lines
Is this desirable? While it may be some reduction for special cases using a table (like in the
log2_2048function I found - it computes only a certain of log2 and multiplies this with 2048), wouldn't a more generic implementation likeceil_log2andfloor_log2not be desirable for all platforms?U can simply use the functions of
bitops.h(of asm-alpha) inline functions, removing the alpha special comands:
Well, I could, but that is not quite my point. That would be a kernel patch to just my kernel.
Wouldn't it be more wise to supply a patch providing a single implementation in the standard kernel and start converting most other log2 implementations to that one? I don't have a good feeling with everyone implementing the same, for really minimal gains.
You may say I'm more worried about software engineering practice than a really quick solution. ;)
Thanks and with kind regards,
Oliver Korpilla
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors
Quoted 3 lines · Oliver Korpilla
Wouldn't it be more sensible to supply one portable one, with bit shifts, and people with a need for O(1) timing could implement it using an array?
Send a patch to the linux-kernel mailing list and see what happens.
Erik
Signature · 2 lines
Erik Mouw [email protected] [email protected]
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors
Quoted 8 lines · Erik Mouw
Quoted 3 lines · Oliver Korpilla
Wouldn't it be more sensible to supply one portable one, with bit shifts, and people with a need for O(1) timing could implement it using an array?
Send a patch to the linux-kernel mailing list and see what happens.
Sticking a few defines in a header somewhere should do, I believe:
#define floor_log2(x) (fls(x) - 1)
#define ceil_log2(x) (fls((x) - 1)
fls() is both defined in the kernel and a gcc builtin.
Rene.
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors
Quoted 6 lines · Rene Herman
Quoted 5 lines · Erik Mouw
Quoted 3 lines · Oliver Korpilla
Wouldn't it be more sensible to supply one portable one, with bit shifts, and people with a need for O(1) timing could implement it using an array?
Quoted 6 lines
Quoted 1 line
Send a patch to the linux-kernel mailing list and see what happens.
Sticking a few defines in a header somewhere should do, I believe:
#define
floor_log2(x)(fls(x) - 1)
#defineceil_log2(x)(fls((x) - 1)
IMO, one of them should be just "log2".
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/kernel-janitors