Re: inline mania
Dan Sugalski [EMAIL PROTECTED] writes: At 05:39 PM 8/2/00 +0100, Tim Bunce wrote: On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote: Reference counting is going to be a fun one, that's for sure. I'd like the interface to be something like: stat = perl_get_value(sv *, int what, destination) And what type is perl_get_value declared as returning? An integer--it is a status value after all... Are we sure the value to be should not be returned and the status to be the extra arg? It is neater to be able to say int err; int circ = perl_get_value(radius_sv,PL_INTEGER,err)*2*M_PI; rather than: int radius; int err = perl_get_value(radius_sv,PL_INTEGER,radius); int circ = radius*2*M_PI; Remember the compiler cannot put anything which has its address taken in a register - so if the value is likely to be used in an expression it is better to avoid forcing it to the stack. -- Nick Ing-Simmons [EMAIL PROTECTED] Via, but not speaking for: Texas Instruments Ltd.
Re: inline mania
On Thu, 3 Aug 2000, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 05:39 PM 8/2/00 +0100, Tim Bunce wrote: On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote: Reference counting is going to be a fun one, that's for sure. I'd like the interface to be something like: stat = perl_get_value(sv *, int what, destination) And what type is perl_get_value declared as returning? An integer--it is a status value after all... Are we sure the value to be should not be returned and the status to be the extra arg? It is neater to be able to say int err; int circ = perl_get_value(radius_sv,PL_INTEGER,err)*2*M_PI; rather than: int radius; int err = perl_get_value(radius_sv,PL_INTEGER,radius); int circ = radius*2*M_PI; Remember the compiler cannot put anything which has its address taken in a register - so if the value is likely to be used in an expression it is better to avoid forcing it to the stack. The problem with that is that the value will be a variety of things--a float, an integer, a char *, and so on, depending on what you're asking for, so it sort of has to be a generic void * that's passed. The short-cut functions could well return their type, but I'm loathe to have the two different. Dan
Re: inline mania
Sam Tregar [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2000, John Tobey wrote: The people here are rightly skeptical about the effectiveness of using the 5.6 code base as a starting point for v6, but I have a pretty clear vision of how to do it, and I am committed to giving it a try, even if no one else will. In fact, I'll give you all a tentative schedule: Wait, you're going to develop Perl 6 ALONE? Wasn't this going to be "the community's rewrite of Perl"? Shouldn't you be trying to rally support for your vision before issuing schedules? Not really. I'm going to START developing MY IDEA of how Perl 6 might work. Very likely, I'll stop or merge with someone else's ideas along the way. The schedule is just to get something down, to start fleshing out my idea and maybe provoke other people into starting on their own visions, as Simon Cozens has (though he seems to deny it) done with GLib and Sapphire. I'm not trying to knock you - I'm not at all against hearing you plans and possibly helping out. This just seems like a pretty strange way to approach a community effort. 15 August 2000 - detailed draft spec to perl6-internals. 31 August 2000 - revised spec after discussion. What? You're expecting all the various perl6-* lists to come up with final RFCs be the end of the month? And you're expecting to have Larry's final plans by then? Well, I'll read RFC's as they appear and adjust to them as they are approved, but the stuff I want to do now does not need to wait. This sounds hopeful, but mostly unfounded. Without starting with threading and Unicode as primary features you're going to be fighting an uphill battle ala Perl 5. This I hope to address in my first architecture document. Thanks for the comments. -John
Re: inline mania
On Tue, Aug 01, 2000 at 06:10:53PM -0400, John Tobey wrote: Nick Ing-Simmons [EMAIL PROTECTED] wrote: By all means have a go at Topaz-II But it won't be 'Perl 6' unless it implements what perl-language decides that _is_. Agreed. It won't even remotely resemble 'Perl 6' (as opposed to Perl 5) until it's in a position to start changing the lexer, at least several months from now. So please, follow Chips wise lead, don't call your work Perl 6. Tim.
Re: inline mania
Tim Bunce [EMAIL PROTECTED] wrote: So please, follow Chips wise lead, don't call your work Perl 6. It's called Pickle. "Andy Wardley" [EMAIL PROTECTED] wrote: Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful kinda way), but there's nothing to stop you from wrapping it all up into a less efficent, but prettier API (with the possible exception of reference counting). There is no reason for it to be any less efficient (other than compilers' botching of `inline'). I favor leaving efficiency as a user option. In return for efficiency, we offer binary independence of interpreters. Pickle provides (or will provide) three modes of compiling: Default - perl.h is not included - total bincompat Refcount Cheat - the only bit structure knowledge is sv_refcount Gung Ho - all Default API functions are inline to the level of Perl 5's API You can select any of them with a single conditional. I believe Perl 6 (and v5.8) should support three interfaces along these lines, whether or not any Pickle code is involved. -John
Re: inline mania
On Wed, Aug 02, 2000 at 05:39:19PM +0100, Tim Bunce wrote: On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote: Reference counting is going to be a fun one, that's for sure. I'd like the interface to be something like: stat = perl_get_value(sv *, int what, destination) And what type is perl_get_value declared as returning? Well if what is stating I want a string, it could be a length. Or it could just be a flag if the value was undef, or ... I can't imagine actually using it. Let's forget that one till we know more about how Svs will be implemented. I agree. Graham.
RE: inline mania
Brent Fulgham [EMAIL PROTECTED] writes: Having thought about it a bunch more (because of this) I'm proposing we let the compiler decide. The caller doesn't know enough to make that decision. Read carefully. I said we *let* the caller decide, not *make* the caller decide. What, specifically, disturbs you about my proposal? The 'inline' keyword is just a hint to the compiler. If optimization is turned off, no inlining is done. If optimization is on, the compiler may or may not decide to inline. Performance on different compilers will vary. To repeat: Even if I say "inline" on everything, the compiler is free to disregard that if its optimization routines decide not to. (Also, if I fail to say "inline" on something, the compiler may decide to inline if optimization is active). So aren't we all saying the same thing? I don't think so - it is a question which way we code the source: A. Use 'inline' every where and trust compiler not to do what we told it if it knows better. B. No inline hints in the source and trust the compiler to be able to do the right thing when prodded with -O9 or whatever. C. Make "informed" guesses at to which calls should be inlined. My view is that (B) is the way to go, aiming for (C) eventually, because (A) gives worst-case cache purging. -Brent -- Nick Ing-Simmons
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: Non-inline functions have their place in reducing code size and easing debugging. I just want an i_foo for every foo that callers will have the option of using. Before we make any promises to do all that extra work can we measure (for various architectures) the cost of a real call vs inline. I want proof that inline makes X% difference. I'm not going to prove that. A normal C function call involves several instructions and a jump most likely across page boundaries. But if that function is already in cache from another use, you win. Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit data bus. If your code is inlined and works out to 256 bytes, that's 16 fetches on the main bus. That costs 112 cycles. On the other hand, if your Dan, you are completely missing my point. Okay, fine, non-inline may be a performance win in some cases. Inline may be a win in others. I am not proposing we mandate inlining in any case, I am proposing the exact opposite: that we let the caller decide in every case. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
RE: inline mania
Alan Burlison wrote: John Tobey wrote: 1 November 2000 - Perl6 alpha in C++ that uses classes derived from PerlInterpreter and SV everywhere in place of these types, a la Pickle, but with inline methods that use Perl 5's internal API. I think there is an undiscussed assumption about the implementation language in there somewhere... I think you may have missed the context of the message. John was talking about creating his Alpha using various existing projects that had already been done in C++. [ ... snip ... ] We've been down that path already - Topaz. With all due respect this is supposed to be a community rewrite. Your proposal doesn't seem to be along those lines. With all due respect, I think you may be taking this out of context. I don't believe John's intent was to hijack the process. He was outling a theoretical schedule that could be used to provide a working Perl5 - Perl6 migration path. Regards, -Brent
Re: inline mania
Brent Fulgham wrote: I think there is an undiscussed assumption about the implementation language in there somewhere... I think you may have missed the context of the message. John was talking about creating his Alpha using various existing projects that had already been done in C++. Why is he bothering? A year to produce a prototype doesn't seem like a useful way to expend effort on something that isn't actually perl6. We've been down that path already - Topaz. With all due respect this is supposed to be a community rewrite. Your proposal doesn't seem to be along those lines. With all due respect, I think you may be taking this out of context. I don't believe John's intent was to hijack the process. He was outling a theoretical schedule that could be used to provide a working Perl5 - Perl6 migration path. I'm not saying it was. However I don't see how the proposal would aid the migration - after all what he is writing will be neither perl5 nor perl6. Alan Burlison
Re: inline mania
At 05:55 PM 8/1/00 -0400, John Tobey wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Non-inline functions have their place in reducing code size and easing debugging. I just want an i_foo for every foo that callers will have the option of using. Before we make any promises to do all that extra work can we measure (for various architectures) the cost of a real call vs inline. I want proof that inline makes X% difference. I'm not going to prove that. A normal C function call involves several instructions and a jump most likely across page boundaries. But if that function is already in cache from another use, you win. Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit data bus. If your code is inlined and works out to 256 bytes, that's 16 fetches on the main bus. That costs 112 cycles. On the other hand, if your Dan, you are completely missing my point. Okay, fine, non-inline may be a performance win in some cases. Inline may be a win in others. I am not proposing we mandate inlining in any case, I am proposing the exact opposite: that we let the caller decide in every case. Having thought about it a bunch more (because of this) I'm proposing we let the compiler decide. The caller doesn't know enough to make that decision. *Especially* if (when) we allow for on-the-fly changing of variable access subsystems. We'll be marking a *lot* of functions as inline, and they'll likely get used often and frequently. (If all the SV, HV, and AV macros become functions, which they should, it'll be used a lot) If we go the PI route, the generated files should either have inlined functions or calls to plain functions, and the PI code generator can work that out. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: At 05:55 PM 8/1/00 -0400, John Tobey wrote: Dan, you are completely missing my point. Okay, fine, non-inline may be a performance win in some cases. Inline may be a win in others. I am not proposing we mandate inlining in any case, I am proposing the exact opposite: that we let the caller decide in every case. Having thought about it a bunch more (because of this) I'm proposing we let the compiler decide. The caller doesn't know enough to make that decision. Read carefully. I said we *let* the caller decide, not *make* the caller decide. What, specifically, disturbs you about my proposal? -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: At 05:34 PM 8/1/00 -0400, John Tobey wrote: Okay. For starters, assume that every inline function is called in exactly one place in the translation unit that defines its non-inline counterpart. That one place being, of course, i_foo's foo. This is a natural result of a clean, PI-like-generated source. Bad assumption. How often is av_fill called? By "assume" I mean "ensure" here. As in, this is how we build our library. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
Dan Sugalski [EMAIL PROTECTED] wrote: Bad assumption. How often is av_fill called? Only once in av_fill.c (generated by allfuncs.pl). In most other places, it's called as i_av_fill(). -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: inline mania
[EMAIL PROTECTED] wrote: John Tobey wrote: Why is he bothering? A year to produce a prototype doesn't seem like a useful way to expend effort on something that isn't actually perl6. It is actually perl6 if/when it's finished. Right, so it isn't a community effort then, as you intend doing it all yourself. I always welcome patches, suggestions, and constructive criticism. And if somebody else wants the "maintainer" role, I'll be happy to let them do that work for me. :-) I'm not saying it was. However I don't see how the proposal would aid the migration - after all what he is writing will be neither perl5 nor perl6. I am not "writing". I am "transforming". Ok, so neither is it a rewrite. I suspect it won't be called perl6 in any case. Well, if not, I'll have the satisfaction of having tried. Cheers -John
Re: inline mania
On Tue, 1 Aug 2000, John Tobey wrote: The people here are rightly skeptical about the effectiveness of using the 5.6 code base as a starting point for v6, but I have a pretty clear vision of how to do it, and I am committed to giving it a try, even if no one else will. In fact, I'll give you all a tentative schedule: Wait, you're going to develop Perl 6 ALONE? Wasn't this going to be "the community's rewrite of Perl"? Shouldn't you be trying to rally support for your vision before issuing schedules? I'm not trying to knock you - I'm not at all against hearing you plans and possibly helping out. This just seems like a pretty strange way to approach a community effort. 15 August 2000 - detailed draft spec to perl6-internals. 31 August 2000 - revised spec after discussion. What? You're expecting all the various perl6-* lists to come up with final RFCs be the end of the month? And you're expecting to have Larry's final plans by then? Or are you going to implement Perl 6 without knowing what it is? Unicode and threading would become integrable only after a lot of morphing (refactoring). The morphing would probably destroy any traces of v5 unicode support (since well under 20% of test scripts will notice), and of course 5005threads will be the first to go. With any luck, a compatible, well-integrated replacement will eventually take its place. This sounds hopeful, but mostly unfounded. Without starting with threading and Unicode as primary features you're going to be fighting an uphill battle ala Perl 5. -sam
