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
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 up with
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 section
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, 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):
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 shall I?
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 bug
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 file
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? Is
the
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 fast
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
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.
Well, there's only
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 even two assignment,
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 Parrot
could
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 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 variable to a
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 is
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 the length
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 there's no
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
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
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 optimized
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 needs
[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
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 offset with a
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
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 about
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 you were
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 might
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 case,
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, not just
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
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,
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.
--
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 to see
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
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
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't thought
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 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
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 alone
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't/
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 not what my
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 what my diff
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, 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
# the
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 come
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 the goto
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.
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 also
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
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
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 it at
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 a
Ok, attached dispatch.diff is the smallest changes
I could think of to get a Configure.pl time choice
for func/switch/goto implementations of DO_OP.
Diff made against a 9:45 PM EST copy from cvs.
ISSUES:
1) goto is gcc-specific.
2) replaces interp_guts.h with do_op.h
3) the goto is done as a
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
56 matches
Mail list logo
