> I don't think optimising for "X" is the reason. Parrot should have > concise, necessary, complete opcode primitives upon which anything > else can be built.
how about opcode formatting primitives? That is what I would argue 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 available and can be described in terms of parrot primitives (strings, numbers), and the fact that this low-level library is well known, tested and supported on various platforms just seems to me to be a tremendous timesaver. > Date parsing can be done all "with" opcodes, but please not "inside" > opcodes. > 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. I agree that facilitating easy bytecode writing is really important - but 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 performance > 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 tell you what - why don't base your decision on an empirical test. 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 on the performance difference, you can decide whether or not its worth the effort to put these primitives in the core. > >> This sort of creeping featuritis is why date formatting and especially > >> parsing do NOT belong as opcodes. It's too big a problem to solve in the > > I agree. And the more I think about it, the more I think this concern is misplaced. 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. Ed
