Front page | perl.perl5.porters |
Postings from March 2000
At 01:01 PM 3/31/00 -0700, Joseph N. Hall wrote:
>On Fri, 31 Mar 2000 14:42:52 -0500 dan@sidhe.org (Dan Sugalski) wrote:
>
>* At 12:26 PM 3/31/00 -0700, Joseph N. Hall wrote:
>* >I'm not completely convinced that adding markers to the bytecode
>* >stream to indicate when run-time interpolation is in effect is such
>* >a bad idea. It might allow finer-grained control over interpolation
>* >(with overload? or?) as well as more accurate Deparse, both of which
>* >might turn out to be quite valuable. Just to resolve the problem
>* >with the warning message, though, it's way too much work.
>*
>* An added field could be thrown into the opcodes, but the problem with that
>* is the opcodes take even more memory than they used to. They keep getting
>* bigger, and I think we're seeing slowdowns as it is from larger opcodes.
>* (The bigger they are the fewer fit in a page or the processor cache, though
>* we're pretty profligate with D-space as it is)
>
>I doubt that is really a problem for the ages, though. In the near
>future, if not now, caches will be large and/or capable enough that
>cache busting really isn't something to design against. Nevermind
>that there is one Perl and a zillion different cache architectures.
Ick. No offense but I absolutely loathe that particular attitude. I've got
a VAXStation II/GPX (with a whopping 1/3 VUPs of power) around that I like
to work on when I've got time--if things run OK there they should run
nicely anywhere.
Perl itself is getting slower with each release and that's troublesome.
Machines get faster, but data volumes get larger faster. I may be unusual
in chugging through runs of 80G of data and 10-20M files at a shot, but not
*that* unusual.
>* It might be worth doing to opcodes what we do to SVs and make the opcode
>* itself smaller with the 'extras' hanging off a secondary structure, but I
>* don't know that it'd be a win overall.
>
>What is going on at runtime is already so complex that I wonder how much
>more indirection and complexity would be worthwhile. My biggest objection
>to adding more stuff to the guts of Perl isn't that it makes Perl bigger
>or slower, but that it brings the guts closer to "write-only" as far
>as current and possible future developers/patchers are concerned. Bigger
>and slower are problems that 6 months of progress in the CPU wars will
>solve. Incomprehensible is a problem that is almost impossible to solve.
Well, Topaz is supposed to take care of the complexity issues, at least
somewhat. And the guts themselves are pretty near incomprehensible to mere
mortals.
>I'm certainly impressed at all the indirection that has crept into
>the guts. My look at sprintf the other day and this message issue today
>have made it clear to me that C/C++ acumen and smarts and good programming
>skills are not enough qualification to work on even relatively simple
>Perl patches.
The guts are pretty much beyond the reach of most everyone, and honestly I
think they'll *always* stay that way. Perl's not simple under the hood, and
neither is any programming language of any significance. We could partition
things out so it was easier to understand and expand individual bits, and
we could certainly document it better, but I think the bar's pretty high
and will always stay that way in general.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk