«

Mirco Wahab schreef:
> Dr.Ruud:

>> I propose this:
>>
>> sub ruud2_2 {
>> # out: my $R = $G_bits -1 ;
>> # out: $R = qr/^((.).{$R})(.)/ ;
>>
>> my $w = $G_bits + 1 ; # window size
>> my $n = length($G_input_data) - $w ;
>>
>> for my $i ( 0 .. $n ) {
>> $_ = substr( $G_input_data, $i, $w );
>> # out: /$R/ and print " $2 -> $1 -> $3 \n" ;
>
> 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.

--
Affijn, Ruud

"Gewoon is een tijger."

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

--
Affijn, Ruud

"Gewoon is een tijger."

Mirco Wahab wrote:
> 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).

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

"Mirco Wahab" <> wrote in message
news:e5c08f$c37$...
> Thus spoke Ralph Ganszky (on 2006-05-28 10:0:
>
>
> 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

wahab- wrote:
> Thus spoke DJ Stunks (on 2006-05-27 17:51):
>
> > Mirco Wahab wrote:
> >> 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB