|
in reply to Re^6: Faster Luhn Check Digit Calculation?
in thread Faster Luhn Check Digit Calculation?
Looks fat to me ( just kidding :)
Is this any faster? Or does the compiler optimize away the differences?
int l[] = {
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
int
c_luhn2( char *s ) {
return ((
l[ (int)s[ 0] ]
+ s[ 1]
+ l[ (int)s[ 2] ]
+ s[ 3]
+ l[ (int)s[ 4] ]
+ s[ 5]
+ l[ (int)s[ 6] ]
+ s[ 7]
+ l[ (int)s[ 8] ]
+ s[ 9]
+ l[ (int)s[10] ]
+ s[11]
+ l[ (int)s[12] ]
+ s[13]
+ l[ (int)s[14] ] - 7 * '0' ) * 9) % 10;
}
|
Re^8: Faster Luhn Check Digit Calculation?
by BrowserUk (Patriarch) on Dec 02, 2018 at 07:45 UTC
|
The optomiser eliminates any differences. Yours (c_luhn3 below) can be slightly faster one run and slightly slower on the next; but the difference is less that 0.5% either way:
#! perl -slw
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C', NAME => '_luhn', CLEAN_AFTER_BUILD =>0;
int c_luhn( char *s ) {
int i, total = 0;
for( i=0; i < 15; ++i ) {
int d = s[ i ] - '0';
if( !( i & 1 ) ) {
d *= 2;
if( d > 9 ) d -= 9;
}
total += d;
}
total *= 9;
return total % 10;
}
int l[] = { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
int c_luhn2( char *s ) {
int total = 0;
total += l[ s[ 0] - '0' ];
total += s[ 1] - '0';
total += l[ s[ 2] - '0' ];
total += s[ 3] - '0';
total += l[ s[ 4] - '0' ];
total += s[ 5] - '0';
total += l[ s[ 6] - '0' ];
total += s[ 7] - '0';
total += l[ s[ 8] - '0' ];
total += s[ 9] - '0';
total += l[ s[10] - '0' ];
total += s[11] - '0';
total += l[ s[12] - '0' ];
total += s[13] - '0';
total += l[ s[14] - '0' ];
total *= 9;
return total % 10;
}
int ll[] = {
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
int
c_luhn3( char *s ) {
return ((
ll[ (int)s[ 0] ]
+ s[ 1]
+ ll[ (int)s[ 2] ]
+ s[ 3]
+ ll[ (int)s[ 4] ]
+ s[ 5]
+ ll[ (int)s[ 6] ]
+ s[ 7]
+ ll[ (int)s[ 8] ]
+ s[ 9]
+ ll[ (int)s[10] ]
+ s[11]
+ ll[ (int)s[12] ]
+ s[13]
+ ll[ (int)s[14] ] - 7 * '0' ) * 9) % 10;
}
END_C
use Time::HiRes qw[ time ];
my @samples = qw[
4011350000000008
4011350000000016
4011350000000024
4011350000000032
4011350000000040
4011350000000057
4011350000000065
4011350000000073
4011350000000081
4011350000000099
];
sub luhn {
use integer;
my $s = $_[ 0 ];
my $total = 0;
for my $i ( 0 .. 14 ) {
my $d = substr( $s, $i, 1 );
unless( $i & 1 ) {
$d *= 2;
$d -= 9 if $d > 9;
}
$total += $d;
}
$total *= 9;
return chop $total;
}
for ( @samples ) {
print "$_: ", luhn( substr $_, 0, 15 );
}
my $start = time;
#for ( 401135000000000..401135000999999 ) {
# my $chk = luhn( $_ );
#}
#printf "Took %.9f seconds.\n", time() - $start;
#for ( @samples ) {
# print "$_: ", c_luhn( $_ );
#}
$start = time;
for ( 401135000000000..401135000999999 ) {
my $chk = c_luhn( $_ );
}
printf "Took %.9f seconds.\n", time() - $start;
for ( @samples ) {
print "$_: ", c_luhn2( $_ );
}
$start = time;
for ( 401135000000000..401135000999999 ) {
my $chk = c_luhn2( $_ );
}
printf "Took %.9f seconds.\n", time() - $start;
for ( @samples ) {
print "$_: ", c_luhn3( $_ );
}
$start = time;
for ( 401135000000000..401135000999999 ) {
my $chk = c_luhn3( $_ );
}
printf "Took %.9f seconds.\n", time() - $start;
C:\test>luhn
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.751899958 seconds.
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.695394039 seconds.
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.693738222 seconds.
C:\test>luhn
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.751657963 seconds.
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.694734097 seconds.
4011350000000008: 8
4011350000000016: 6
4011350000000024: 4
4011350000000032: 2
4011350000000040: 0
4011350000000057: 7
4011350000000065: 5
4011350000000073: 3
4011350000000081: 1
4011350000000099: 9
Took 0.697062969 seconds.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit | [reply]
[d/l]
[select] |
|
|
At least according to godbolt.org, the three routines don't get folded into the same assembly code. What's (somewhat) interesting is that gcc and clang create different addressing modes for the accesses, so it might be worth to switch between compilers and compiler versions if calculating the check digits was material to the program operation.
| [reply] |
|
|
At least according to godbolt.org, the three routines don't get folded into the same assembly code.
I didn't really expect that they would be; but the empirical evidence is that they take the same amount of time. The routine is now so stripped down to the essentials that the calling overheads are beginning to dominate.
For example, the OPs original test code used a numeric range for testing:401135000000000..401135000999999 which I just copy&pasted. That means that every call to the function carries the overhead of converting those integers to strings. Switching the range to strings: '401135000000000' .. '401135000999999' avoids that conversion and saves more time than tybalt's optimisations.
Other changes that would require knowledge of how that code is used are also more likely to affect the performance. Eg. If the code's purpose is to verify existing CC numbers (rather than constructing new ones) then is is likely that the 16-digits strings are being read from a file or DB. Then the 16-digits are truncated to 15, passed into the routine, the checkdigit is calculated and returned and that is then compared against the 16th digit of the input.
If the routine was rewritten to accept the 16 digits and return a boolean indicating T/F then several operations external to the routine could be eliminated and overall throughput improved even though the function itself might be a little slower.
Only the OP can decide what comes next.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply]
[d/l]
[select] |
|
|
|
|
Re^8: Faster Luhn Check Digit Calculation? (Ignore this!)
by BrowserUk (Patriarch) on Dec 02, 2018 at 15:09 UTC
|
Update:Ignore this! It doesn't stand up to syphilis's scrutiny. (It only works for the OPs limited test range by luck!)
Looks fat to me ( just kidding :)
If its skinny you want, try this for (its lack of) size :)
Correct results and 35% faster to boot:
int lookup[] = { 8, 6, 4, 2, 0, 7, 5, 3, 1, 9, 7, 5, 3, 1, 9, 6, 4, 2,
+ 0 };
int c_fluhn( int n ) {
return lookup[ n % 20 ];
}
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit | [reply]
[d/l] |
|
|
Very nice. Unfortunately, Algorithm::LUHN supports some odd inputs, like non-numeric strings (See their docs).
| [reply] |
|
|
Algorithm::LUHN supports some odd inputs
That module may attempt to extend the purpose and use of the algorithm to inputs for which it was never designed; but in doing so, it invalidates itself and the algorithm.
Ie. The purpose of the algorithm is to catch 2 digit transposition errors in numeric identifiers; trying to extend that mathematics to non-numerics invalidates that purpose.
Eg. The use of Mod 9, on alpha data that has a 26 character alphabet means that some (34% of) combinations of 2-digits transpositions will not be detected.
Rules to live by:Don't perpetuate other people's bullshit.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
|
|
> Unfortunately, Algorithm::LUHN supports some odd inputs, like non-numeric strings
Careful, is this algorithm well defined for input >=10 !?!
From the docs:
> For example, Standard & Poor's maps A..Z to 10..35 so the LIST to add these valid characters would be (A, 10, B, 11, C, 12, ...)
provided B=11 is on an odd position, what's the formula now to reduce 2*11?
cross total is 4, but 22-9 =13
and if it's even does 11 stay 11 with cross total 2 or do you take it module 10 hence resulting in 1?
| [reply] |
|
|
|
|
|
|
|
