On Wed, Nov 07, 2001 at 05:15:14PM -0500, Dan Sugalski wrote:
*) The program is fully parsed
*) There are no string eval, do, or requires
*) There are no symbolic references on the LHS of any assignment
*) There is no use of MY within the block or in any subs c
At 07:27 PM 11/8/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > Gack. Looks like a mis-placed optimization in perl 5. The list of a
> foreach
> > is *supposed* to flatten at loop start and be static. Apparently not. :)
>
>Is anybody keeping a list of things that are *supposed* to be static?
Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
Is anybody keeping a list of things that are *supposed* to be static? Is
the list changing much with Perl 6?
> Care to fil
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Yes, it is a bug. There's an array in list context--it's supposed to be
> flattened before the foreach loop gets evaluated. (And if there are
> multiple arrays in the list it works as you'd expect)
Sorry, I quoted the wrong section. It really isn't a bu
At 05:41 PM 11/8/2001 -0500, Sam Tregar wrote:
>On Thu, 8 Nov 2001, Dan Sugalski wrote:
>
> > Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> > is *supposed* to flatten at loop start and be static. Apparently not. :)
> >
> > Care to file the perl 5 bug report, or shal
On Thu, 8 Nov 2001, Brent Dax wrote:
> That doesn't support your argument. The point is that in the statement:
>
> foreach(@array) {
> ...
> }
>
> @array should only be evaluated once, at the beginning of the loop. In
> effect (using := here, but otherwise Perl 5 code)
Sam Tregar
# On Thu, 8 Nov 2001, Dan Sugalski wrote:
#
# > Gack. Looks like a mis-placed optimization in perl 5. The
# list of a foreach
# > is *supposed* to flatten at loop start and be static.
# Apparently not. :)
# >
# > Care to file the perl 5 bug report, or shall I?
#
# It's not a bug. Check
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
>
> Care to file the perl 5 bug report, or shall I?
It's not a bug. Check out the "Foreach Loops" sect
At 07:53 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > No it isn't. It can get the integer length of the array and stuff it in a
> > register at the beginning of the loop, or do an integer compare when it
> > needs to, depending on the semantics of the loop.
>
>Wow. Did you just come
Dan Sugalski wrote:
> No it isn't. It can get the integer length of the array and stuff it in a
> register at the beginning of the loop, or do an integer compare when it
> needs to, depending on the semantics of the loop.
Wow. Did you just come up with a place in Perl where static
behavior is gua
At 06:06 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
> > > On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > > > If Perl can keep the loop index in an integer register, then Parrot
> > > > could use fast loop ops. IMHO th
Dan Sugalski wrote:
> At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
> > On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > > If Perl can keep the loop index in an integer register, then Parrot
> > > could use fast loop ops. IMHO there's no point in using fast loop ops
> > > if taking
At 08:44 PM 11/7/2001 +0100, Bart Schuller wrote:
>On Wed, Nov 07, 2001 at 07:12:40AM -0600, Dave Goehrig wrote:
> > I brought up the whole low level integer rewrite stuff above, because
> > look at it again. That is eactly what we are meant to do when we know
> > it is safe to optimize a variabl
On Wed, Nov 07, 2001 at 07:12:40AM -0600, Dave Goehrig wrote:
> I brought up the whole low level integer rewrite stuff above, because
> look at it again. That is eactly what we are meant to do when we know
> it is safe to optimize a variable to a more limited domain than say
> 'scalar'. We don't
At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
>On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > I've been thinking of ways to speed up stuff like:
> > foreach my $x (@vector) {
> > $x *= $scale
> > }
> >
> > If Perl can keep the loop index in an integer register, then Parro
At 10:04 AM 11/7/2001 -0600, Dave Goehrig wrote:
>On Wed, Nov 07, 2001 at 03:41:54PM -0500, Ken Fox wrote:
> > Dan Sugalski wrote:
> > > my $foo;
> > > $foo = 12;
> > > print $foo;
> > > $foo /= 24;
> > > print $foo;
> >
> > Well, there's only two assignments there,
>
>It isn't
At 03:41 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > my $foo;
> > $foo = 12;
> > print $foo;
> > $foo /= 24;
> > print $foo;
> >
> > may well have the vtable pointer attached to the PMC for $foo change with
> > every line of code. Probably will, honestly.
>
>Wel
At 09:47 AM 11/7/2001 -0600, Dave Goehrig wrote:
> > The problem with inlining methods from PMC vtables is it assumes those
> > vtable methods are constant. They're not.
>
>They're not constant universally, but the are constant locally.
No, they aren't. A vtable method can completely swap out a v
On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> I've been thinking of ways to speed up stuff like:
> foreach my $x (@vector) {
> $x *= $scale
> }
>
> If Perl can keep the loop index in an integer register, then Parrot
> could use fast loop ops. IMHO there's no point in using fa
On Wed, Nov 07, 2001 at 03:41:54PM -0500, Ken Fox wrote:
> Dan Sugalski wrote:
> > my $foo;
> > $foo = 12;
> > print $foo;
> > $foo /= 24;
> > print $foo;
>
> Well, there's only two assignments there,
It isn't even two assignment, hell, it reduces to: 120.5
literally, if you
> The problem with inlining methods from PMC vtables is it assumes those
> vtable methods are constant. They're not.
They're not constant universally, but the are constant locally. In
those locales that inlining is worth the cost we can do it. And
as long as we are willing to take the hit in o
Dan Sugalski wrote:
> my $foo;
> $foo = 12;
> print $foo;
> $foo /= 24;
> print $foo;
>
> may well have the vtable pointer attached to the PMC for $foo change with
> every line of code. Probably will, honestly.
Well, there's only two assignments there, so I assume that print
Dan Sugalski:
# >Is anybody working on the Perl code generator yet? I think
# >the code generator might influence op implementation.
Chicken and egg. We can't really generate code until the ops are ready,
but we would like the code generator to be around so we can make
intelligent decisions abou
On Wed, Nov 07, 2001 at 11:50:00AM -0500, Dan Sugalski wrote:
> I mean "Change which table of functions is in effect for a
> variable at this point in time".
I honestly, still don't think that makes a lick of difference,
though I admit I may be introducing an "out of context problem".
> my
At 05:35 AM 11/7/2001 -0600, Dave Goehrig wrote:
>[snip inlining PMC vtable]
>
>On Wed, Nov 07, 2001 at 09:49:04AM -0500, Dan Sugalski wrote:
> > We can't do that. PMCs, even statically typed ones, can change their
> > vtables as they see fit.
>
>That is true, but it does not negate the option of
At 10:15 AM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> > >If the guts of a vtable implementation are ripped out and given an
> > >op, isn't that inlining a PMC method? There doesn't seem much point
> > >in replacing a dynamic vtable offse
[snip inlining PMC vtable]
On Wed, Nov 07, 2001 at 09:49:04AM -0500, Dan Sugalski wrote:
> We can't do that. PMCs, even statically typed ones, can change their
> vtables as they see fit.
That is true, but it does not negate the option of inlining, it simply
increases the overhead required for
Dan Sugalski wrote:
> At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> >If the guts of a vtable implementation are ripped out and given an
> >op, isn't that inlining a PMC method? There doesn't seem much point
> >in replacing a dynamic vtable offset with a constant vtable offset.
> >The method really
At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
>Simon Cozens wrote:
> > > some static typing ability, so it should be able
> > > to emit bytecode that doesn't go through the PMC vtable.
> >
> > Yes, but that's fundamentally different from inlining vtable methods
> > in the runops loop, which is what
Simon Cozens wrote:
> On Mon, Nov 05, 2001 at 11:35:53PM -0500, Ken Fox wrote:
> > IMHO Perl is getting
>
> Interesting construction. :)
Yeah, that should have been a disclaimer. I've heard static typing
proposed, but nothing appears finalized about anything yet. Something
like static typing mi
On Mon, Nov 05, 2001 at 11:35:53PM -0500, Ken Fox wrote:
> IMHO Perl is getting
Interesting construction. :)
> some static typing ability, so it should be able
> to emit bytecode that doesn't go through the PMC vtable.
Yes, but that's fundamentally different from inlining vtable methods
in the
Simon Cozens wrote:
> On Mon, Nov 05, 2001 at 02:08:21PM -0500, Ken Fox wrote:
> > we'd be a lot better inlining some of the PMC methods as ops instead of
> > trig functions. ;)
>
> Won't work. We can't predict what kind of PMCs will be coming our way, let
> alone what vtables they'll use, let al
On Mon, Nov 05, 2001 at 02:08:21PM -0500, Ken Fox wrote:
> we'd be a lot better inlining some of the PMC methods as ops instead of
> trig functions. ;)
Won't work. We can't predict what kind of PMCs will be coming our way, let
alone what vtables they'll use, let alone what methods those vtables w
Dan Sugalski wrote:
> We might want to have one fast and potentially big loop (switch or computed
> goto) with all the alternate (tracing, Safe, and debugging) loops use the
> indirect function dispatch so we're not wedging another 250K per loop or
> something.
Absolutely. There's no gain from
On Monday 05 November 2001 09:46 am, Daniel Grunblatt wrote:
> This is exactly what I'm trying to avoid, this is a big overhead, because
> if I'm understaing right you are suggesting to add and if here, right?
> well imagine that if made everytime even when we are not tracing.
>
> Unless that what
You already got them on my last patch posted yesterday, but now I'm
working in a new version which will have nicer code, in that patch I
didn't add an if to the Makefile, because I thought that it is not
portable, but Brent Dax told me that I can use it, what do you think about
this? should we kee
At 05:32 PM 11/5/2001 +, Simon Cozens wrote:
>On Mon, Nov 05, 2001 at 11:46:50AM -0300, Daniel Grunblatt wrote:
> > The point is that,in my opinion, we don't really need to be faster than
> > now when tracing, etc but we DO have to be faster when running like:
>
>I agree completely. I'd like t
On Mon, Nov 05, 2001 at 11:46:50AM -0300, Daniel Grunblatt wrote:
> The point is that,in my opinion, we don't really need to be faster than
> now when tracing, etc but we DO have to be faster when running like:
I agree completely. I'd like to see configure-time options for the
runops loop.
--
"
I'm definetly having a hard time trying to make my self clear, sorry guys
I'm still learning english :( .
The point is that,in my opinion, we don't really need to be faster than
now when tracing, etc but we DO have to be faster when running like:
# ./test_prog mops.pbc
On Mon, 5 Nov 2001, Bre
Daniel Grunblatt:
# No, I totally disagree on that if I do that we will lose the
# speed gained
# before, I still don't know why we can't stay we the actual
# dispatch method
# when tracing, etc and use computed goto when running without
# any command
# line switch?
If we enable tracing with comp
No, I totally disagree on that if I do that we will lose the speed gained
before, I still don't know why we can't stay we the actual dispatch method
when tracing, etc and use computed goto when running without any command
line switch?
Daniel Grunblatt.
On Mon, 5 Nov 2001, Brent Dax wrote:
> Dan
Daniel Grunblatt:
# On Mon, 5 Nov 2001, Brent Dax wrote:
#
# > Michael Fischer:
# > # On Nov 04, Brent Dax <[EMAIL PROTECTED]> took up a keyboard
# > # and banged out
# > # > Michael Fischer:
# > # > # In the goto case, we spin. And perhaps I am broken there. End
# > # > # really wants to return,
On Mon, 5 Nov 2001, Brent Dax wrote:
> Michael Fischer:
> # On Nov 04, Brent Dax <[EMAIL PROTECTED]> took up a keyboard
> # and banged out
> # > Michael Fischer:
> # > # In the goto case, we spin. And perhaps I am broken there. End
> # > # really wants to return, not just set the pc, but I hadn
Michael Fischer:
# On Nov 04, Brent Dax <[EMAIL PROTECTED]> took up a keyboard
# and banged out
# > Michael Fischer:
# > # In the goto case, we spin. And perhaps I am broken there. End
# > # really wants to return, not just set the pc, but I hadn't thought
# > # of a clever way to do that corner c
Yes, and thanks to Michael Fischer I'm already working on that as I
described on a previos mail. I hope to post it in a few hours.
Daniel Grunblatt.
On Sun, 4 Nov 2001, Dan Sugalski wrote:
> At 02:45 PM 11/4/2001 -0300, Daniel Grunblatt wrote:
> >Sure, I alredy knew that, may be I'm just having
At 02:45 PM 11/4/2001 -0300, Daniel Grunblatt wrote:
>Sure, I alredy knew that, may be I'm just having a hard time to make my
>self clear.
>
>What I mean was:
>
>On those unixes, with cc (NOT GCC), that Benoit Cerrina pointed, Can we
>use computed goto?
No. And Unix generally doesn't enter into i
Sure, I alredy knew that, may be I'm just having a hard time to make my
self clear.
What I mean was:
On those unixes, with cc (NOT GCC), that Benoit Cerrina pointed, Can we
use computed goto?
or in other words:
Is there any other compiler besides gcc that implements computed goto?
Daniel Grun
At 02:37 PM 11/4/2001 -0300, Daniel Grunblatt wrote:
>So, on those other unixes that come with cc we can't use computed goto?
Computed goto is, at the moment, a GCC-specific feature. It's not OS
specific, just compiler-specific.
Dan
-
So, on those other unixes that come with cc we can't use computed goto?
Daniel Grunblatt.
On Sun, 4 Nov 2001, Benoit Cerrina wrote:
>
>
> > I think your approuch is much better and cleaner than mine, my brain was
> > limited to unix :) so I never worried about anything besides gcc.
> > It would
At 02:33 PM 11/4/2001 -0300, Daniel Grunblatt wrote:
>Did you put an eye on my implementation? what's the point in using
>computed goto when tracing, checking bounds or profiling?
There's not a huge amount of win over a switch, but there is a benefit over
the function dispatch method.
Did you put an eye on my implementation? what's the point in using
computed goto when tracing, checking bounds or profiling?
Daniel Grunblatt.
On Sun, 4 Nov 2001, Michael Fischer wrote:
> On Nov 04, Brent Dax <[EMAIL PROTECTED]> took up a keyboard and banged out
> > Michael Fischer:
> > # In th
> I think your approuch is much better and cleaner than mine, my brain was
> limited to unix :) so I never worried about anything besides gcc.
> It would also be nice if you can decide which dispatch method use instead
> of asking.
Hum, I think you mean linux, maybe BSD, but the other unixes com
On Nov 04, Brent Dax <[EMAIL PROTECTED]> took up a keyboard and banged out
> Michael Fischer:
> # In the goto case, we spin. And perhaps I am broken there. End
> # really wants to return, not just set the pc, but I hadn't thought
> # of a clever way to do that corner case, and wanted to see what
>
Michael Fischer:
# In the goto case, we spin. And perhaps I am broken there. End
# really wants to return, not just set the pc, but I hadn't thought
# of a clever way to do that corner case, and wanted to see what
# the behavior would be without it. I suspect I need it.
Can't you just break()?
-
On Nov 04, Daniel Grunblatt <[EMAIL PROTECTED]> took up a keyboard and banged out
>
>
> On Sun, 4 Nov 2001, Michael Fischer wrote:
>
> > On Nov 04, Daniel Grunblatt <[EMAIL PROTECTED]> took up a keyboard and
>banged out
> > > I really suggest that you do a do_op.c and a do_op.h and that you c
On Sun, 4 Nov 2001, Michael Fischer wrote:
> On Nov 04, Daniel Grunblatt <[EMAIL PROTECTED]> took up a keyboard and banged
>out
> > First of all you miss typed:
> > -if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
> > +if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
>
> hmm. Thats not wh
At 12:19 PM 11/4/2001 -0500, Michael Fischer wrote:
>On Nov 04, Daniel Grunblatt <[EMAIL PROTECTED]> took up a keyboard
>and banged out
> > First of all you miss typed:
> > -if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
> > +if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
>
>hmm. Thats no
On Nov 04, Daniel Grunblatt <[EMAIL PROTECTED]> took up a keyboard and banged out
> First of all you miss typed:
> -if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
> +if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
hmm. Thats not what my diff has. Point is, if you chose
'goto', $c{cc} /isn'
First of all you miss typed:
-if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
+if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
On Sat, 3 Nov 2001, Michael Fischer wrote:
> Ok, attached dispatch.diff is the smallest changes
> I could think of to get a Configure.pl time choice
> for func/sw
59 matches
Mail list logo
