Steve Fink writes:
> I just wonder if a 10% improvement on some benchmark is worth writing a
> new language for. A 100% improvement on a single "representative
> real-world task" would be a lot more persuasive. But much more
> convincing would be allowing perl to be embedded as a scripting language
> in places where it couldn't before because it's too slow. Or if it
> allowed some of my quick & dirty prototypes to be usable as production
> components.
10% roughly-across-the-board is good, and mixed with the other
improvements, I think it'll be good. If you can phrase those other
wishables as a measurable well-defined objective, please do so.
And there's no law that says some areas can't run *faster* than 10%.
But I think we have to be realistic. We all want a programming
language that doesn't require you to do anything and runs in zero time,
but it ain't going to happen. 10% -- that's at least in the realms
of possibility.
> Speed is a small issue for me with perl5, and I suspect for most people.
> But partly that's because if I have something that needs speed, I don't
> do it in Perl. For me, the speed of my existing scripts is mostly
> irrelevant. CGI people may disagree. Not sure about PDL people, since I
> don't know if they spend much time in the interpreter.
It's not CGI people who find speed a problem, it's the folks dealing
with shitloads of data. They do the same operations again and again
on 500 million lines of data, and need to squeeze every microsecond
out of the operations because one microsecond each line corresponds to
8 minutes of real-world time. If the bulk of your program is regexp
manipulations of text, a 10% speedup in the RE engine corresponds to
nearly a 10% speedup of your program (for perspective, they could do
another 50 million lines in that time).
> code. Number of new patchers, reduction of complaints (ick), number of
> new XS modules, Dave Beazley's opinion, ...? What would be really nice
> is a real-world example XS' module, and an analysis of the percentage of
> code relevant to the problem (the glue problem, not the domain problem.)
Once again, I'd tend to compile a set of ten problems that represent
common XS operations (wrapping a simple function with automatic type
conversion, defining custom types, mixing Perl-allocated data with
C-allocated data, all the way up to wrapping C++ objects as blessed
tied hashes).
Nat
