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;
}









share|improve this question
























  • 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 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

















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;
}









share|improve this question
























  • 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 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















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;
}









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 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




















  • 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 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


















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












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 by A and Temp may be modified

  • naming

    while I like i for index without further significance, I prefer p for a pointer

    What is the significance of Z in Z1…4?

    case:

    assuming capital case OK for arrays: why N, 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 of p[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"






share|improve this answer























  • (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











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
});


}
});














draft saved

draft discarded


















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 by A and Temp may be modified

  • naming

    while I like i for index without further significance, I prefer p for a pointer

    What is the significance of Z in Z1…4?

    case:

    assuming capital case OK for arrays: why N, 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 of p[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"






share|improve this answer























  • (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















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 by A and Temp may be modified

  • naming

    while I like i for index without further significance, I prefer p for a pointer

    What is the significance of Z in Z1…4?

    case:

    assuming capital case OK for arrays: why N, 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 of p[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"






share|improve this answer























  • (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













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 by A and Temp may be modified

  • naming

    while I like i for index without further significance, I prefer p for a pointer

    What is the significance of Z in Z1…4?

    case:

    assuming capital case OK for arrays: why N, 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 of p[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"






share|improve this answer















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 by A and Temp may be modified

  • naming

    while I like i for index without further significance, I prefer p for a pointer

    What is the significance of Z in Z1…4?

    case:

    assuming capital case OK for arrays: why N, 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 of p[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"







share|improve this answer














share|improve this answer



share|improve this answer








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 between A and Temp" - 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










  • (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
















(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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Ellipse (mathématiques)

Quarter-circle Tiles

Mont Emei