This is all 1099 work, so we're responsible for all the taxes. Also don't forget that 20% of the grant is dedicated to travel and outreach, and we're also responsible for paying the health insurance and other things that we'd otherwise get through an employer.
Yes, of course. The specification's documented (albeit a bit fuzzily, but we're working on that) in the parrot distribution. There are already several language implementations for Parrot which are included with the kit, and there are other projects (I know of one to port Ruby) in the works to target Parrot.
Parrot will juice performance boosts at the sacrifice of built-in safety.
You misunderstood my comments, apparently. Perl, python, and ruby all, right now, have unsafe interpreters. This isn't anything new--you feed in bad optrees or bytecode to most interpreters and they'll do horrible things. Checking for safety at this level, when running plain code for which you don't choose to be paranoid, is a drain on performance with no corresponding benefit.
If you do choose to not trust your bytecode, you can run it in a safe interpreter, which will check to make sure everything is proper. You'll pay the corresponding performance penalty, but that's fine as you've asked for it at that point.
Most of the code that most people execute is trusted code, and for that there's just no win in double-checking it at runtime. And for those rare (relatively) cases where you do care, you can be paranoid and run safely.
(The CLR's certainly not safe either. Use some unchecked code, of which there's likely to be a lot, and you're just as unsafe)
Clarification:
Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.
Erm.... you did. The last line of that posting was:
Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).
Still, they're not going away as they're useful. That you don't like the syntax change is a separate issue entirely.
Character classes have changed to <[]> which isn't that big a deal. bare [] are used for non-capturing grouping. It's a reasonable choice--most people use non-capturing groups more than character classes.
Though it's not done yet. (I'm writing it as I type this:) Additionally, if you're interested, I'll be giving a half-day tutorial on this at O'Reilly's OS X conference at the end of September/beginning of October. As time permits there should be a few articles about it on oreillynet.com, too.
Yup, I've got the update. Got it before I installed silk, and the fonts in question had problems with anti-aliasing enabled then. And in AppleWorks under OS 9 with fractional character widths turned on. It's definitely the fonts that have mildly whacked medatada somewhere, not PowerPoint or Quartz. Still, they look good without the extras, so I've no cause to complain.
I've found some fonts that don't work at all well with anti-aliasing. I ended up having to turn it off in PowerPoint, as they end up being the fonts that I like to use in presentations...:(
This doesn't work at all well. Tried it, no joy. The problem is that Cocoa only works with real, honest-to-goodness applications, and you have to load the frameworks in the right order.
CamelBones is the way to go. Full perl bindings to Cocoa, the ability to build standalone apps, and full integration with Project Builder and Interface Builder. It's sweet, and well worth fetching.
Re:additional corrections
on
Parrot Updates
·
· Score: 1
Yes, the JVM is an interpreter. And yes, it is stack based. And no, there is no trivial transformation from stack to register based architectures. (There are transformations, but they're not trivial, and the result is often not great) And the restricted stack approach that the JVM and CLR take does not have both the efficiency advantages of register machines and the compactness of stack machines. You can't do that.
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 1
I wasn't calling the design of the interpreter dumb. I see how it could be taken that way. When I said dumb, I meant as in "dumb terminal" (somwthing without knowledge). The interpreter just seemed to look at an operation and do exactly what asked of it, not optimizing on the fly. A language called K from http://kx.com is a smart interpreter in the sense that it does semantically what it is asked, but not necessarily how you ask it to be done and it will blow C code out of the water many times. It is based on APL coolness and tricks, like not actually calculating the entire matrix being operated on, but only the section that is examined at the end.
Currently the interpreter does do what you ask it to, and nothing more. (Or less) The compiler is left with the task of emitting reasonably clever code.
That doesn't mean we haven't taken lazy evaluation into account, but there are limits to what we can do. All the languages that are likely to run on the parrot engine have the potential for a lot of side-effects, and runtime dependency checking for that stuff usually ends up costing more than you gain.
There are some areas where this sort of partial and lazy evaluation get you big wins, but they're pretty specialized areas. APL and Fortran will probably always be faster in their areas of particular specialty.
Re:performance of big programs? compatibility?
on
Parrot Updates
·
· Score: 1
You'll need to change a bunch of stuff to build as native perl 6 anyway--array and hash access syntax is different in perl 6. It's just one more thing to change.
I'll file a note to add a "potential compatibility issue" warning to things so you can get warned if you call any routine that behaves differently in perl 5 and perl 6. (Off by default, of course)
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 1
I am a very big fan of stack machines and I think that an intelligent implementation can be built that would blow the doors off any finite register machine:
Then go do it and prove my design wrong. I think you wildly underestimate the amount of complexity you're contemplating.
Why does everybody always want to make dumb interpreters and not something more intelligent?
Not everybody does. But just because you disagree with the design doesn't make it dumb.
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 3, Insightful
Since this seems to be serious, please consider the advantages of a mixed register+stack machine. With 3 32 bit stacks and one 64 bit stack (though if you are using FORTH, you can use the FORTH model, and drop the last one at the expense of having a set of double-cell primitives.
This has been part of the design from the very beginning. In addition to a general purpose stack, each of the register types has a stack associated with it so you can push and pop all the registers of a particular type at once.
The reason for hardware registers is that in hardware fast memory is an expensive and scarse resource.
That's not the only reason. Bits and memory bus bandwidth are also scarce resources, and a small set of named scratchpad spots allows for significant speedups over fully qualifying everything with a memory location.
But in a software implementation, the registers run in the same memory space as the rest of the program. So they loose many of their advantages.
Many, but not all. The stack thrash is a big issue as well and, while there are ways to get around it by allowing references back in the stack, they're generally more awkward than a plain register setup.
There's also an awful lot of literature on writing optimizers which is geared towards register machines, as that's what everyone's CPU is these days. I've not found much readable literature on optimizing a pure stack-based system.
They can, however, save a level of indirection. And that can speed things up if it's on something that is being done frequently. So one alternative is to define the largest stack frame that one wishes to allow for, provide a way for a stack frame to be copied to a fixed location, and then have analogous operations based either on the fixed location, or on a stack frame pointer in the stack. So the stack is a set of modifiable stack frames (though only the top stack frame at any time is resizeable).
Congrats, you just described a register-frame system. Which is what we already have.:)
However, if one isn't modeling an existing hardware implementation, then the virtual machine should not end up looking like any of the hardware.
One is always modelling hardware. That's what this stuff ultimately runs on. You can't ignore the underlying system if you want really good performance. And while a good chunk of our userbase is running on register-starved systems (x86) a lot aren't. The design's not got any serious disadvantages relative to a stack system on x86, and some good advantages on machines with plentiful registers (alpha, sparc, PPC, MIPS, IA64) so it's a win.
Re:I hear Perl 6 will use Mono's JIT engine
on
Parrot Updates
·
· Score: 1
Ummm... no. 'Fraid not.
Re:I hear Perl 6 will use Mono's JIT engine
on
Parrot Updates
·
· Score: 2, Informative
Nope. Borrow some of the ideas, certainly, but our JIT's hand-rolled.
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 5, Interesting
The "Parrot Implementation Issues" piece suggests to me that the developer hasn't done any research or have much idea of the field they're programming in. Now, of course, it could be that the FAQ is merely flippant
That would generally be the case. Most of the folks reading FAQs on this stuff don't have the background for a good discussion on this stuff, and the FAQ really isn't the place for it.
* Java is not the only stack based interpreter out there - and is far from being a good example of one. Even ignoring FORTH which is a full blown language based around the idea, there's the UCSD p-System,
Forth doesn't count--it's really not an interpreter or VM as such. And the UCSD p-System (which I did know about) ran on systems that are profoundly obsolete. The base hardware's a bit more capable than the 6502s in Apple ][s. (Much as I liked both)
One example I didn't mention but should have was Visual Basic, which is apparently a stack-based interpreter system.
A stack based system has architectural advantages over a register based system. It may be the FAQ author considered them, but it'd be nice to actually see acknowledgement rather than an assumption that such advantages are easily explained away. Register systems have a finite structure which, ultimately, will limit the overall design of the end product and intrude into how efficient it can be. Stack based systems have no such limitations - a stack is a stack.
And register based systems have advantages over stack based systems. An awful lot of stack thrash is avoided in a register system--with more temp values handy you don't have the extraneous dups, stack rotates, and name lookups.
And just because we have registers doesn't mean we don't have a stack. We do. (Several, actually) But registers let us toss a lot of the useless shuffling.
The 68000 emulator on the Mac is somehow proof that register based VMs are the way to go
...Ever run UAE on an Intel CPU? You need to get into Pentium territory to get it to look like a damned A500
The 68K emulation on the Mac is proof that it works and is viable, not that it's the way to go. And UAE's troubles are as much architectural issues (the x86 chip is really register starved) as anything else.
Parrot's ops are generally not as low-level as machine instructions, so even if the register system was dreadfully inefficient compared to a stack system (and it's not, parrot's numbers are good) not that much time is spent dealing with it anyway. (Though I don't want to trade off even 3% speed hits)
Maybe all these issues were answered, but if you're going to put together a FAQ, a "Yeah, I thought of it, but those ideas suck, mine's much better, but I'm not telling you why, indeed, I'm going to use the worst possible examples to demonstrate how little research I did into this" answer isn't terribly inspiring.
This is dead-on. I'll get some more meat into the FAQ.
Adam might
...
I might, actually. Adam just pasted in my answers to the technical stuff.
Re:best FAQ read in awhile
on
Parrot Updates
·
· Score: 1
The project's too important to perl to take seriously, and no software's so important it's worth getting pompous over.:)
Re:performance of big programs? compatibility?
on
Parrot Updates
·
· Score: 4, Interesting
The perl parser's not written in perl for efficiency (both speed and memory use) and convenience (yacc is nice for some things, after all) reasons. Parrot's addressing the efficiency issues, and at this point there's more than enough knowledge and tools to get a good perl parser written in perl.
As for compatibility, your perl 5 code will call routines that return perl 5 compatible values. The perl 6 code will call routines that return perl 6 compatible values. It'll work--it's a simple enough problem to deal with.
The LN2 went into small containers because they got it in a rather large (like 1.5M tall) container. There was a hunk of copper tubing hooked to the valve on the big tank. Unfortunately the copper tubing was rather warmer than the LN2, so the LN2 had a disconcerting tendency to heat up and go gaseous by the time it hit the end of the tube. Gaseous nitrogen's just a little bit less dense than the liquid, so sometimes you'd get this huge gout of gas spewing into the ice cream mix. While much hilarity (and splattered ice cream mix) ensued, it didn't make for great ice cream.
Putting it into containers and pouring made it so the gas could spout out harmlessly, since the containers were empty.
Slashdot Mirror
This is all 1099 work, so we're responsible for all the taxes. Also don't forget that 20% of the grant is dedicated to travel and outreach, and we're also responsible for paying the health insurance and other things that we'd otherwise get through an employer.
Yes, of course. The specification's documented (albeit a bit fuzzily, but we're working on that) in the parrot distribution. There are already several language implementations for Parrot which are included with the kit, and there are other projects (I know of one to port Ruby) in the works to target Parrot.
If you do choose to not trust your bytecode, you can run it in a safe interpreter, which will check to make sure everything is proper. You'll pay the corresponding performance penalty, but that's fine as you've asked for it at that point.
Most of the code that most people execute is trusted code, and for that there's just no win in double-checking it at runtime. And for those rare (relatively) cases where you do care, you can be paranoid and run safely.
(The CLR's certainly not safe either. Use some unchecked code, of which there's likely to be a lot, and you're just as unsafe)
Character classes have changed to <[]> which isn't that big a deal. bare [] are used for non-capturing grouping. It's a reasonable choice--most people use non-capturing groups more than character classes.
Go reread the Apocalypse. Character classes aren't going away at all.
Though it's not done yet. (I'm writing it as I type this :) Additionally, if you're interested, I'll be giving a half-day tutorial on this at O'Reilly's OS X conference at the end of September/beginning of October. As time permits there should be a few articles about it on oreillynet.com, too.
Yup, I've got the update. Got it before I installed silk, and the fonts in question had problems with anti-aliasing enabled then. And in AppleWorks under OS 9 with fractional character widths turned on. It's definitely the fonts that have mildly whacked medatada somewhere, not PowerPoint or Quartz. Still, they look good without the extras, so I've no cause to complain.
I've found some fonts that don't work at all well with anti-aliasing. I ended up having to turn it off in PowerPoint, as they end up being the fonts that I like to use in presentations... :(
I'd definitely use Objective C over Java for Cocoa code--it meshes much better with the way Cocoa works, which isn't much of a surprise.
Still, you can use the Interface Builder with CamelBones. It's possible to build a fully GUI based app entirely in perl.
This doesn't work at all well. Tried it, no joy. The problem is that Cocoa only works with real, honest-to-goodness applications, and you have to load the frameworks in the right order.
Yep, a while off. A few chapters done, and more to come. (Sez the man feverishly writing the thing... :)
CamelBones is the way to go. Full perl bindings to Cocoa, the ability to build standalone apps, and full integration with Project Builder and Interface Builder. It's sweet, and well worth fetching.
Yes, the JVM is an interpreter. And yes, it is stack based. And no, there is no trivial transformation from stack to register based architectures. (There are transformations, but they're not trivial, and the result is often not great) And the restricted stack approach that the JVM and CLR take does not have both the efficiency advantages of register machines and the compactness of stack machines. You can't do that.
That doesn't mean we haven't taken lazy evaluation into account, but there are limits to what we can do. All the languages that are likely to run on the parrot engine have the potential for a lot of side-effects, and runtime dependency checking for that stuff usually ends up costing more than you gain.
There are some areas where this sort of partial and lazy evaluation get you big wins, but they're pretty specialized areas. APL and Fortran will probably always be faster in their areas of particular specialty.
You'll need to change a bunch of stuff to build as native perl 6 anyway--array and hash access syntax is different in perl 6. It's just one more thing to change.
I'll file a note to add a "potential compatibility issue" warning to things so you can get warned if you call any routine that behaves differently in perl 5 and perl 6. (Off by default, of course)
There's also an awful lot of literature on writing optimizers which is geared towards register machines, as that's what everyone's CPU is these days. I've not found much readable literature on optimizing a pure stack-based system.
Congrats, you just described a register-frame system. Which is what we already have.Ummm... no. 'Fraid not.
Nope. Borrow some of the ideas, certainly, but our JIT's hand-rolled.
One example I didn't mention but should have was Visual Basic, which is apparently a stack-based interpreter system.
And register based systems have advantages over stack based systems. An awful lot of stack thrash is avoided in a register system--with more temp values handy you don't have the extraneous dups, stack rotates, and name lookups.And just because we have registers doesn't mean we don't have a stack. We do. (Several, actually) But registers let us toss a lot of the useless shuffling.
The 68K emulation on the Mac is proof that it works and is viable, not that it's the way to go. And UAE's troubles are as much architectural issues (the x86 chip is really register starved) as anything else.Parrot's ops are generally not as low-level as machine instructions, so even if the register system was dreadfully inefficient compared to a stack system (and it's not, parrot's numbers are good) not that much time is spent dealing with it anyway. (Though I don't want to trade off even 3% speed hits)
This is dead-on. I'll get some more meat into the FAQ. I might, actually. Adam just pasted in my answers to the technical stuff.The project's too important to perl to take seriously, and no software's so important it's worth getting pompous over. :)
The perl parser's not written in perl for efficiency (both speed and memory use) and convenience (yacc is nice for some things, after all) reasons. Parrot's addressing the efficiency issues, and at this point there's more than enough knowledge and tools to get a good perl parser written in perl.
As for compatibility, your perl 5 code will call routines that return perl 5 compatible values. The perl 6 code will call routines that return perl 6 compatible values. It'll work--it's a simple enough problem to deal with.
I'll nudge the perl-foundation.org folks and see what they can do. (No idea how much work's involved, or what paperwork needs filing for access)
He was invited. He just couldn't make it that weekend. Which was a pity, because I wanted to discuss getting an INTERCAL parser for Parrot... :)
Putting it into containers and pouring made it so the gas could spout out harmlessly, since the containers were empty.