linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] bitreversal program
@ 2008-05-19 17:04 Soumyadip Das Mahapatra
  2008-05-19 20:42 ` Harvey Harrison
  0 siblings, 1 reply; 13+ messages in thread
From: Soumyadip Das Mahapatra @ 2008-05-19 17:04 UTC (permalink / raw)
  To: linux-kernel; +Cc: akinobu.mita

--- a/include/linux/bitrev.h    2008-04-17 08:19:44.000000000 +0530
+++ b/include/linux/bitrev.h    2008-05-19 21:49:46.000000000 +0530
@@ -3,11 +3,32 @@

  #include <linux/types.h>

-extern u8 const byte_rev_table[256];
+/**
+ * Here is a generalised bit reversal program
+ * @x: word to get bits reversed
+ * @k: key, explained below
+ * for k = 31, it reverses the bits of word(32 bit)
+ * for k = 24, it reverses the bytes in word
+ * for k = 7, it reverses the bits in every byte without
+ * changing the positions of bytes in a word
+ * and for k = 16 it swaps the left and right halves of a
+ * word
+ */

-static inline u8 bitrev8(u8 byte)
+static inline u32 gen_bit_rev(u32 x, u32 k)
  {
-       return byte_rev_table[byte];
+       if(k & 1)
+               x = (x & 0x55555555) << 1 | (x & 0xaaaaaaaa) >> 1;
+       if(k & 2)
+               x = (x & 0x33333333) << 2 | (x & 0xcccccccc) >> 2;
+       if(k & 4)
+               x = (x & 0x0f0f0f0f) << 4 | (x & 0xf0f0f0f0) >> 4;
+       if(k & 8)
+               x = (x & 0x00ff00ff) << 8 | (x & 0xff00ff00) >> 8;
+       if(k & 16)
+               x = (x & 0x0000ffff) << 16 | (x & 0xffff0000) >> 16;
+
+       return x;
  }

  extern u32 bitrev32(u32 in);

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-19 17:04 [PATCH 1/2] bitreversal program Soumyadip Das Mahapatra
@ 2008-05-19 20:42 ` Harvey Harrison
  2008-05-20  6:53   ` John Hubbard
  2008-05-20 11:01   ` Soumyadip Das Mahapatra
  0 siblings, 2 replies; 13+ messages in thread
From: Harvey Harrison @ 2008-05-19 20:42 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: linux-kernel, akinobu.mita

On Mon, 2008-05-19 at 19:04 +0200, Soumyadip Das Mahapatra wrote:
> --- a/include/linux/bitrev.h    2008-04-17 08:19:44.000000000 +0530
> +++ b/include/linux/bitrev.h    2008-05-19 21:49:46.000000000 +0530
> @@ -3,11 +3,32 @@
> 
>   #include <linux/types.h>
> 
> -extern u8 const byte_rev_table[256];
> +/**
> + * Here is a generalised bit reversal program
> + * @x: word to get bits reversed
> + * @k: key, explained below
> + * for k = 31, it reverses the bits of word(32 bit)
> + * for k = 24, it reverses the bytes in word
> + * for k = 7, it reverses the bits in every byte without
> + * changing the positions of bytes in a word
> + * and for k = 16 it swaps the left and right halves of a
> + * word
> + */
> 
> -static inline u8 bitrev8(u8 byte)

What about anybody who currently uses bitrev8?

> +static inline u32 gen_bit_rev(u32 x, u32 k)
>   {
> -       return byte_rev_table[byte];
> +       if(k & 1)
> +               x = (x & 0x55555555) << 1 | (x & 0xaaaaaaaa) >> 1;
> +       if(k & 2)
> +               x = (x & 0x33333333) << 2 | (x & 0xcccccccc) >> 2;
> +       if(k & 4)
> +               x = (x & 0x0f0f0f0f) << 4 | (x & 0xf0f0f0f0) >> 4;
> +       if(k & 8)
> +               x = (x & 0x00ff00ff) << 8 | (x & 0xff00ff00) >> 8;
> +       if(k & 16)
> +               x = (x & 0x0000ffff) << 16 | (x & 0xffff0000) >> 16;
> +
> +       return x;
>   }

