On 1/7/24 15:18, ToddAndMargo via perl6-users wrote:
sub DirectoryExists( Str $DirPath --> Bool ) { return
"$DirPath".IO.d.Bool; } # $Full DirPath format is `H:\MyDocsBackup`
Problem: sometimes DirectoryExists lies about
backup1 existing.
Here is what I am up against.
You will
On 1/7/24 06:16, Parrot Raiser wrote:
What's the reason behind the request?
Hi Parrot,
The reason is to eliminate the Optimizer as a
source of weird problems.
I have written a wrapper for Cobian Backup/Reflector
that rotates backup sets. Cobain has is own database
to keep track of backup
On 7 Jan 2024, at 07:09, ToddAndMargo via perl6-users
wrote:
Hi All,
Is there a switch on the command line to disable the code optimizer?
Many thanks,
-T
On 1/7/24 04:24, Elizabeth Mattijsen wrote:
> $ raku --help
>
> ...
> --optimize=level use the given level of optimi
..@perl.org> wrote:
> >
> > Hi All,
> >
> > Is there a switch on the command line to disable the code optimizer?
> >
> > Many thanks,
> > -T
>
>
$ raku --help
...
--optimize=level use the given level of optimization (0..3)
...
> On 7 Jan 2024, at 07:09, ToddAndMargo via perl6-users
> wrote:
>
> Hi All,
>
> Is there a switch on the command line to disable the code optimizer?
>
> Many thanks,
> -T
Hi All,
Is there a switch on the command line to disable the code optimizer?
Many thanks,
-T
This now works on the JVM backend, too. Fixed with
https://github.com/rakudo/rakudo/commit/12d4514a3d
I'm closing this ticket as 'resolved'.
This is still a problem on the JVM backend. I tried a second time to find the
underlying problem and arrived at the same conclusion: There seems to be
something wrong in 'analyze_dispatch'. When running the given code
multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"
On Thu, 04 Apr 2019 22:59:38 -0700, barto...@gmx.de wrote:
> I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm.
For the record: https://github.com/perl6/roast/commit/aaf7ad02fc
Just for the record: This seems to work on the JVM backend:
$ ./perl6-j --optimize=3 -e 'sub f() { sub g() { if True { return
&?ROUTINE.name } } }; say f()()'
g
I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm.
On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote:
> Seems an optimizer bug. Running with --optimize=off does not have the
> issue present.
Fixed and tested as https://github.com/rakudo/rakudo/issues/1465
On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote:
> Seems an optimizer bug. Running with --optimize=off does not have the
> issue present.
Fixed and tested as https://github.com/rakudo/rakudo/issues/1465
On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote:
> On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net
> wrote:
> > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> > > I dug at this bug a few months back, but lost my notes on my
> > > findings.
> >
On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote:
> On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net
> wrote:
> > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> > > I dug at this bug a few months back, but lost my notes on my
> > > findings.
> >
On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote:
> Maybe it is worth noting that this is pretty much a regression (even
> though an
> old one, and caused by a non-optimizer change).
>
> (2016-08-09)
> https://github.com/ra
On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote:
> Maybe it is worth noting that this is pretty much a regression (even
> though an
> old one, and caused by a non-optimizer change).
>
> (2016-08-09)
> https://github.com/ra
On Sat, 21 Jan 2017 11:45:10 -0800, ale...@yahoo.com wrote:
> Take a look at the following examples - the second is more than
> 10x(!!!) faster:
> m: my int $i = 0; loop { if $i++ == 10_000_000 { last }}; say now -
> INIT now;rakudo-moar f97d5c: OUTPUT«2.0606382»
> m: my int $i = 0; loop { if
On Sat, 21 Jan 2017 11:45:10 -0800, ale...@yahoo.com wrote:
> Take a look at the following examples - the second is more than
> 10x(!!!) faster:
> m: my int $i = 0; loop { if $i++ == 10_000_000 { last }}; say now -
> INIT now;rakudo-moar f97d5c: OUTPUT«2.0606382»
> m: my int $i = 0; loop { if
ix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi
> > > foo ($ is rw) {"wrong"}; say foo "42"'
> > > wrong
> > >
> > > And if we turn off the optimizer, we get the right candidate called
> > > (same would h
Maybe it is worth noting that this is pretty much a regression (even though an
old one, and caused by a non-optimizer change).
(2016-08-09)
https://github.com/rakudo/rakudo/commit/328402599c16077e182bb38baf68e435b8bc1082
Output before and after:
https://gist.github.com
$ is rw) {"wrong"}; say foo "42"'
> > wrong
> >
> > And if we turn off the optimizer, we get the right candidate called
> > (same would happen if we add more complex sub bodies, so possibly the
> > sub gets inlined):
> >
> > zoffix@lelian
On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote:
> Expected no errors, but in the first case it complains about
> assignment to immutable value even though none exist in the code.
>
> zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 {
> $ = foo }; say now - INIT now'
On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote:
> Expected no errors, but in the first case it complains about
> assignment to immutable value even though none exist in the code.
>
> zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 {
> $ = foo }; say now - INIT now'
On Wed, 05 Oct 2016 14:23:57 -0700, c...@zoffix.com wrote:
>
> This code shows the bug:
>
> zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi
> foo ($ is rw) {"wrong"}; say foo "42"'
> wrong
>
> And if we tur
Tests in
https://github.com/perl6/roast/commit/b1f116fdd5181274cda1a520194488da82c10a7e
Tests in
https://github.com/perl6/roast/commit/b1f116fdd5181274cda1a520194488da82c10a7e
On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net wrote:
> On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> > I dug at this bug a few months back, but lost my notes on my
> > findings.
> >
> > As I recall it, the 128655 happens in BOOTSTRAP.nqp in
> >
On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote:
> I dug at this bug a few months back, but lost my notes on my findings.
>
> As I recall it, the 128655 happens in BOOTSTRAP.nqp in
> find_best_dispatchee() the non-native candidate ends up being first in
> the list and that's why it's
11-182-gea28845 built on MoarVM version
> 2016.11-41-gd2139b5
> implementing Perl 6.c.
> zoffix@VirtualBox:~$
>
>
> There's a pretty good chance that the optimizer evaluates the
> statement and encounters NQP bug involving ||:
> https://github.com/perl6/nqp/issues/332
Looks as
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #130855]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130855 >
Expected no errors, but in the first case it complains about assignment to
immutable
ion 2016.11-182-gea28845 built on MoarVM version
2016.11-41-gd2139b5
implementing Perl 6.c.
zoffix@VirtualBox:~$
There's a pretty good chance that the optimizer evaluates the statement and
encounters NQP bug involving ||: https://github.com/perl6/nqp/issues/332
ot;right" }; multi
foo ($ is rw) {"wrong"}; say foo "42"'
wrong
And if we turn off the optimizer, we get the right candidate called
(same would happen if we add more complex sub bodies, so possibly the
sub gets inlined):
zoffix@leliana:~$ perl6 --optimize=o
Posting on behalf of dogbert17:
I believe that I have encountered the same bug under different circumstances.
With the help of hackedNODE and others on #perl6
it seems as if the problem described below also suffers from the wrong multi
candidate being called. In
Playing around I found that the following change made your examples work as
expected:
diff --git a/src/Perl6/Optimizer.nqp b/src/Perl6/Optimizer.nqp
index 12398ba..9102b7f 100644
--- a/src/Perl6/Optimizer.nqp
+++ b/src/Perl6/Optimizer.nqp
@@ -1082,7 +1082,8 @@ class Perl6::Optimizer
PRC/rakudo$ ./perl6 -e 'sub foo ($) {say
"meow"}; ^4 .map: '
===SORRY!===
Cannot find method 'count' on object of type NQPMu
However, everything works fine, if we turn off the optimizer:
zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6 --optimize=off -e '^4
.map: {};'
Canno
nice test case, though!
[14:11] I'll submit this. At least it will be useful as a note for
the future.
[14:11] our regex optimizer is dumb as bricks ;)
--
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.
Please reply to all on tickets, so that comments also end up back in
RT as well. (I linked the tickets based on your comment here.)
On Mon, Jul 18, 2016 at 4:10 AM, mt1957 wrote:
> Hi Elizabeth,
>
> Need to mention that there was a ticket #128624 created 'Buf initialization
>
Hi Elizabeth,
Need to mention that there was a ticket #128624 created 'Buf
initialization error'.
Regards,
Marcel Timmerman
an Int, and that fails the nqp::istype($a,Int) test. It
*feels* like it calling the int/int candidate, when it thinks it's calling the
Int:D/Int:D candidate. Since the int/int candidate returns an int, but the
optimizer probably thinks it is getting an Int, the native is not marshalled
into
uot;a" =:= "a" || 0 # must be runtime
rakudo-moar ac36d2: OUTPUT«True»
That seems of another level to me.
looks like an optimizer bug:
$ perl6 --optimize=0 -e 'my $a = "a"; say $a =:= $a || 0'
True
$ perl6 --optimize=2 -e 'my $
t; rakudo-moar 8b834c: ( no output )
[21:58:08] m: sub a($x is rw) { $x; }; { a 42 } # seems to be
optimizer related
[21:58:08] <+camelia> rakudo-moar 8b834c: ( no output )
[21:58:19] $ perl6 --optimize=off -e 'sub a($x is rw) { $x }; { a
42 }'
[21:58:19] Parameter '$x
On Tue Jun 19 11:51:14 2012, pmichaud wrote:
Refined from a case given by harmil++ on #perl6, the optimizer seems
to have problems with long expressions.
pmichaud@kiwi:~/p6/rakudo$ cat z
#!/bin/bash
for size in 1 10 100 500 1000 1;
do
code=$(./perl6 -e say (1..$size).join
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #113754]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=113754
Refined from a case given by harmil++ on #perl6, the optimizer seems
Argh. Just realised my old address, [EMAIL PROTECTED], could receive emails
but not send them (not even to itself!)
On Dec 31, 2005, at 15:43, Amos Robinson wrote:
--
A copy_ins() function would be nice, if needed.
However, this doesn't seem to work with e.g. set_args.
Why?
In my local
into the PCC stuff you did.
Copying these instructions should work after all the directives are
expanded, i.e. when the optimizer sees it.
Ahh, okay. How many ops would you say there are that change contents of
non-LHS args? I don't want to cause too much trouble, but for
used_once I
think some
On Dec 31, 2005, at 15:43, Amos Robinson wrote:
I was wondering if anybody could help: the best I've found for
duplicating
an instruction is
INS(interp, unit, ins-op, , ins-r, ins-n_r, ins-keys, 0);
A copy_ins() function would be nice, if needed.
However, this doesn't seem to work with
I was wondering if anybody could help: the best I've found for duplicating
an instruction is
INS(interp, unit, ins-op, , ins-r, ins-n_r, ins-keys, 0);
However, this doesn't seem to work with e.g. set_args.
Is there some easy way to duplicate an instruction, or should I just give
up when I see a
Curtis Rawls wrote:
As part of my Summer of Code project, I wanted to improve the
documentation of the optimizer.
Please svn add the .pod to docs/dev
Thanks,
leo
As part of my Summer of Code project, I wanted to improve the
documentation of the optimizer. This was especially relevant for me
since I had to learn it my self by trial and error and asking
questions. So here is my first draft of the optimizer documentation.
I tried to include the most
Also, this is in plain text format. What is the standard way to
convert a document to POD format?
By rewriting it. Only took me a few minutes:
=head1 NANE
optimizer.pod - About the IMCC optimizer
=head1 ABSTRACT
This document describes how the IMCC optimizer works.
=head1 DESCRIPTION
Simon Glover [EMAIL PROTECTED] wrote:
If -O2 is used however, it prints '-1', and the hangs. Disassembly of
the optimized bytecode shows that it is being optimized to:
-O2 shouldn't do anything for PASM code and it seems that it got more
broken recently as it was. I'll disable it for now.
# New Ticket Created by Simon Glover
# Please include the string: [perl #27181]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27181
This code (a cut-down version of mops.pasm):
setI2, 0
set
Luke Palmer [EMAIL PROTECTED] wrote:
gcc 3.2 has a bug that makes SArray's shift_* not work when compiled
with optimization. This works around it (and is arguably better style
anyway). gcc will receive a bug report if I can manage to reduce the
problem.
Thanks, applied.
leo
gcc 3.2 has a bug that makes SArray's shift_* not work when compiled
with optimization. This works around it (and is arguably better style
anyway). gcc will receive a bug report if I can manage to reduce the
problem.
Index: classes/sarray.pmc
# New Ticket Created by Clinton A. Pierce
# Please include the string: [perl #22359]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22359
The IMCC optimizer run with these options:
..\..\imcc\imcc -Op1 -d60
Clinton A. Pierce [EMAIL PROTECTED] wrote:
..\..\imcc\imcc -Op1 -d60 err.imc
Please note: -Op does optimize PASM code, that wouldn't get optimized
else. For .imc files just using -O1 suffices.
Bug #1:
Issues the error message (now a warning, but probably a problem nontheless):
of a repeat of the old ld:
multiple definitions of symbol problem (ticket #17159). I fixed that
with the attached patch.
Thanks for the patch, applied.
Now that it compiles, several of the optimizer tests fail. The problem
seems to be unrelated to the patch because the tests pass with the patch
on my
definitions of symbol problem (ticket #17159). I fixed that
with the attached patch.
Now that it compiles, several of the optimizer tests fail. The problem
seems to be unrelated to the patch because the tests pass with the patch
on my Slackware box.
Hope this is useful.
Allison
...
t/imcpasm
Leopold Toetsch wrote:
Phil Hassey wrote:
But with a processor with 16 registers (do such things exist?).
Parrot would be overflowing registers that it could have been using
in the JIT.
RISC processor have a lot of them. But before there are unused
processor registers, we will allocate P
Nicholas Clark [EMAIL PROTECTED] writes:
On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote:
[snip lots of good stuff]
All this is obviously machine dependent: the code generated should
only run in the machine it was compiled for. So we should always keep
the original imc code in
by parrots JIT code, to get sections and register
mappings. This is significantly faster then current's jit optimizer,
which has a relatively high impact on program load times.
The JIT loader looks at the packfile now, and uses either method to
generate information needed for actually producing bytecode
On Tue, Feb 25, 2003 at 11:58:41PM +0100, Leopold Toetsch wrote:
Nicholas Clark wrote:
[thanks for the explanation]
And is this all premature optimisation, give that we haven't got objects,
exceptions, IO or a Z-code interpreter yet?
And yes: We don't have exceptions and threads yet. The
[snip]
Maybe we starting to get to the point of having imcc deliver parrot
bytecode if you want to be portable, and something approaching native
machine code if you want speed.
IMHO yes, the normal options produce a plain PBC file, more or less
optimized at PASM level, the -Oj option is
Phil Hassey wrote:
... The current bytecode from parrot already has potential
for slowing things down, and that's what worries me here.
I don't see that.
My understanding is that PBC has a limit of 16 (32?) integer registers. When
a code block needs more than 16 registers, they are overflowed
[ you seem to be living some hors ahead in time ]
Yep, sorry about that.
The problem stays the same: spilling processors to parrot's or
parrots to array.
Thinking a bit more about it, now I believe that the best way to do it
would be:
(1) First, do a register allocation for machine
load/store ops and an additional CFG/register usage PBC
section. But running it does require less memory, because the JIT
optimizer doesn't have to create all the internal bookkeeping tables.
Cheers,
Phil
leo
Angel Faus wrote:
(1) First, do a register allocation for machine registers, assuming
that there are N machine registers and infinite parrot registers.
This uses equally the top N used registers for processor regs. The
spilling for (1) is loading/moving them to parrot registers/temp
Although it might be nice if IMC were binary at this stage (for some
feel-good-reason?).
You mean, that a HL like perl6 should produce a binary equivalent to
ther current .imc file? Yep - this was discussed already, albeit there
was no discussion, how this should look like. And the lexer
Leopold Toetsch wrote:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
I have committed the next bunch of changes and an updated jit.pod.
- it should now be platform independent, *but* other platforms have to
define what they consider as
I explained very badly. The issue is not spilling (at the parrot
level)
The problem is: if you only pick the highest priority parrot registers
and put them in real registers you are losing oportunities where
copying the date once will save you from copying it many times. You
are, in some
Angel Faus wrote:
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
With your approach there are three levels of parrot registers:
- The first N registers, which in JIT will be mapped to physical
registers.
- The others 32 - N parrot registers, which will be in memory.
- The spilled
On Tuesday 25 February 2003 08:51, Leopold Toetsch wrote:
Angel Faus wrote:
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
With your approach there are three levels of parrot registers:
- The first N registers, which in JIT will be mapped to physical
registers.
- The
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Ok .. well I sort of understood that the first N registers will
be the ones MAPped ?. So I thought re-ordering/sorting was the
operation performed.
Yep. Register
On Tue, Feb 25, 2003 at 07:18:11PM +0100, Angel Faus wrote:
I believe it would be smarter if we instructed IMCC to generate code
that only uses N parrot registers (where N is the number of machine
register available). This way we avoid the risk of having to copy
twice the data.
It's not
each code block say
I need 12 registers for this block and then the JIT system would go on to
do it's appropriate spilling magic with the system registers...
This is somehow the approach, the current optimizer in jit.c takes. The
optimizer looks at a section (a JITed part of a basic block
, and
this is -- hmmm suboptimal then :) and imcc can write out CFG
information in some machine independent form, i.e. at basic block level.
But no processor specific load/store instructions and such.
This can help JIT optimizer to do the job faster, though it isn't that
easy, because
[ you seem to be living some hors ahead in time ]
Angel Faus wrote:
I explained very badly. The issue is not spilling (at the parrot
level)
The problem stays the same: spilling processors to parrot's or parrots
to array.
[ ... ]
set I3, 1
add I3, I3, 1
print I3
fast_save I3, 1
set I3, 1
Dan Sugalski wrote:
At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor
If memory serves me right, Dan Sugalski wrote:
This sounds pretty interesting, and I bet it could make things
faster. The one thing to be careful of is that it's easy to get
yourself into a position where you spend more time optimizing the
code you're JITting than you win in the end.
I
Gopal V wrote:
I'm assuming that the temporaries are the things being moved around here ?.
It is not so much a matter of moving things around, but a matter of
allocating (and renumbering) parrot (or for JIT) processor registers.
These are of course mainly temporaries, but even when you have
At 4:28 PM +0100 2/22/03, Leopold Toetsch wrote:
Gopal V wrote:
Direct hardware maps (like using CX for loop count etc) will need to be
platform dependent ?. Or you could have a fixed reg that can be used for
loop count (and gets mapped on hardware appropriately).
We currently don't have special
Nicholas Clark wrote in perl.perl6.internals :
r-score = r-use_count + (r-lhs_use_count 2);
r-score += 1 (loop_depth * 3);
[...]
I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc
that added trap code for all classes of undefined behaviour, and caused
Please don't take the following as a criticism of imcc - I'm sure I manage
to write code with things like this all the time.
On Sat, Feb 22, 2003 at 08:13:59PM +0530, Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
r-score = r-use_count + (r-lhs_use_count 2);
If memory serves me right, Leopold Toetsch wrote:
I'm assuming that the temporaries are the things being moved around here ?.
It is not so much a matter of moving things around, but a matter of
allocating (and renumbering) parrot (or for JIT) processor registers.
Ok .. well I sort of
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Ok .. well I sort of understood that the first N registers will be the
ones MAPped ?. So I thought re-ordering/sorting was the operation performed.
Yep. Register renumbering, so that the top N used (in terms of score)
registers
Nicholas Clark wrote:
r-score += 1 (loop_depth * 3);
until variables in 11 deep loops go undefined?
Not undefined, but spilled. First *oops*, but second of course this all
not final. I did change scoring several times from the code base AFAIK
Angel Faus did implement. And we don't
On Sat, Feb 22, 2003 at 08:44:12PM -, Rafael Garcia-Suarez wrote:
Nicholas Clark wrote in perl.perl6.internals :
r-score = r-use_count + (r-lhs_use_count 2);
r-score += 1 (loop_depth * 3);
[...]
I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc
On Sat, Feb 22, 2003 at 09:27:04PM +, nick wrote:
On Sat, Feb 22, 2003 at 08:44:12PM -, Rafael Garcia-Suarez wrote:
What undefined behaviour are you referring to exactly ? the shift
overrun ? AFAIK it's very predictable (given one int size). Cases of
Will you accept a shortcut
Leopold Toetsch wrote:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
The [RFC] imcc calling conventions didn't get any response. Should I
take this fact as an implict yep, fine?
Here is again the relevant part, which has implications on
At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is
still faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
This sounds
Dan Sugalski wrote:
At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor
Sean O'Rourke wrote:
On Thu, 20 Feb 2003, Leopold Toetsch wrote:
What do people think?
Cool idea -- a lot of optimization-helpers could eventually be passed on
to the jit (possibly in the metadata?). One thought -- the information
imcc computes should be platform-independent. e.g. it
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm), I did this experiment:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
Here is the JIT optimized PASM output of
$ imcc -Oj -o p.pasm
On Thursday 20 February 2003 18:14, Leopold Toetsch wrote:
Tupshin Harper wrote:
Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm)
Lol...what are you going to do when somebody comes along with the
Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm)
Lol...what are you going to do when somebody comes along with the
unbearable example of primes.s(optimized x86 assembly), and you are
forced to throw up your
Tupshin Harper wrote:
Leopold Toetsch wrote:
Starting from the unbearable fact, that optimized compiled C is still
faster then parrot -j (in primes.pasm)
Lol...what are you going to do when somebody comes along with the
unbearable example of primes.s(optimized x86 assembly), and you are
# New Ticket Created by Tony Payne
# Please include the string: [netlabs #617]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=617
Fixed some minor bugs w/ the Optimizer, having to do mainly with
handling
G'day all.
I'm working on the Optimizer (adding a new intermediate form to allow
for more aggressive optimization) but mail to Jeff Goff seems to be
bouncing. Does anyone know where he is?
Cheers,
Andrew Bromage
---BeginMessage---
Andrew J Bromage wrote:
G'day all.
I'm working on the Optimizer (adding a new intermediate form to allow
for more aggressive optimization) but mail to Jeff Goff seems to be
bouncing. Does anyone know where he is?
Cheers,
Andrew Bromage
No idea :)
It's been
Enclosed patch fixes a couple of bugs in the optimizer. The first was
that the parser wasn't correctly recognising register names - it needs
to check for these _before_ checking for labels, or else they're
incorrectly identified as labels. Strangely, this wasn't causing
any problems
1 - 100 of 105 matches
Mail list logo