Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:06 PM +0200 8/16/03, Leopold Toetsch wrote: >>How long does it take to compile core_ops_cg.c with 60 times the opcode, >>we now have?
> We'll only have double the number of ops (since we did decide, ages > ago, that if one PMC in an all-PMC operation was accessed via key > that they all would) so it's not a factor of 60 explosion. To handle all cases with one additional opcode per operation means, that we only have the general form with a Key PMC per argument. This requires the construction of keys (even NULL keys?) for each argument. Constructing these keys (albeit at load time) isn't free. Where we now have an optimized keyed_int opocde, the 3-key variant needs a full PMC key, just holding an immediate constant. To handle all permutations of keyed/non-keyed, each of these vtables has to check, if the associated argument key is NULL or not, which further slows things down. > ... Even if it > was, I'm not worried about the time to compile parrot. That's > something that happens once, for any installation, so the compile > time's generally irrelevant. Yeah, it's a problem for us, but we can > deal. This "generally irrelevant" is going to hit me 20 times a day (or, if we have the opcode explosion, a cron job is compiling Parrot during the night - once) Can you provide an 8-way eServer 325 with plenty of RAM or some such for developers? >>What aboud cache locality? > This won't generally be an issue--either the functions get used a > lot, What is the general usage of these ops? Where do you see this big advantage of bloating the core? >>What about final executable size (with speciall respect to embbeding >>Parrot in some small devices)? > That's definitely an issue, yes. This is something that someone > looking to embed parrot into small devices may want to look at > chopping out. 2 variants of our classes and ops? One with and one without multi-keyed? Who is getting to manage that? >>The only difference of my proposal and the mulit-keyed variants are 3 >>additional opcodes, which doesn't really count - we have a really fast >>opcode dispatch: > And semantic differences--don't forget those. A keyed "add" vtable doesn't help to provide more semantics. The set vs assign thread applies here too. On the contrary: to provide all semantics you would need "add_set_p_k_p_k_p_k" and "add_assign_p_k_p_k_p_k" and possibly "add_clone_p_k_p_k_p_k". leo
