Radix Sort speed improvement
up vote
5
down vote
favorite
I was trying to optimize the Radix Sort code, because I never found a code that was simple and easy to understand yet wasn't any slower. I have seen codes on web and in some books that implement arbitrary radices such as 10 and others and also do modulo operation rather than bit-shifting. Those codes however have always been slower that their comparison based counterparts in the same language.
Since Radix Sort runs in $O(n)$ time, I built up my version of Radix Sort which is coded below in C. I choose C language because of speed, however please correct me if I'm going wrong. The code also works for negative numbers too.
I have optimized the code as far as I could go, and maybe I might have missed some more optimization techniques.
Any ideas with which I can increase the execution speed ?
Motivation for optimization:
http://codercorner.com/RadixSortRevisited.htm
http://stereopsis.com/radix.html
I was unable to implement all the optimizations in the articles, as it was beyond my skills and understanding mostly and somewhat lack of sufficient time. Other techniques not included in them or out of the box would definitely help a lot.
This is the pointer optimized version, "long" on my system is 32 bits.
long* Radix_Sort(long *A, size_t N, long *Temp)
{
long Z1[256] ;
long Z2[256] ;
long Z3[256] ;
long Z4[256] ;
long T = 0 ;
while(T != 256)
{
*(Z1+T) = 0 ;
*(Z2+T) = 0 ;
*(Z3+T) = 0 ;
*(Z4+T) = 0 ;
++T;
}
size_t Jump, Jump2, Jump3, Jump4;
// Sort-circuit set-up
Jump = *A & 255 ;
Z1[Jump] = 1;
Jump2 = (*A >> 8) & 255 ;
Z2[Jump2] = 1;
Jump3 = (*A >> 16) & 255 ;
Z3[Jump3] = 1;
Jump4 = (*A >> 24) & 255 ;
Z4[Jump4] = 1;
// Histograms creation
long *swp = A + N;
long *i = A + 1;
for( ; i != swp ; ++i)
{
++Z1[*i & 255];
++Z2[(*i >> 8) & 255];
++Z3[(*i >> 16) & 255];
++Z4[(*i >> 24) & 255];
}
// 1st LSB byte sort
if( Z1[Jump] == N );
else
{
swp = Z1+256 ;
for( i = Z1+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z1[*i & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 2nd LSB byte sort
if( Z2[Jump2] == N );
else
{
swp = Z2+256 ;
for( i = Z2+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z2[(*i >> 8) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 3rd LSB byte sort
if( Z3[Jump3] == N );
else
{
swp = Z3 + 256 ;
for( i = Z3+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z3[(*i >> 16) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 4th LSB byte sort and negative numbers sort
if( Z4[Jump4] == N );
else
{
swp = Z4 + 256 ;
for( i = Z4+129 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
*Z4 = *Z4 + *(Z4+255) ;
swp = Z4 + 128 ;
for( i = Z4+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A - 1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z4[(*i >> 24) & 255] + Temp) = *i;
}
return Temp;
}
return A;
}
performance c radix-sort
|
show 3 more comments
up vote
5
down vote
favorite
I was trying to optimize the Radix Sort code, because I never found a code that was simple and easy to understand yet wasn't any slower. I have seen codes on web and in some books that implement arbitrary radices such as 10 and others and also do modulo operation rather than bit-shifting. Those codes however have always been slower that their comparison based counterparts in the same language.
Since Radix Sort runs in $O(n)$ time, I built up my version of Radix Sort which is coded below in C. I choose C language because of speed, however please correct me if I'm going wrong. The code also works for negative numbers too.
I have optimized the code as far as I could go, and maybe I might have missed some more optimization techniques.
Any ideas with which I can increase the execution speed ?
Motivation for optimization:
http://codercorner.com/RadixSortRevisited.htm
http://stereopsis.com/radix.html
I was unable to implement all the optimizations in the articles, as it was beyond my skills and understanding mostly and somewhat lack of sufficient time. Other techniques not included in them or out of the box would definitely help a lot.
This is the pointer optimized version, "long" on my system is 32 bits.
long* Radix_Sort(long *A, size_t N, long *Temp)
{
long Z1[256] ;
long Z2[256] ;
long Z3[256] ;
long Z4[256] ;
long T = 0 ;
while(T != 256)
{
*(Z1+T) = 0 ;
*(Z2+T) = 0 ;
*(Z3+T) = 0 ;
*(Z4+T) = 0 ;
++T;
}
size_t Jump, Jump2, Jump3, Jump4;
// Sort-circuit set-up
Jump = *A & 255 ;
Z1[Jump] = 1;
Jump2 = (*A >> 8) & 255 ;
Z2[Jump2] = 1;
Jump3 = (*A >> 16) & 255 ;
Z3[Jump3] = 1;
Jump4 = (*A >> 24) & 255 ;
Z4[Jump4] = 1;
// Histograms creation
long *swp = A + N;
long *i = A + 1;
for( ; i != swp ; ++i)
{
++Z1[*i & 255];
++Z2[(*i >> 8) & 255];
++Z3[(*i >> 16) & 255];
++Z4[(*i >> 24) & 255];
}
// 1st LSB byte sort
if( Z1[Jump] == N );
else
{
swp = Z1+256 ;
for( i = Z1+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z1[*i & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 2nd LSB byte sort
if( Z2[Jump2] == N );
else
{
swp = Z2+256 ;
for( i = Z2+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z2[(*i >> 8) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 3rd LSB byte sort
if( Z3[Jump3] == N );
else
{
swp = Z3 + 256 ;
for( i = Z3+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z3[(*i >> 16) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 4th LSB byte sort and negative numbers sort
if( Z4[Jump4] == N );
else
{
swp = Z4 + 256 ;
for( i = Z4+129 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
*Z4 = *Z4 + *(Z4+255) ;
swp = Z4 + 128 ;
for( i = Z4+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A - 1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z4[(*i >> 24) & 255] + Temp) = *i;
}
return Temp;
}
return A;
}
performance c radix-sort
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
Note: sort fails withlong
as 64-bit. Good code get ported to other platforms than the ones used today.
– chux
Jul 20 '17 at 11:32
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bitlong
withlong *A
with only 4Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.
– chux
Jul 22 '17 at 16:34
|
show 3 more comments
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I was trying to optimize the Radix Sort code, because I never found a code that was simple and easy to understand yet wasn't any slower. I have seen codes on web and in some books that implement arbitrary radices such as 10 and others and also do modulo operation rather than bit-shifting. Those codes however have always been slower that their comparison based counterparts in the same language.
Since Radix Sort runs in $O(n)$ time, I built up my version of Radix Sort which is coded below in C. I choose C language because of speed, however please correct me if I'm going wrong. The code also works for negative numbers too.
I have optimized the code as far as I could go, and maybe I might have missed some more optimization techniques.
Any ideas with which I can increase the execution speed ?
Motivation for optimization:
http://codercorner.com/RadixSortRevisited.htm
http://stereopsis.com/radix.html
I was unable to implement all the optimizations in the articles, as it was beyond my skills and understanding mostly and somewhat lack of sufficient time. Other techniques not included in them or out of the box would definitely help a lot.
This is the pointer optimized version, "long" on my system is 32 bits.
long* Radix_Sort(long *A, size_t N, long *Temp)
{
long Z1[256] ;
long Z2[256] ;
long Z3[256] ;
long Z4[256] ;
long T = 0 ;
while(T != 256)
{
*(Z1+T) = 0 ;
*(Z2+T) = 0 ;
*(Z3+T) = 0 ;
*(Z4+T) = 0 ;
++T;
}
size_t Jump, Jump2, Jump3, Jump4;
// Sort-circuit set-up
Jump = *A & 255 ;
Z1[Jump] = 1;
Jump2 = (*A >> 8) & 255 ;
Z2[Jump2] = 1;
Jump3 = (*A >> 16) & 255 ;
Z3[Jump3] = 1;
Jump4 = (*A >> 24) & 255 ;
Z4[Jump4] = 1;
// Histograms creation
long *swp = A + N;
long *i = A + 1;
for( ; i != swp ; ++i)
{
++Z1[*i & 255];
++Z2[(*i >> 8) & 255];
++Z3[(*i >> 16) & 255];
++Z4[(*i >> 24) & 255];
}
// 1st LSB byte sort
if( Z1[Jump] == N );
else
{
swp = Z1+256 ;
for( i = Z1+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z1[*i & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 2nd LSB byte sort
if( Z2[Jump2] == N );
else
{
swp = Z2+256 ;
for( i = Z2+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z2[(*i >> 8) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 3rd LSB byte sort
if( Z3[Jump3] == N );
else
{
swp = Z3 + 256 ;
for( i = Z3+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z3[(*i >> 16) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 4th LSB byte sort and negative numbers sort
if( Z4[Jump4] == N );
else
{
swp = Z4 + 256 ;
for( i = Z4+129 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
*Z4 = *Z4 + *(Z4+255) ;
swp = Z4 + 128 ;
for( i = Z4+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A - 1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z4[(*i >> 24) & 255] + Temp) = *i;
}
return Temp;
}
return A;
}
performance c radix-sort
I was trying to optimize the Radix Sort code, because I never found a code that was simple and easy to understand yet wasn't any slower. I have seen codes on web and in some books that implement arbitrary radices such as 10 and others and also do modulo operation rather than bit-shifting. Those codes however have always been slower that their comparison based counterparts in the same language.
Since Radix Sort runs in $O(n)$ time, I built up my version of Radix Sort which is coded below in C. I choose C language because of speed, however please correct me if I'm going wrong. The code also works for negative numbers too.
I have optimized the code as far as I could go, and maybe I might have missed some more optimization techniques.
Any ideas with which I can increase the execution speed ?
Motivation for optimization:
http://codercorner.com/RadixSortRevisited.htm
http://stereopsis.com/radix.html
I was unable to implement all the optimizations in the articles, as it was beyond my skills and understanding mostly and somewhat lack of sufficient time. Other techniques not included in them or out of the box would definitely help a lot.
This is the pointer optimized version, "long" on my system is 32 bits.
long* Radix_Sort(long *A, size_t N, long *Temp)
{
long Z1[256] ;
long Z2[256] ;
long Z3[256] ;
long Z4[256] ;
long T = 0 ;
while(T != 256)
{
*(Z1+T) = 0 ;
*(Z2+T) = 0 ;
*(Z3+T) = 0 ;
*(Z4+T) = 0 ;
++T;
}
size_t Jump, Jump2, Jump3, Jump4;
// Sort-circuit set-up
Jump = *A & 255 ;
Z1[Jump] = 1;
Jump2 = (*A >> 8) & 255 ;
Z2[Jump2] = 1;
Jump3 = (*A >> 16) & 255 ;
Z3[Jump3] = 1;
Jump4 = (*A >> 24) & 255 ;
Z4[Jump4] = 1;
// Histograms creation
long *swp = A + N;
long *i = A + 1;
for( ; i != swp ; ++i)
{
++Z1[*i & 255];
++Z2[(*i >> 8) & 255];
++Z3[(*i >> 16) & 255];
++Z4[(*i >> 24) & 255];
}
// 1st LSB byte sort
if( Z1[Jump] == N );
else
{
swp = Z1+256 ;
for( i = Z1+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z1[*i & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 2nd LSB byte sort
if( Z2[Jump2] == N );
else
{
swp = Z2+256 ;
for( i = Z2+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z2[(*i >> 8) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 3rd LSB byte sort
if( Z3[Jump3] == N );
else
{
swp = Z3 + 256 ;
for( i = Z3+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A-1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z3[(*i >> 16) & 255] + Temp) = *i;
}
swp = A;
A = Temp;
Temp = swp;
}
// 4th LSB byte sort and negative numbers sort
if( Z4[Jump4] == N );
else
{
swp = Z4 + 256 ;
for( i = Z4+129 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
*Z4 = *Z4 + *(Z4+255) ;
swp = Z4 + 128 ;
for( i = Z4+1 ; i != swp ; ++i )
{
*i = *(i-1) + *i;
}
swp = A - 1;
for( i = A+N-1 ; i != swp ; --i )
{
*(--Z4[(*i >> 24) & 255] + Temp) = *i;
}
return Temp;
}
return A;
}
performance c radix-sort
performance c radix-sort
edited Jul 16 '17 at 18:57
alecxe
14.6k53377
14.6k53377
asked Jul 16 '17 at 18:44
ytoamn
262
262
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
Note: sort fails withlong
as 64-bit. Good code get ported to other platforms than the ones used today.
– chux
Jul 20 '17 at 11:32
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bitlong
withlong *A
with only 4Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.
– chux
Jul 22 '17 at 16:34
|
show 3 more comments
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
Note: sort fails withlong
as 64-bit. Good code get ported to other platforms than the ones used today.
– chux
Jul 20 '17 at 11:32
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bitlong
withlong *A
with only 4Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.
– chux
Jul 22 '17 at 16:34
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
Note: sort fails with
long
as 64-bit. Good code get ported to other platforms than the ones used today.– chux
Jul 20 '17 at 11:32
Note: sort fails with
long
as 64-bit. Good code get ported to other platforms than the ones used today.– chux
Jul 20 '17 at 11:32
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bit
long
with long *A
with only 4 Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.– chux
Jul 22 '17 at 16:34
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bit
long
with long *A
with only 4 Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.– chux
Jul 22 '17 at 16:34
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
2
down vote
I never found a code that was simple and easy to understand yet wasn't any slower
Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.
No slower than what? A "well known implementation" for reference and as a base-line would be useful.
Things I liked:
- "non-obvious" code blocks are commented
(short-circuit set-up
,negative numbers sort
) - trying to keep the number of passes low
- handling of negative numbers via histogram instead of value manipulation
Dislikes (beyond missing doc comments):
- not declaring the size parameter
const N
this would at least hint that the memory pointed to byA
andTemp
may be modified - naming
while I likei
for index without further significance, I preferp
for a pointer
What is the significance ofZ
inZ1…4
?
case:
assuming capital case OK for arrays: whyN
,T
,Jump1…4
? - naked literals (beyond 0±1)
- repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between - zeroing memory with open code - use
memset(destination, 0, count)
- "empty then" instead of inverting the condition
*(p+e)
instead ofp[e]
(let alone*(e+p)
) - without revisiting the standard, I would have denied this was well defined.)- updating a counter using increment/decrement
I think of those operations as next/previous and use+= 1
(-= 1
) for numerical adjustment - not using an explicit variable (histogram handling, mostly)
- re. speed: not special-casing "small" arrays
Things I don't want to presume warranted:
- bit operations preferred to
ldiv_t ldiv()
- bit operations using compile time constants over using parameters (would allow factoring out)
- "walking memory backwards" as fast as "forwards"
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap betweenA
andTemp
" - one should at least check for NULL/&equality.)
– greybeard
Apr 6 at 8:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f169418%2fradix-sort-speed-improvement%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
I never found a code that was simple and easy to understand yet wasn't any slower
Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.
No slower than what? A "well known implementation" for reference and as a base-line would be useful.
Things I liked:
- "non-obvious" code blocks are commented
(short-circuit set-up
,negative numbers sort
) - trying to keep the number of passes low
- handling of negative numbers via histogram instead of value manipulation
Dislikes (beyond missing doc comments):
- not declaring the size parameter
const N
this would at least hint that the memory pointed to byA
andTemp
may be modified - naming
while I likei
for index without further significance, I preferp
for a pointer
What is the significance ofZ
inZ1…4
?
case:
assuming capital case OK for arrays: whyN
,T
,Jump1…4
? - naked literals (beyond 0±1)
- repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between - zeroing memory with open code - use
memset(destination, 0, count)
- "empty then" instead of inverting the condition
*(p+e)
instead ofp[e]
(let alone*(e+p)
) - without revisiting the standard, I would have denied this was well defined.)- updating a counter using increment/decrement
I think of those operations as next/previous and use+= 1
(-= 1
) for numerical adjustment - not using an explicit variable (histogram handling, mostly)
- re. speed: not special-casing "small" arrays
Things I don't want to presume warranted:
- bit operations preferred to
ldiv_t ldiv()
- bit operations using compile time constants over using parameters (would allow factoring out)
- "walking memory backwards" as fast as "forwards"
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap betweenA
andTemp
" - one should at least check for NULL/&equality.)
– greybeard
Apr 6 at 8:10
add a comment |
up vote
2
down vote
I never found a code that was simple and easy to understand yet wasn't any slower
Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.
No slower than what? A "well known implementation" for reference and as a base-line would be useful.
Things I liked:
- "non-obvious" code blocks are commented
(short-circuit set-up
,negative numbers sort
) - trying to keep the number of passes low
- handling of negative numbers via histogram instead of value manipulation
Dislikes (beyond missing doc comments):
- not declaring the size parameter
const N
this would at least hint that the memory pointed to byA
andTemp
may be modified - naming
while I likei
for index without further significance, I preferp
for a pointer
What is the significance ofZ
inZ1…4
?
case:
assuming capital case OK for arrays: whyN
,T
,Jump1…4
? - naked literals (beyond 0±1)
- repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between - zeroing memory with open code - use
memset(destination, 0, count)
- "empty then" instead of inverting the condition
*(p+e)
instead ofp[e]
(let alone*(e+p)
) - without revisiting the standard, I would have denied this was well defined.)- updating a counter using increment/decrement
I think of those operations as next/previous and use+= 1
(-= 1
) for numerical adjustment - not using an explicit variable (histogram handling, mostly)
- re. speed: not special-casing "small" arrays
Things I don't want to presume warranted:
- bit operations preferred to
ldiv_t ldiv()
- bit operations using compile time constants over using parameters (would allow factoring out)
- "walking memory backwards" as fast as "forwards"
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap betweenA
andTemp
" - one should at least check for NULL/&equality.)
– greybeard
Apr 6 at 8:10
add a comment |
up vote
2
down vote
up vote
2
down vote
I never found a code that was simple and easy to understand yet wasn't any slower
Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.
No slower than what? A "well known implementation" for reference and as a base-line would be useful.
Things I liked:
- "non-obvious" code blocks are commented
(short-circuit set-up
,negative numbers sort
) - trying to keep the number of passes low
- handling of negative numbers via histogram instead of value manipulation
Dislikes (beyond missing doc comments):
- not declaring the size parameter
const N
this would at least hint that the memory pointed to byA
andTemp
may be modified - naming
while I likei
for index without further significance, I preferp
for a pointer
What is the significance ofZ
inZ1…4
?
case:
assuming capital case OK for arrays: whyN
,T
,Jump1…4
? - naked literals (beyond 0±1)
- repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between - zeroing memory with open code - use
memset(destination, 0, count)
- "empty then" instead of inverting the condition
*(p+e)
instead ofp[e]
(let alone*(e+p)
) - without revisiting the standard, I would have denied this was well defined.)- updating a counter using increment/decrement
I think of those operations as next/previous and use+= 1
(-= 1
) for numerical adjustment - not using an explicit variable (histogram handling, mostly)
- re. speed: not special-casing "small" arrays
Things I don't want to presume warranted:
- bit operations preferred to
ldiv_t ldiv()
- bit operations using compile time constants over using parameters (would allow factoring out)
- "walking memory backwards" as fast as "forwards"
I never found a code that was simple and easy to understand yet wasn't any slower
Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.
No slower than what? A "well known implementation" for reference and as a base-line would be useful.
Things I liked:
- "non-obvious" code blocks are commented
(short-circuit set-up
,negative numbers sort
) - trying to keep the number of passes low
- handling of negative numbers via histogram instead of value manipulation
Dislikes (beyond missing doc comments):
- not declaring the size parameter
const N
this would at least hint that the memory pointed to byA
andTemp
may be modified - naming
while I likei
for index without further significance, I preferp
for a pointer
What is the significance ofZ
inZ1…4
?
case:
assuming capital case OK for arrays: whyN
,T
,Jump1…4
? - naked literals (beyond 0±1)
- repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between - zeroing memory with open code - use
memset(destination, 0, count)
- "empty then" instead of inverting the condition
*(p+e)
instead ofp[e]
(let alone*(e+p)
) - without revisiting the standard, I would have denied this was well defined.)- updating a counter using increment/decrement
I think of those operations as next/previous and use+= 1
(-= 1
) for numerical adjustment - not using an explicit variable (histogram handling, mostly)
- re. speed: not special-casing "small" arrays
Things I don't want to presume warranted:
- bit operations preferred to
ldiv_t ldiv()
- bit operations using compile time constants over using parameters (would allow factoring out)
- "walking memory backwards" as fast as "forwards"
edited 1 hour ago
albert
1371
1371
answered Apr 6 at 7:42
greybeard
1,3491521
1,3491521
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap betweenA
andTemp
" - one should at least check for NULL/&equality.)
– greybeard
Apr 6 at 8:10
add a comment |
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap betweenA
andTemp
" - one should at least check for NULL/&equality.)
– greybeard
Apr 6 at 8:10
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Ran out of time - not finished/polished)
– greybeard
Apr 6 at 7:42
(Dang. Wanted to have looked up how to checl "overlap between
A
and Temp
" - one should at least check for NULL/&equality.)– greybeard
Apr 6 at 8:10
(Dang. Wanted to have looked up how to checl "overlap between
A
and Temp
" - one should at least check for NULL/&equality.)– greybeard
Apr 6 at 8:10
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f169418%2fradix-sort-speed-improvement%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Note: Why is Radix Sort O(n)? goes into some details about the O() for radix sort.
– chux
Jul 17 '17 at 15:04
@chux Radix Sort takes O( d(n+k) ) where "d" is number of digits as per the base "k" in the maximum value in the list, typically "d" is 4 for 32 bit numbers as 4 passes are performed ( if K is 256 ), clever implementations will skip passes if all nth LSBs are same, "d" depends on K, in order to fit the histogram in L1 cache K is often taken 256, so if n is >= 200 then only Radix Sort will run in O(n) time. For arrays of small sizes, it will run in O(nlogn) or even worse O(n2). The "K" has to be chosen carefully. This is only for 32-bit numbers. You can extend the same analysis to 64-bits too.
– ytoamn
Jul 20 '17 at 5:32
Note: sort fails with
long
as 64-bit. Good code get ported to other platforms than the ones used today.– chux
Jul 20 '17 at 11:32
@chux You say today's code aren't good enough ? Why ? and it would fail for 64 bits ? How ? Instead of making claims without backed up proofs, at least contribute to the knowledge, share such codes if you know them, otherwise whats the use of hankering all that knowledge ? Post relevant comments that would help get an answer, otherwise no need for you to review.
– ytoamn
Jul 22 '17 at 14:48
Post requests an increase in the execution speed (assuming 32-bit) and not a portability review. Given that viewers of this code may not see that code fails with a 64-bit
long
withlong *A
with only 4Z
arrays, I felt a small note to high-light that ancillary concern was sufficient. Should a portability review be desired, recommended that post is amended to include that goal.– chux
Jul 22 '17 at 16:34