Why is this better than a single 256 byte table?

Harvey


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-19 20:42 ` Harvey Harrison
@ 2008-05-20  6:53   ` John Hubbard
  2008-05-20 11:01   ` Soumyadip Das Mahapatra
  1 sibling, 0 replies; 13+ messages in thread
From: John Hubbard @ 2008-05-20  6:53 UTC (permalink / raw)
  To: Harvey Harrison; +Cc: Soumyadip Das Mahapatra, linux-kernel, akinobu.mita

Harvey Harrison wrote:

>> +static inline u32 gen_bit_rev(u32 x, u32 k)
>>   {
>> -       return byte_rev_table[byte];
>> +       if(k & 1)
>> +               x = (x & 0x55555555) << 1 | (x & 0xaaaaaaaa) >> 1;
>> +       if(k & 2)
>> +               x = (x & 0x33333333) << 2 | (x & 0xcccccccc) >> 2;
>> +       if(k & 4)
>> +               x = (x & 0x0f0f0f0f) << 4 | (x & 0xf0f0f0f0) >> 4;
>> +       if(k & 8)
>> +               x = (x & 0x00ff00ff) << 8 | (x & 0xff00ff00) >> 8;
>> +       if(k & 16)
>> +               x = (x & 0x0000ffff) << 16 | (x & 0xffff0000) >> 16;
>> +
>> +       return x;
>>   }
> 
> Why is this better than a single 256 byte table?
> 
> Harvey
> 

One reason it could be better, at least in some situations, is that the 
above is more likely to execute directly from the CPU's instruction 
cache. The table lookup appears more efficient at first, until you 
consider the memory caching hierarchy.

--John Hubbard

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-19 20:42 ` Harvey Harrison
  2008-05-20  6:53   ` John Hubbard
@ 2008-05-20 11:01   ` Soumyadip Das Mahapatra
  2008-05-20 12:13     ` Akinobu Mita
  1 sibling, 1 reply; 13+ messages in thread
From: Soumyadip Das Mahapatra @ 2008-05-20 11:01 UTC (permalink / raw)
  To: Harvey Harrison; +Cc: linux-kernel, akinobu.mita



On Mon, 19 May 2008, Harvey Harrison wrote:

> On Mon, 2008-05-19 at 19:04 +0200, Soumyadip Das Mahapatra wrote:
>> --- a/include/linux/bitrev.h    2008-04-17 08:19:44.000000000 +0530
>> +++ b/include/linux/bitrev.h    2008-05-19 21:49:46.000000000 +0530
>> @@ -3,11 +3,32 @@
>>
>>   #include <linux/types.h>
>>
>> -extern u8 const byte_rev_table[256];
>> +/**
>> + * Here is a generalised bit reversal program
>> + * @x: word to get bits reversed
>> + * @k: key, explained below
>> + * for k = 31, it reverses the bits of word(32 bit)
>> + * for k = 24, it reverses the bytes in word
>> + * for k = 7, it reverses the bits in every byte without
>> + * changing the positions of bytes in a word
>> + * and for k = 16 it swaps the left and right halves of a
>> + * word
>> + */
>>
>> -static inline u8 bitrev8(u8 byte)
>
> What about anybody who currently uses bitrev8?
>
>> +static inline u32 gen_bit_rev(u32 x, u32 k)
>>   {
>> -       return byte_rev_table[byte];
>> +       if(k & 1)
>> +               x = (x & 0x55555555) << 1 | (x & 0xaaaaaaaa) >> 1;
>> +       if(k & 2)
>> +               x = (x & 0x33333333) << 2 | (x & 0xcccccccc) >> 2;
>> +       if(k & 4)
>> +               x = (x & 0x0f0f0f0f) << 4 | (x & 0xf0f0f0f0) >> 4;
>> +       if(k & 8)
>> +               x = (x & 0x00ff00ff) << 8 | (x & 0xff00ff00) >> 8;
>> +       if(k & 16)
>> +               x = (x & 0x0000ffff) << 16 | (x & 0xffff0000) >> 16;
>> +
>> +       return x;
>>   }
>
> Why is this better than a single 256 byte table?
>
> Harvey
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

Thanks for reviewing Harvey :-)
please look at the line below
>> -static inline u8 bitrev8(u8 byte)
It is a static function, so you cant use it from outside of this
file. So there should not be anyone using this function.

>Why is this better than a single 256 byte table?

Why store those things if stuffs can be done in smoother and cleaner
(using less memeory ofcourse) way!

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 11:01   ` Soumyadip Das Mahapatra
@ 2008-05-20 12:13     ` Akinobu Mita
  2008-05-20 15:25       ` Soumyadip Das Mahapatra
  0 siblings, 1 reply; 13+ messages in thread
