On Sunday 27 June 2010 at 23:05, Peter Lobsinger wrote:
> The problem with doing register allocation before IMCC is that IMCC
> creates temporary registers and does so in a very simple, inefficient
> way (every temporary in a function consumes an independant register).
This wouldn't be a problem
On Sun, Jun 27, 2010 at 4:33 PM, Andrew Whitworth wrote:
> Doing it in IMCC is intractable I think. It's probably okay if basic
> PIR doesn't get too fancy with register allocation, though there's no
> reason why it shouldn't be added in to POST. Do you think it should be
> part of normal POST ope
> Note that doing it in POST means that anyone NOT using POST doesn't
> get this benefit, which I think includes winxed, lua, and old-school
> partcl.
If people write winxed functions that use several hundred registers I
must consider to add an special clause to its license to forbid it ;-)
More
On Sun, Jun 27, 2010 at 5:21 PM, chromatic wrote:
> Hello C hackers,
>
> I added some temporary debugging output to CallContext's mark VTABLE to see
> what's happening in the GC when Rakudo runs. Look at src/gen/core.pir in the
> Rakudo directory, and especially the first PIR function (it's _bloc
On Sunday 27 June 2010 at 16:33, Andrew Whitworth wrote:
> Do you think it should be
> part of normal POST operation, or added as an optional optimization
> step? I ask because we might want multiple pluggable/selectable
> allocators, and we may want to turn off the fancier ones entirelywhere
> sp
Hello.
For the record. I'm going to replace current POST with PIRATE's POST
"really soon". And PIRATE already has VanillaAllocator which can be
easily replaced with more sophisticated one.
--
Bacek.
On Mon, Jun 28, 2010 at 9:33 AM, Andrew Whitworth wrote:
> Better register allocation will like
On Sun, Jun 27, 2010 at 02:21:17PM -0700, chromatic wrote:
> Hello C hackers,
>
> I added some temporary debugging output to CallContext's mark VTABLE to see
> what's happening in the GC when Rakudo runs. Look at src/gen/core.pir in the
> Rakudo directory, and especially the first PIR function
Better register allocation will likely lead to some performance
improvement, if only because each context will need to allocate less
storage space for contexts. It probably won't be huge though.
Doing it in IMCC is intractable I think. It's probably okay if basic
PIR doesn't get too fancy with reg
Hello C hackers,
I added some temporary debugging output to CallContext's mark VTABLE to see
what's happening in the GC when Rakudo runs. Look at src/gen/core.pir in the
Rakudo directory, and especially the first PIR function (it's _block67 for me).
This function has 1425 PMC registers and 7
