[perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
On Wed Feb 25 16:08:29 2009, jk...@verizon.net wrote: On Thu Jan 29 06:15:28 2009, Whiteknight wrote: has the remove_pic branch landed yet? Well, it's still an active branch in SVN. So I would guess not. Per discussion on the mailing list, we're removing the remove_pic branch (r41287). Whiteknight already has this ticket. kid51
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
On Thursday 25 December 2008 23:29:28 Allison Randal via RT wrote: CGP is too important to be deprecated over something as small as this. If it were important, we'd test it and maintain the code. We don't, ergo -- c
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: Apparently remove the files isn't exactly what was meant here. This probably removes the need for the remove_pic branch, which is in the process of taking this to its literal extreme. We do need to remove the files, and the remove_pic branch is on the right track. There's just a couple lines of code here and there that have to be kept. The only other place to look is in the JIT code. In src/jit.c, in the 'parrot_build_asm' function, it's using the 'pic_callr__' opcode to invoke a NCI function/JITted sub. src/jit.c:1624 (op_func[PARROT_OP_pic_callr___pc].fn)(jit_info, interp); This opcode may need a new non-PIC variant, and should certainly be converted to use one of the standard calling conventions (PCC or C). (I can come back and look into it in a few days, I'm providing information here to help guide anyone else who takes a crack at it.) BTW, the other failing test in the remove_pic branch was simply because there are fewer elements in the packfile directory now that 'pic_index' has been removed. Fixed in r34401. Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and changes in imc, packfile... lots of references to PIC. chromatic mentioned on #parrot that if we remove PIC, we're going to break all the predereferenced runcores. After some discussion, this probably means ripping out: 16:42 @chromatic Everything other than the default core, the nearly-useless profiling core, and the gc-debug core. He mentioned this in a conversation, but I don't believe it. AFAICT, he's drawing the conclusion from the fact that these cores call some functions (or a function) in src/pic.c. But, the functions I've examined had a small nugget of code that could be moved out of PIC, so the rest of the PIC function could be safely deleted. CGP is too important to be deprecated over something as small as this. Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
On Tue, 2008-12-23 at 17:31 -0800, Will Coleda via RT wrote: chromatic mentioned on #parrot that if we remove PIC, we're going to break all the predereferenced runcores. After some discussion, this probably means ripping out: 16:42 @chromatic Everything other than the default core, the nearly-useless profiling core, and the gc-debug core. So, I vote we update the deprecation notice in trunk to include the runcores (which means delaying the removal until post-0.9.0), and then I can continue the mayhem and destruction that has begun in the branch. Comments? This is certainly a biggie, but I believe we've been doing this on a smaller scale more and more lately: removing functionality and/or optimizations that we don't have the spare cycles to support. On the one hand this is a good thing -- we'll actually hit 1.0 in a few months. I'm all for getting that wider audience. On the other hand, I'm somewhat concerned that Parrot 1.0 will either itself be rather slow, or will architecturally force HLL implementations to be slow. While looking for the IRC discussion mentioned by Coke, I found the following interchange (slightly edited for clarity): donaldh Hmm. Bad memory profile for rakudo. A piece of PIR that runs a SQLite query and prints ~18000 rows tops out at 6 MB when run with -G. The equivalent in Rakudo tops out at 1.6GB chromatic PGE/PCT/Rakudo uses more STRINGs and PMCs. If you disable garbage collection, Parrot won't reuse them. donaldh Sure. I'm just realising how much pressure Rakudo is putting on GC. pmichaud rakudo is somewhat constrained by the architecture Parrot provides, unfortunately. This interchange raised a flag for me. Am I incorrect in seeing this as a problem? Since Parrot 1.0 is supposed to be the stable interface for HLL implementors to aim for, I'd hate for that interface to be very suboptimal, performance-wise, even if it is technically sufficient to get things to *work*. Or is the plan that Parrot 1.5/2.0 are going to include the needed performance and functional improvements as part of the push to production? -'f
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
On Tuesday 23 December 2008 18:47:23 Geoffrey Broadwell wrote: On the other hand, I'm somewhat concerned that Parrot 1.0 will either itself be rather slow, or will architecturally force HLL implementations to be slow. While looking for the IRC discussion mentioned by Coke, I found the following interchange (slightly edited for clarity): donaldh Hmm. Bad memory profile for rakudo. A piece of PIR that runs a SQLite query and prints ~18000 rows tops out at 6 MB when run with -G. The equivalent in Rakudo tops out at 1.6GB chromatic PGE/PCT/Rakudo uses more STRINGs and PMCs. If you disable garbage collection, Parrot won't reuse them. donaldh Sure. I'm just realising how much pressure Rakudo is putting on GC. pmichaud rakudo is somewhat constrained by the architecture Parrot provides, unfortunately. This interchange raised a flag for me. Am I incorrect in seeing this as a problem? Yes and no. That has nothing to do with runcores. The number of GCables allocated is, more or less, constant between runcores. Ideally, the PIR emitted from Rakudo would be require just about as many GCables as hand-written PIR, but if you want to compare that, you're going to have to precompile Perl 6 source to PIR, so that you're not running PGE and PCT and seeing all of the memory they use as well. Compare like to like. I'm not pleased about performance numbers right now either, but the known problems are the multiple calling conventions conversions to compare an Integer PMC with anything else through MMD and our garbage collector. (I suspect Parrot's calling conventions are likewise full of strange decisions.) You (or anyone else) is very much free to dig into that. If removing poorly-written, undertested, undocumented, experimental code that's never worked quite right helps us concentrate on the important things, I'm all for it. -- c
