[CVS ci] string_set is back for a faster live - not only
Leopold Toetsch
strings are heavily used. One examples is life.pasm, where the generate
loop does:
substr S0, S15, I3, 1
~10^6 times. Till now, S0 (the result of substr) was constructed every
time, now it get's just reused.
This improves life generations from 400/370 to both 587 for GC/malloc
allocators.
string_set is currently only used in string_substr, but, when people are
ok with this, can be used everywhere in core.ops, where a string
register is globbered.
set S0, S1 { $1 = $2 }
would become string_set(interpreter, $1, $2)
leo
Leopold Toetsch
[ substr in life.pasm ]
> ~10^6 times.
10^7
> set S0, S1 { $1 = $2 }
>
> would become string_set(interpreter, $1, $2)
Exactly this example is wrong, because here these 2 registers just point
to the same string.
leo
Peter Gibbs
> string_set is currently only used in string_substr, but, when people are
> ok with this, can be used everywhere in core.ops, where a string
> register is globbered.
The behaviour of the following program has changed, is this correct?
set S0, "test"
set S1, S0
set S2, "another"
substr S0, S2, 1, 3
print S1
print "\n"
end
--
Peter Gibbs
EmKel Systems
Leopold Toetsch
Yes you are right.
Before:
test
now:
not
The questions are (and this is IMHO the same problem with PMCs):
- set vs assign
- what should this program do
leo
Dan Sugalski
Substr should generate a new string and stick that into S0.
If we want to build a fast version that reuses a string register, I'm
fine with that--it's definitely useful in a large number of
circumstances, large enough to warrant expressing both sets of
semantics.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> Substr should generate a new string and stick that into S0.
>
> If we want to build a fast version that reuses a string register, I'm
> fine with that--it's definitely useful in a large number of
> circumstances, large enough to warrant expressing both sets of semantics.
Fine. But how do we know, which version we could take. Please read again
Peter's example. It depends on the semantics of Sx register usage all
over the program IMHO.
My version doesn't break any current test but gives ~30% increase in
life generations - yes I do know - 1): correctness, 2) speed - but what
is correct for Peter's example?
The "normal" case would be that substr (or any operation resulting in a
new Sx) should be able to reuse an existing string header. Peter's
example is a of course valid but still exception from a normal program
flow IMHO. If I (HL) want to save a SReg, I would copy (clone in PMC
terms) it.
I think, we should invest some more thoughts on an optimization with
that much potential in execution speed. DOD/GC runs aren't free, when
minimized we can gain ~30% execution speed.
And for RL (or perl6) programs, reusign PMCs would be a similar case.
leo
Peter Gibbs
> Fine. But how do we know, which version we could take. Please read again
> Peter's example. It depends on the semantics of Sx register usage all
> over the program IMHO.
In an attempt to clarify the positions here, let us start with a shorter
example:
set S0, "zero"
set S1, "one"
set S0, S1
The first line will create a new string header, which will COW-reference
the constant string data "zero", and store the address of that header
in register S0.
The second line creates another string header, COWing to "one",
and stores its address in register S1.
The third line could do any of the following:
a) Create a new string header, COW-referencing string "one",
and store that new address in register S0
b) Re-use the existing string header created in line 1, changing
it to point to string "one"; the register does not change
c) Store the address of the string header created in line 2 into
string register S0; no headers are affected in any way
The current implementation is (c).
Does anybody believe this should be different?
An extended version of my previous example follows, as it points
out some more inconsistent behaviour.
--
Peter Gibbs
EmKel Systems
set S0, "test"
set S1, S0
set S2, "another"
substr S0, S2, 1, 3
print S1
print "\n"
set S0, "test"
new P1, .PerlString
set P1, S0
set S2, "another"
substr S0, S2, 1, 3
print P1
print "\n"
set S0, "test"
new P1, .PerlArray
set P1[0], S0
set S2, "another"
substr S0, S2, 1, 3
set S3, P1[0]
print S3
print "\n"
set S0, "test"
new P1, .PerlHash
set P1["a"], S0
set S2, "another"
substr S0, S2, 1, 3
set S3, P1["a"]
print S3
print "\n"
end
Brent Dax
# The questions are (and this is IMHO the same problem with PMCs):
# - set vs assign
# - what should this program do
This idea may be totally on crack, but why do we even have S and P
registers as pointers? What if the S registers were basically just
STRING[32] and the Ps were PMC[32], and 'set' was a COW alias-everything
operation? This might boost performace, ease memory allocation, and end
poverty, disease and war.
Or not.
Whatever.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Leopold Toetsch
Printing (with string_set):
not
test
test
not
Thanks for this example:
- PerlStrings set_string does a string_copy
- PerlArray stores a PMC* and does a set_string_native, which converts
the PerlUndef to a string and does set_string i.e. string_copy
- PerlHash stores the STRING* pointer of the string.
I have an example too - dunno but doesn't look consistent to me either:
set S0, "test"
new P1, .PerlArray
set P1[0], S0
set S1, "not"
set S0, S1
set S3, P1[0]
print S3
print "\n"
set S0, "test"
new P2, .PerlString
set P2, S0
new P1, .PerlArray
set P1[0], P2
set S1, "not"
set P2, S1
set P3, P1[0]
print P3
print "\n"
set S0, "test"
new P1, .PerlHash
set P1["a"], S0
set S1, "not"
set S0, S1
set S3, P1["a"]
print S3
print "\n"
set S0, "test"
new P2, .PerlString
set P2, S0
new P1, .PerlHash
set P1["a"], P2
set S1, "not"
set P2, S1
set P3, P1["a"]
print P3
print "\n"
end
This prints (string_set is not involved here):
test
not
test
not
So the issue is still, when and how to copy a string, or
set S0, S1
a) b) or c)
leo
Leopold Toetsch
> Leopold Toetsch:
> # The questions are (and this is IMHO the same problem with PMCs):
> # - set vs assign
> # - what should this program do
>
> This idea may be totally on crack, but why do we even have S and P
> registers as pointers? What if the S registers were basically just
> STRING[32] and the Ps were PMC[32], and 'set' was a COW alias-everything
> operation? This might boost performace, ease memory allocation, and end
> poverty, disease and war.
>
> Or not.
>
> Whatever.
Interesting idea, I too had some time ago. I think, this wont work. How
to you store a PMC/STRING in an aggregate then.
leo
Leopold Toetsch
> An extended version of my previous example follows, as it points
> out some more inconsistent behaviour.
Here is a simple example, which shows inconsistent WRT strings:
set S0, "not"
set S1, S0
set S0, "ok"
print S1
print "\n"
new P0, .PerlString
set P0, "not"
set P1, P0
set P0, "ok"
print P1
print "\n"
end
not
ok
leo