From: Akinobu Mita @ 2008-05-20 12:13 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: Harvey Harrison, linux-kernel

>>> -static inline u8 bitrev8(u8 byte)
>
> It is a static function, so you cant use it from outside of this
> file. So there should not be anyone using this function.
>

bitrev8() is static inline function in header file.
There are several users:

./drivers/isdn/gigaset/asyncdata.c
./drivers/isdn/gigaset/isocdata.c
./drivers/isdn/hisax/st5481_b.c
./drivers/rtc/rtc-s35390a.c
...

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 12:13     ` Akinobu Mita
@ 2008-05-20 15:25       ` Soumyadip Das Mahapatra
  2008-05-20 15:47         ` Benoit Boissinot
  2008-05-21 16:52         ` Tilman Schmidt
  0 siblings, 2 replies; 13+ messages in thread
From: Soumyadip Das Mahapatra @ 2008-05-20 15:25 UTC (permalink / raw)
  To: Akinobu Mita; +Cc: Harvey Harrison, linux-kernel

Thanks for giving a reply Akinobu :-)
I forgot that bitrev8() is static in header file. Sorry for that.

Below is my new patch considering this. Cant it be applicable?
Please review it.

I know that my bitrev8() takes more instructions than that
of yours. But we have to think about faster access of cpu cache over that
of memory cache(which your bit_rev_table uses).

Thanks anyway ;-)

---Inline Attachment---
--- a/include/linux/bitrev.h    2008-04-17 08:19:44.000000000 +0530
+++ b/include/linux/bitrev.h    2008-05-20 20:41:13.000000000 +0530
@@ -3,11 +3,49 @@

  #include <linux/types.h>

-extern u8 const byte_rev_table[256];
+/**
+ * Here is a generalised bit reversal program
+ * @x: word to get bits reversed
+ * @k: key, explained below
+ * for k = 31, it reverses the bits of word(32 bit)
+ * for k = 24, it reverses the bytes in word
+ * for k = 7, it reverses the bits in every byte without
+ * changing the positions of bytes in a word
+ * and for k = 16 it swaps the left and right halves of a
+ * word
+ */
+
+static inline u32 gen_bit_rev(u32 x, u32 k)
+{
+       if(k & 1)
+               x = (x & 0x55555555) << 1 | (x & 0xaaaaaaaa) >> 1;
+       if(k & 2)
+               x = (x & 0x33333333) << 2 | (x & 0xcccccccc) >> 2;
+       if(k & 4)
+               x = (x & 0x0f0f0f0f) << 4 | (x & 0xf0f0f0f0) >> 4;
+       if(k & 8)
+               x = (x & 0x00ff00ff) << 8 | (x & 0xff00ff00) >> 8;
+       if(k & 16)
+               x = (x & 0x0000ffff) << 16 | (x & 0xffff0000) >> 16;
+
+       return x;
+}
+
+/**
+ * bitrev8(): function for reversing bits of a byte
+ * @byte: the byte to get its bits reversed
+ */

  static inline u8 bitrev8(u8 byte)
  {
-       return byte_rev_table[byte];
+       u8 k = 7;
+       if(k & 1)
+               byte = (byte & 0x5555) << 1 | (byte & 0xaaaa) >> 1;
+       if(k & 2)
+               byte = (byte & 0x3333) << 2 | (byte & 0xcccc) >> 2;
+       if(k & 4)
+               byte = (byte & 0x0f0f) << 4 | (byte & 0xf0f0) >> 4;
+       return byte;
  }

  extern u32 bitrev32(u32 in);



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 15:25       ` Soumyadip Das Mahapatra
@ 2008-05-20 15:47         ` Benoit Boissinot
  2008-05-20 15:57           ` Soumyadip Das Mahapatra
  2008-05-21 16:52         ` Tilman Schmidt
  1 sibling, 1 reply; 13+ messages in thread
