|
Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3348283 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/ Set by moderator on 1 March 2011. |
|||
| whiteknight | lucian: Which assumptions? Parrot's implementation of it necessarily will be a little bit pluggable | 00:00 | |
| lucian | Tene: single dispatch, existance of methods on objects | ||
|
00:00
jnthn_ joined
|
|||
| whiteknight | If single dispatch is the current reality of 6model, I can guarantee it isn't the final form | 00:01 | |
| TimToady | given that p6 is not assuming only single dispatch, I don't see how you can claim 6model won't support multiple dispatch | ||
| lucian | there's also a method cache | ||
| whiteknight | Parrot has and will always support multiple dispatch | ||
| Tene | lucian: If objects don't have methods, then your object model's response to method calls should be to throw an exception. Method dispatch can do whatever it wants in 6model; that's entirely up to you. | ||
| whiteknight | lucian: we have (bad) method caching in Parrot now | ||
| we cache vtable overrides at a level below the object model anyway, so there's currently no way to avoid that | |||
| lucian | TimToady: i didn't say that. i only claim that 6model is at the very least not optimised for multidispatch and no-methods | ||
| whiteknight: being able to flush the cache should be enough | 00:02 | ||
| whiteknight | lucian: the most important questions we can ask right now are 1) what can we do to make 6model workable for the largest audience by default, and 2) what can we make pluggable about it so other people can get what they want? | ||
| lucian: If you write all your requirements down, we will keep all of them in mind | 00:03 | ||
| allison | whiteknight: those are the important questions for 6model | ||
| TimToady | lucian: 6model is optimized with the assumption that if you know your dispatcher statically it can be optimized regardless of its single or multiple-ness | ||
| jnthn_ | I don't really understand "not optimised for multidispatch", given that it has to support Perl 6 multi-dispatch efficiently. | ||
| TimToady | but multiple such dispatchers are supported | ||
| allison | whiteknight: the important question for pynie is just "what's the simplest way to get a simple implementation of Python running" | ||
| lucian | jnthn_: then i may be misunderstanding | 00:04 | |
|
00:04
davidfetter left
|
|||
| lucian | allison: correction: simple, but complete | 00:04 | |
| TimToady | allison: the word "simplest" is completely fraught :) | ||
| whiteknight | allison: We also have a timing issue. porting 6model into Parrot is a project we haven't even started planning for yet. There are certainly no relevant deprecation notices about it in place yet | ||
| allison | lucian: yes, complete enough for now | ||
| whiteknight | I suppose that a pynie rewrite will precede 6model | ||
| allison | whiteknight: yes, "immediately available" is also important | 00:05 | |
| lucian | whiteknight: it'd be gsoc | ||
| so i'm guessing yes | |||
| allison | whiteknight: it doesn't preclude 6model at some later point | ||
| whiteknight | right, but 6model probably won't be in place by the summer | ||
| jnthn_ | I'm not sure what's not immediately available in 6model. :) | ||
| OK, I am. :) | |||
| allison | whiteknight: it just means 6model is not looking like a good option for right now | ||
| jnthn_ | It's a little bit too tangled with NQP in the odd place. | ||
| lucian | jnthn_: github.com/jnthn/6model/blob/maste...erview.pod isn't clear. could you explain/link multi-dispatch in 6model? | 00:06 | |
| whiteknight | if pynie is implemented now, whatever interface and capabilities it requires will be part of the interface our future object model must satisfy for compatibility purposes | ||
| jnthn_ | But that's mostly about what files we stick lines of code in. | ||
| whiteknight | so if you build your compiler, and we can put a new MOP in place preserving the majority of the interface and semantics, there's nothing to worry about | ||
| allison | whiteknight: that's reasonable, making the immediate implementation a good prototype for future Parrot MOP needs | ||
| whiteknight | and if you put together a custom object model, we'll make sure your custom object model continues to work after the advent of 6model | 00:07 | |
| allison | whiteknight: (in much the same way the Perl 6's needs are gradually working their way down to Parrot core) | ||
| whiteknight | exactly. | ||
| Tene | jnthn_: afaict, there's nothing in 6model that actually requires nqp; the worst is a bit of naming (rakudoobject) | ||
| jnthn_ | Tene: Correct. I don't know what to rename it to. | ||
| 6MObject is an invalid identifier. | 00:08 | ||
| SMObject is...painful. ;) | |||
| lucian | jnthn_: SixObject | ||
| Tene | Which doesn't actually have anything to do with rakudo | ||
| allison | SevenOfNine | ||
| jnthn_ | Tene: No, the name leaked from a prototype. | ||
| lucian | allison: +1 | ||
| jnthn_ | :) | ||
| lucian: The 6model core mostly just does enough to make sure one *can* implement an efficient multi-dispatcher. | 00:09 | ||
| Trying to provide on canonical way to do multi dispatch isn't really 6model's business. It's mostly interested in not defining too many ways you have to do things. | |||
| allison | lucian: one consideration is performance | 00:10 | |
| lucian: the only way to develop high-performance objects in Parrot currently is macroized-C | |||
| jnthn_ | While trying to provide for decent performance along the way. | ||
| lucian | allison: which i find evil | ||
| i'm more interested in performance potential | |||
| allison | lucian: and we are going to be desparate to demonstrate the performance of Python on Parrot compared to CPython and PyPY | ||
| lucian | allison: i'm fine with it being slow | 00:11 | |
| if i can demo pynie and cardinal working together, i'll be satisfied | |||
| Tene: ^ | |||
| allison | mmmm... can we try both strategies? | ||
| whiteknight | over the course of gsoc, a working python compiler is probably more important than a fast one | ||
| it will take more than 3 months to get it working right and then optimize it from top to bottom | |||
| allison | that is, a set of winexed/pir objects, and a set of macroized-C dynPMCs? | ||
| Tene | lucian: Me too. | ||
| whiteknight | allison: in Lorito world, dynpmcs may not be in macroized C anymore | 00:12 | |
| lucian | allison: as a stop-gap optimisation, i guess | ||
| allison | for a gsoc project, agreed, working is more important than fast | ||
| but, for getting any traction in the Python community, fast is critical | |||
| lucian | parrot bytecode dispatch was supposed to be fast | ||
| whiteknight | once we have pynie working, the same things that we need to do to optimize that will need to be done to optimize rakudo, cardinal, partcl, etc | 00:13 | |
| mostly the same things | |||
| lucian | whiteknight: that's one thing i'm skeptical of | ||
| it's part of why i think parrot will never be really fast | |||
| whiteknight | lucian: you're skeptical of a lot of things :) | ||
| lucian | whiteknight: yes :) | ||
| allison | lucian: bytecode dispatch is one thing, objects are another, and PIR objects still have a lot of overhead | ||
| whiteknight | lucian: Parrot is never going to be as fast as something uber-specialized like some of the modern JS VMs | 00:14 | |
| lucian | whiteknight: or PyPy, i'd say | ||
| whiteknight | I consider PyPy to be pretty well specialized, right now at least | ||
| lucian | they still have a lot of relatively low-hanging fruit | ||
| allison | lucian: PyPy is fast in certain applications, not in all cases | ||
| lucian | allison: but it does certain optimisations that are extremely python-specific | 00:15 | |
| allison | lucian: but, yes, they have lots of potential ahead | ||
| lucian | which is my point | ||
| parrot's jit will be relatively general | |||
| it could still be quite fast (like the jvm is for mostly-static languages) | |||
| minusnine_ | well, this all just got a lot more exciting. i have to go, but i'll read the irclogs later. | ||
| lucian | minusnine_: bye :) | 00:16 | |
| whiteknight | Parrot intends to be very pluggable for exactly that reason: We will have opportunities to insert per-language specializations | ||
| minusnine_ | i look forward to slinging code with you! | ||
|
00:16
minusnine_ left
|
|||
| lucian | whiteknight: perhaps. i don't know what'll happen at language boundaries | 00:16 | |
| jnthn_ | So far as I can tell, at the moment, whatever it costs to dispatch a method (in so far as working out what to call) is swamped by the cost of actually doing the invocation of it (e.g. creating and setting up the call context, passing args, etc) | 00:17 | |
| whiteknight | lucian: I like to think that Parrot offers other advantages besides absolute raw performance for a single language | ||
| lucian | jnthn_: right. that's totally the other way around in CPython | ||
| whiteknight: of course, i wouldn't be here otherwise | |||
| TimToady | the main point of 6model is, I think, to support gradual typing, which presumably means supporting *both* dynamic and static notions | ||
| lucian | but i don't think we should be desperate about python perf | ||
| jnthn_ | TimToady: *a* main point :) | 00:18 | |
| lucian | as long as it's reasonable | ||
| TimToady: that's irrelevant for python | |||
| TimToady | you think | ||
| jnthn_ | TimToady: But yes, an important one. | ||
| whiteknight | Parrot has always aimed to provide more features than any single language needs | ||
| lucian | TimToady: how is it? | ||
| allison | whiteknight/cotto: to loop back around to another thread in the conversation, dynpmcs won't be macroized-C in Lorito, but that's probably post gsoc? | 00:19 | |
| whiteknight | allison: I don't know the current lorito timeline, but I can't imagine there will be anything in place before the end of this summer | ||
| TimToady | lucian: obviously, to support the bits that PythonThinks sweeps under the carpet of the runtime | ||
| whiteknight | cotto is optimistic that once the spec is nailed down that implementation of the initial versions will go quickly | 00:20 | |
| lucian | TimToady: i'm not sure i understand | ||
| whiteknight | but then there's the huge effort of rewriting our existing ops and PMCs in lorito, and that will certainly be a long phase out | ||
| allison | whiteknight: me too (confident in initial versions going fast) | ||
| lucian | TimToady: why would the python runtime need to use 6model at all? | ||
| TimToady | a given problem has the same solution space, even if your language hides part of it from you | ||
| allison | whiteknight: but, still a target for later versions of pynie, not current versions | 00:21 | |
| lucian | TimToady: i still don't get it. what does python hide? | ||
| whiteknight | allison: yes, nothing you need to work into your current lans | ||
| allison | to resummarize: it sounds like our best option for a current reboot of pynie is a pure CPython3 module that reads the CPython AST, and dumps PIR, plus a winexed/PIR implementation of the Python core types | 00:22 | |
| with options to depend on other core Parrot features later, as they become available | 00:23 | ||
| lucian nods | |||
| whiteknight | yes, I think that's the best | ||
| the more of it you can write in python and bootstrap, the better | |||
| allison | with the tempting option of writing the Python core data types in Python3, and translating them to PIR using the same method :) | 00:24 | |
| lucian | allison: i don't see how that'd work | ||
| unless it defined a subset | 00:25 | ||
| not even that, it'd have extra things to plug into parrot | |||
| allison | because the translator itself runs in CPython, not in Parrot, so we don't use the core data types until we've already run the translator | ||
| but, I'd consider that a more advanced stage of bootstrapping | |||
| (not to be tried for gsoc) | 00:26 | ||
| lucian | allison: sure, but in terms of what would you write those core types? | ||
| allison | lucian: in terms of the core types | 00:27 | |
| lucian: basically the same as if we'd written them directly in PIR | |||
| but, better to write them directly in PIR first | 00:28 | ||
| lucian | allison: how would you use parrot's Hash from Python3? | ||
| python3 translated to PIR with a compiler | |||
| allison | lucian: do you mean "how would we instantiate it?" or "how would we hide the non-pythonic-features from Python3?" | 00:29 | |
| lucian | allison: second, i guess. how do you even reference it? | ||
| dummy parrot module that the compiler knows about? | |||
| allison | the generated PIR code has access to all Parrot core types, like all PIR does | 00:30 | |
| but, you'd sure want to hide it from Python3 | |||
| lucian | sure, but the code it's generated from (python3) only has access to python3 | ||
| allison | the semantics of Parrot's Hash are wrong for Python | ||
| lucian | yeah, i know | ||
| but you'd still use the Hash to implement dict | |||
| allison | it's a compiler, python3 doesn't understand the PIR code it generates, it just spits it out as a code string | 00:31 | |
| lucian | allison: but it accepts python3 code as input | ||
| that input python3 code has to reference PIR things. how would it do it? | |||
| allison | with some hacks in the translator | 00:32 | |
| lucian | allison: right | ||
| allison | or dummy classes in the Python 3 code | ||
| one or the other | |||
| lucian | also, there's a problem bootstrapping it | ||
| the way i see it anyway | 00:33 | ||
| allison | it's bootstrapping, the turtles have to end at some point | ||
| lucian | you'd need two compilers | ||
| allison | which brings us back to RPython | ||
| lucian | one for regular python3 code, another for python3 code implementing core types | ||
| allison: yes, sort of | |||
| allison | let's not go there for the first implementation | ||
| lucian: do you have any preference between winexed and PIR? | 00:34 | ||
| Tene | allison: "winxed" | ||
| lucian | allison: for actually writing? i'd say winxed | ||
| allison | lucian: or, a sense of which is the simpler starting point? | ||
| lucian | i see no point in writing assembly if i don't have to | ||
| allison | lucian: including the possibility of needing broader semantics for Python? | ||
| lucian: it seems like we can work around semantic limitations if we run into them | 00:35 | ||
| lucian | allison: i don't really know | ||
| the compiler output should likely be PIR, though | |||
| allison | lucian: yes, agreed | ||
| lucian: generating assembly language is no trouble | |||
| lucian: it's a completely different problem than writing assembly language by hand | 00:36 | ||
| lucian | allison: yes | ||
| allison | lucian: winxed is likely better for getting gsoc on it too | ||
| (for the core types) | 00:37 | ||
| lucian | yes. then we can move to specialised compiler + parrot mop | ||
| allison | yah | ||
| lucian | i'd much rather do that from the beginning | 00:38 | |
| higher entry cost, but potential lower cost for corner cases | |||
| allison | do which from the beginning? | ||
| lucian | specialised python3 compiler + parrot mop for core types | ||
| not exactly possible with the state of 6model and so on | |||
| allison | yeah, it's "ideal" versus "immediately possible" | 00:39 | |
| now I'm itching to start the repository and experiment with CPython's AST :) | 00:40 | ||
| lucian | heh | ||
| me too, but i should probably concentrate on my dissertation for now .. | |||
| allison | :) | ||
| lucian | it's even more annoying, because that's interesting as well | 00:41 | |
| allison | I should go grab some dinner | 00:42 | |
| this was really valuable | |||
| lucian agrees | |||
| allison | thanks to minusnine for starting it | 00:43 | |
| lucian | although the conclusion was similar to previous discussions | ||
| lucian nods | |||
| allison | on the core types side, yeah. but we know a whole lot more about the feasibility of pypy versus cpython for the parser component | 00:44 | |
| fortuitous timing on the Python sprints | |||
| allison afk -> dinner | 00:45 | ||
| lucian | allison: have a good meal | ||
|
00:48
lucian left
00:59
cxreg joined
01:09
whiteknight left
01:11
cotto joined
01:24
eternaleye_ is now known as eternaleye
01:41
jnthn_ left,
atrodo left
02:15
ascent left
02:38
ascent joined
03:11
ShaneC left
03:17
plobsing joined
03:31
plobsing left
04:08
ascent left
04:13
ascent joined
04:14
benabik left
06:15
bacek left
06:16
ascent left
06:21
ascent joined
09:59
contingencyplan left
10:07
lucian joined
10:30
lucian left
10:40
bacek joined
12:31
atrodo joined
13:47
bluescreen joined
14:25
bluescreen left
14:36
bluescreen joined
15:38
particle left
15:54
lucian joined
15:55
lucian left
17:44
atrodo left
18:13
contingencyplan joined
18:16
ShaneC joined
19:00
lucian joined
19:02
bluescreen left
19:04
lucian left
22:34
whiteknight joined
|
|||