> I don't think optimising for "X" is the reason. Parrot should havehow about opcode formatting primitives? That is what I would argue
> concise, necessary, complete opcode primitives upon which anything
> else can be built.
strftime and relatives are... generic low-level ways of turning strings
into dates into numbers (seconds) and vice-versa.
That they are part of a standard low-level library (libc) that is widely
> Date parsing can be done all "with" opcodes, but please not "inside"I agree that facilitating easy bytecode writing is really important - but
> If we cannot provide a decently performing VM that makes people want to
> write stuff in bytecode (or compiled to bytecode) we have failed anyway.
reimplementing a pretty standard wheel and having that pretty standard wheel
be slower than what is available doesn't seem to be useful to me. Taking
the standard wheel and augmenting it seems more useful IMO.
> This is subjective reasoning, though. If we want to talk performanceI tell you what - why don't base your decision on an empirical test.
> hits, we should know where we stand. When bytecode isn't full of
> PMC thrashing, and actually uses the low level Ix and Sx registers
> where possible, the JIT works extremely well and the performance
> beats Perl5 by several orders of magnitude in many cases. Hopefully
> the "hints" in Perl6 will help us write better libraries, but some of it
> may have to be written in IMC or slightly higher level language (on
> the equivalent of C, compilable to bytecode).
I'll write a c program around strftime that does a given
set of formatting dates and times, as well as the reverse translation, and
we can benchmark that program versus the bytecode that parrot offers in a stdlib on
a list of tasks.
After some optimising iterations, we'll compare the results. And depending
> >> This sort of creeping featuritis is why date formatting and especiallyAnd the more I think about it, the more I think this concern is misplaced.
> >> parsing do NOT belong as opcodes. It's too big a problem to solve in the
> I agree.
Putting it in an opcode will make it *harder* to do this type of thing, not easier.
In perl5 land, backwards - and forwards - compatibility is a big concern. There will
be a large tendency to stabilize any implementation that occurs here.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.