From: Benoit Boissinot @ 2008-05-20 15:47 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel

On Tue, May 20, 2008 at 5:25 PM, Soumyadip Das Mahapatra
<kernelhacker@visualserver.org> wrote:
> Thanks for giving a reply Akinobu :-)
> I forgot that bitrev8() is static in header file. Sorry for that.
>
> Below is my new patch considering this. Cant it be applicable?
> Please review it.
>
> I know that my bitrev8() takes more instructions than that
> of yours. But we have to think about faster access of cpu cache over that
> of memory cache(which your bit_rev_table uses).

I didn't review your patch, sorry.
But I'm pretty sure that your patch won't be considered unless you
provide benchmarks
with numbers for different CPU/architecture.
Ideally you should provide a script to test the correctness and the
performance of your
change that anyone could run on his computer.

regards,

Benoit

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 15:47         ` Benoit Boissinot
@ 2008-05-20 15:57           ` Soumyadip Das Mahapatra
  2008-05-20 16:39             ` Benoit Boissinot
  0 siblings, 1 reply; 13+ messages in thread
From: Soumyadip Das Mahapatra @ 2008-05-20 15:57 UTC (permalink / raw)
  To: Benoit Boissinot; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel



On Tue, 20 May 2008, Benoit Boissinot wrote:

> On Tue, May 20, 2008 at 5:25 PM, Soumyadip Das Mahapatra
> <kernelhacker@visualserver.org> wrote:
>> Thanks for giving a reply Akinobu :-)
>> I forgot that bitrev8() is static in header file. Sorry for that.
>>
>> Below is my new patch considering this. Cant it be applicable?
>> Please review it.
>>
>> I know that my bitrev8() takes more instructions than that
>> of yours. But we have to think about faster access of cpu cache over that
>> of memory cache(which your bit_rev_table uses).
>
> I didn't review your patch, sorry.
> But I'm pretty sure that your patch won't be considered unless you
> provide benchmarks
> with numbers for different CPU/architecture.
> Ideally you should provide a script to test the correctness and the
> performance of your
> change that anyone could run on his computer.

Thanks Benoit for giving me such a precious advice. But sorry, I dont
have any benchmarking system in my hand(how can i have? i am just a
student, not a professional).
So if you do me a favour and kindly do it for me, please :-)

Anyway thanks again.

Soumya

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 15:57           ` Soumyadip Das Mahapatra
@ 2008-05-20 16:39             ` Benoit Boissinot
  2008-05-21  8:54               ` Soumyadip Das Mahapatra
  0 siblings, 1 reply; 13+ messages in thread
From: Benoit Boissinot @ 2008-05-20 16:39 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel

On Tue, May 20, 2008 at 05:57:37PM +0200, Soumyadip Das Mahapatra wrote:
> On Tue, 20 May 2008, Benoit Boissinot wrote:
>> On Tue, May 20, 2008 at 5:25 PM, Soumyadip Das Mahapatra
>> <kernelhacker@visualserver.org> wrote:
>>> I know that my bitrev8() takes more instructions than that
>>> of yours. But we have to think about faster access of cpu cache over that
>>> of memory cache(which your bit_rev_table uses).
>>
>> I didn't review your patch, sorry.
>> But I'm pretty sure that your patch won't be considered unless you
>> provide benchmarks
>> with numbers for different CPU/architecture.
>> Ideally you should provide a script to test the correctness and the
>> performance of your
>> change that anyone could run on his computer.
>
> Thanks Benoit for giving me such a precious advice. But sorry, I dont
> have any benchmarking system in my hand(how can i have? i am just a
> student, not a professional).
> So if you do me a favour and kindly do it for me, please :-)

A quick benchmarking (that you should have done at least one your
computer gives for 100000000 iterations):
old:
real	0m1.631s
user	0m1.628s
sys	0m0.004s

new:
real	0m5.553s
user	0m5.540s
sys	0m0.004s

So I guess there's no need to discuss this further.

regards,

Benoit

-- 
:wq

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 16:39             ` Benoit Boissinot
@ 2008-05-21  8:54               ` Soumyadip Das Mahapatra
  2008-05-21  9:11                 ` Benoit Boissinot
  2008-05-21 11:11                 ` Rene Herman
  0 siblings, 2 replies; 13+ messages in thread
From: Soumyadip Das Mahapatra @ 2008-05-21  8:54 UTC (permalink / raw)
  To: Benoit Boissinot; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel



On Tue, 20 May 2008, Benoit Boissinot wrote:

> A quick benchmarking (that you should have done at least one your
> computer gives for 100000000 iterations):
> old:
> real	0m1.631s
> user	0m1.628s
> sys	0m0.004s
>
> new:
> real	0m5.553s
> user	0m5.540s
> sys	0m0.004s
>
> So I guess there's no need to discuss this further.

Sorry to disturb you again. But i tested my code against Akinobu's one
and the test result shows my code takes less cpu time than that of
Akinobu's.
Here is the code i used to determine performance
--
#include<stdio.h>
#include<time.h>

int main()
{
 	int i = 100000000;
 	printf("%ld\n", (long)clock());
 	for(; i>0; i--) {
 		bitrev32(0x00face32);
 	}
 	printf("%ld", (long)clock());
}
--
OUTPUT:
[using Akinobu's bitrev32()]
0
6010000

[using my bitrev32()]
0
3990000

And using bitrev8() instead of bitrev32() the result gives the output
like this:
[using Akinobu's bitrev8()]
0
770000

[using my bitrev8()]
0
2360000

My processor is 1.4 GHz one.
I am not forcing you to review my code( or i've no expectation of
inclusion of it ) but its just a curiousity: what is truth behind
the output.

Regards,
Soumya

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-21  8:54               ` Soumyadip Das Mahapatra
@ 2008-05-21  9:11                 ` Benoit Boissinot
  2008-05-21 11:11                 ` Rene Herman
  1 sibling, 0 replies; 13+ messages in thread
From: Benoit Boissinot @ 2008-05-21  9:11 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Wed, May 21, 2008 at 10:54:15AM +0200, Soumyadip Das Mahapatra wrote:
> On Tue, 20 May 2008, Benoit Boissinot wrote:
>
> Sorry to disturb you again. But i tested my code against Akinobu's one
> and the test result shows my code takes less cpu time than that of
> Akinobu's.
>
> My processor is 1.4 GHz one.
> I am not forcing you to review my code( or i've no expectation of
> inclusion of it ) but its just a curiousity: what is truth behind
> the output.

I'm using a core duo 1.2GHz, if you want to play with the code, I'm
attaching a tarball (it's hackish, just change the #include at the top
of bitrev.h to switch implementation).

I'm using gcc -Wall -O3 to compile with gcc 4.2.3.

regards,

Benoit

-- 
:wq

[-- Attachment #2: bitrev.tar.bz2 --]
[-- Type: application/octet-stream, Size: 1520 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-21  8:54               ` Soumyadip Das Mahapatra
  2008-05-21  9:11                 ` Benoit Boissinot
@ 2008-05-21 11:11                 ` Rene Herman
  1 sibling, 0 replies; 13+ messages in thread
From: Rene Herman @ 2008-05-21 11:11 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra
  Cc: Benoit Boissinot, Akinobu Mita, Harvey Harrison, linux-kernel

On 21-05-08 10:54, Soumyadip Das Mahapatra wrote:

> Sorry to disturb you again. But i tested my code against Akinobu's one
> and the test result shows my code takes less cpu time than that of
> Akinobu's.

The unfortunate thing about these kinds of changes is that they're not 
all that easily tested. Straightforwardness would suggest that obviously 
the current table driven method will be faster due to needing fewer code 
cycles. Cache considerations add to that in the sense of instruction 
cache and can (!) detract from it in the sense of data cache; sometimes 
dramaticaly detract due to cache misses basically dwarving most anything 
else.

However, in this case the table is a tiny 256-byte one which isn't even 
going to be pulled in completely in normal usage (just the cache-lines 
needed) while on the other hand the extra i-cache pressure from the 
increased code in your version is always there.

It's unexpected that you would get better results from your new code 
(and I'm not; I took Benoit's posted test and get 15 seconds for your 
version versus 9 for the original table-driven one) and in this case, 
reality wouldn't contradict the micro-benchmark either. It's when the 
table grows and, especially, more of it is needed on a regular basis 
that you'd start to worry.

PS: If you're going to go really micro, there are even going to be 
differences between bitreversing 0x00000000 which is just going to need 
the first byte (hence cacheline) and say 0x004080c0 which is going to 
occupy 4 cachelines. Again not in the isolated test though; the data in 
this case is small enough that you should be having a hard time getting 
your version to perform better -- forking off a competing process that 
does its best to dirty cache might do it, but then you're in a situation 
which is no longer real-world with respect to this "call once" bit of API...

Rene.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bitreversal program
  2008-05-20 15:25       ` Soumyadip Das Mahapatra
  2008-05-20 15:47         ` Benoit Boissinot
@ 2008-05-21 16:52         ` Tilman Schmidt
  1 sibling, 0 replies; 13+ messages in thread
From: Tilman Schmidt @ 2008-05-21 16:52 UTC (permalink / raw)
  To: Soumyadip Das Mahapatra; +Cc: Akinobu Mita, Harvey Harrison, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Am 20.05.2008 17:25 schrieb Soumyadip Das Mahapatra:
> I know that my bitrev8() takes more instructions than that
> of yours. But we have to think about faster access of cpu cache over that
> of memory cache(which your bit_rev_table uses).

bitrev8() is used on every transferred byte for certain types of
ISDN connections, ie. with a steady rate of 8000 bytes/sec.
Depending on the driver, it will be called for individual data
bytes or possibly a small number of bytes at a time, typically
not more than 64, and typically in interrupt context.

I'd expect the table driven version to perform better in those
circumstances.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2008-05-21 16:52 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-19 17:04 [PATCH 1/2] bitreversal program Soumyadip Das Mahapatra
2008-05-19 20:42 ` Harvey Harrison
2008-05-20  6:53   ` John Hubbard
2008-05-20 11:01   ` Soumyadip Das Mahapatra
2008-05-20 12:13     ` Akinobu Mita
2008-05-20 15:25       ` Soumyadip Das Mahapatra
2008-05-20 15:47         ` Benoit Boissinot
2008-05-20 15:57           ` Soumyadip Das Mahapatra
2008-05-20 16:39             ` Benoit Boissinot
2008-05-21  8:54               ` Soumyadip Das Mahapatra
2008-05-21  9:11                 ` Benoit Boissinot
2008-05-21 11:11                 ` Rene Herman
2008-05-21 16:52         ` Tilman Schmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).