more efficient shift register?

[Dr.Ruud]

Mirco Wahab schreef:

Dr.Ruud:

Bt you have than at least to invoke
the regex, in order to provide the data:
for my $i ( 0 .. $n ) {
$_ = substr( $G_input_data, $i, $w );
/$R/ and 1;
# out: /$R/ and print " $2 -> $1 -> $3 \n" ;
}

which makes it slow again.

Well, the output-data is already in $_ (just not expanded).
So it depends on whether the exact format is in the specs.
If so, what is the most efficient way to transform the
literal string '12345' into '1 -> 1234 -> 5'?

PS. I like this discussion very much
and learned a lot from it.
(Thanks to all involved!)

Yes, such exercises are nice to be involved in.

 

[Dr.Ruud]

Dr.Ruud schreef:

what is the most efficient way to transform the
literal string '12345' into '1 -> 1234 -> 5'?

Variants:
perl -e '
($,, $\) = (" -> ", "\n") ;
print unpack("AXA4A", "12345")
'

perl -e '
($", $\) = (" -> ", "\n") ;
$output = "@{[unpack(q{AXA4A}, q{12345})]}" ;
print $output ;
'


I tried to isolate the last character of a numberstring with sprintf,
but didn't succeed:

perl -e '
$b = 4;
printf "%2\$.1s -> %2\$.*s -> %2\$s\n", $b, "12345"
'

1 -> 1234 -> 12345


Another variant:

perl -e '
$, = " -> " ;
$b = 4;
$r = qr/(?=(.))(.{$b})(?=(.))/ ;
$_ = "12345" ;
print /$r/
'

 

[DJ Stunks]

BTW, I adjusted the code to give the OP's output
an timed it again (64KB string this time):

When invoking the Regex in ruud2_2*, I get:
[2 times]
Rate krahn peavy ruud2_2 ruud2_1 original wahab
krahn 6.07/s -- -20% -52% -62% -63% -77%
peavy 7.59/s 25% -- -39% -52% -54% -72%
ruud2_2* 12.5/s 106% 65% -- -21% -25% -53%
ruud2_1 15.9/s 162% 109% 27% -- -4% -41%
original 16.6/s 174% 119% 33% 5% -- -38%
wahab 26.8/s 342% 254% 114% 69% 61% --

Mirco

PS. I like this discussion very much
and learned a lot from it.
(Thanks to all involved!)

well something is still definitely way off.... are you telling me you
can only run these subroutines between 6 and 26 times per second? look
at my benchmark - the peavy() subroutine ran 34,000 times per second.
or are you running on this on your ADAM II with 64k of RAM?

I haven't been following the myriad changes in this thread, but you
must ensure that each subroutine initializes their own variables if
that's what their custom solutions require - a global $shift_register =
'0000' skews the results significantly if the peavy() subroutine must
re-initialize every time. I think the only globals in a benchmark
should be the bare minimum of data to scope the problem (in this case
@input_data and $size_of_SR) and the rest should be left to the
subroutines in order to get a valid result.

-jp

PS - I doubt if a regex solution would be the fastest solution very
often - there's a lot of overhead associated with the regular
expression engine. Regex's are a powerful and important part of Perl
and other contemporary languages, but they're not a panacea. If one
can solve the problem using another method one should usually do so (if
speed is of concern).

 

[Ralph Ganszky]

Hi,

try the following inner loop:

$output_data = chop($shift_register);
$shift_register = sprintf("%4.4s", $input_data . $shift_register);

I think it is much more readable than the fastest implementations and by the
way it is very funny that sprintf(.., $a . $b) is much faster than $a . $b
itself, at least on my Perl implementation 5.8.7.

Regards
Ralph

 

[Ralph Ganszky]

Thus spoke Ralph Ganszky (on 2006-05-28 10:08):


From your results, one could conclude you are most
probably using 'non X64'-Athlon (or Pentium) under
Windows ;-)

Yes you are wright. I'm running Perl on a VMWare with Windows XP on a
Pentium 4.
But do you understand the difference between the original posted code and my
code in runtime?
I don't, espeacially with your results on Linux.

Regards
Ralph

 

[xhoster]

Thus spoke DJ Stunks (on 2006-05-27 17:51):

BTW, I adjusted the code to give the OP's output
an timed it again (64KB string this time):

When invoking the Regex in ruud2_2*, I get:
[2 times]
Rate krahn peavy ruud2_2 ruud2_1 original
wahab krahn 6.07/s -- -20% -52% -62% -63%
-77% peavy 7.59/s 25% -- -39% -52% -54%
-72% ruud2_2* 12.5/s 106% 65% -- -21% -25%
-53% ruud2_1 15.9/s 162% 109% 27% -- -4%
-41% original 16.6/s 174% 119% 33% 5% --
-38% wahab 26.8/s 342% 254% 114% 69% 61%
--

well something is still definitely way off.... are you telling me you
can only run these subroutines between 6 and 26 times per second? look
at my benchmark - the peavy() subroutine ran 34,000 times per second.
or are you running on this on your ADAM II with 64k of RAM?

No. Initially we did run these tests on strings of
24 bytes (or the like). These results should,
therefore, mostly measure initialization overhead.

Now we run the tests on a character stream of
*65,500 bytes*, which gives (imho) much more
insights.

I still fail to see the point of any of this, other than pure academic
interest. If you are actually going to print the output, why not
include that printing in the benchmark? OTOH, if you are not going to
print the output, why demand that the nonexistent output be formatted in a
certain way?

Why test for 65,500 bytes of input but only 4 bytes of shift-register?

Xho