Maybe it's a CPU cache thing. I'm just guessing because I expect the code path you're benchmarking to be identical.

 perl -MDevel::Peek -e'$x=42; "$x"; $y = $x; Dump $y'
SV = PVIV(0x814e9a8) at 0x814d518
  REFCNT = 1
  FLAGS = (IOK,POK,pIOK,pPOK)
  IV = 42
  PV = 0x8168e70 "42"\0
  CUR = 2
  LEN = 4
[download]

update: Ieronim, the issue is that when you stringify a number, perl stores both representations in the variable.

When you copy it, perl doesn't know whether you're going to use the copies as string or numbers, so it copies the whole variable (since that should be faster than copying only one representation and converting it later).

++Joost and diotalevi. Thank you :) After reading the documentation of Devel::Peek i understood that among others there are three types of simple scalar value in Perl—PV (string), IV (integer) and PVIV (both). Of course i tried to compare the speed of them (actually, as you noticed, the speed of copying them). And I got a expected result:

       Rate PVIV   PV   IV
PVIV 2065/s   --  -1% -64%
PV   2084/s   1%   -- -64%
IV   5806/s 181% 179%   --
[download]

The difference between PV and PVIV is so small that i did not notice it in my benchmarks and thought that the numbers are CONVERTED to strings :)

The code of the benchmark is here.

Read more... (1253 Bytes)
UPD: updated according to diotalevi's note :)

---

     s;;Just-me-not-h-Ni-m-P-Ni-lm-I-ar-O-Ni;;tr?IerONim-?HAcker ?d;print

There's more than just that. Check out the nice ASCII art in B and the pretty pictures at PerlGuts Illustrated.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

It's a really interesting meditation, thanks !

it left me with one question :
when you type :

print "ARRAY: @ary2\n";                 # IV -> PVIV
[download]

it converts your IV to PVIV.

But, I would have thinked then that this :

$_ += 0 foreach @ary2;
[download]

executed on a PVIV, would keep it a PVIV. Why does it reverse it to an IV. It's a kind of rule internally ? When you make a numeric operation on a scalar, it convert it into an IV ? I mean, if there is a type which carry both (PVIV), it could have continue with it ? No ? Are there reasons other than the idea of using less memory/less timecode ?

Thanks,
Marsel

Joost, the copy was done before the benchmark. Its the operations on the copied values that's slower. I assume perl is treating both as numbers because both have the IOK flag set which also means I think both have identical code paths. I think then, the only difference is that these values are spaced out more in memory and consume more memory. To code, I expect there should be no difference. In reality, the only thing I can guess is that it has something to do with CPU caches or any of that nonsense that I'm not sure how to reason about.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

diotalevi: I didn't mean the copy at the start, but these ones in the benchmark loop:

my @permuted = @ary[0..$i-1, $j, $i+1..$j-1, $i, $j+1..$len];
# and
my @permuted = @ary;
@permuted[$i, $j] = @permuted[$j, $i];
[download]

(and the ones for @ary2, obviously)

In other words, the operation in the benchmark IS a copy operation.

"What should it profit a man, if he should win a flame war, yet lose his cool?"