github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 7 June 2013.
01:52 Jimmy__ joined
benabik Hm. Building with clang fails on OS X with "unknown linker flag -Bstatic". Not really awake enough to track this down. 03:38
Oh, dear. And clang is now default on OS X. I suppose I'll have to track it down at some point. 03:39
Perhaps we need a --gcc flag to counter that. :-/ 03:41
Looks like the generalizing of the build setting added -Wl,-Bstatic and -Wl,-Bdefault to the OS X clang flags. 03:45
Okay, "fixed". Pull request sent, although the fix is a bit of a hack. 03:55
04:50 jlaire joined 05:01 birdwindupbird joined
sorear could (just saying it's possible, not that it's necessarily a good idea) have an optional mode where pointers are relative, for applications where you really do need the fastest load possible 05:05
apparently the JVM does relative pointers, though for a different reason (32-bit indexes allow you to store more objects in a 4-32GB heap on a 64-bit platform; larger heaps use native pointers) 05:07
05:24 sorear joined 07:23 FROGGS joined 12:27 JimmyZ joined
JimmyZ diakopter: \\o 12:49
14:14 benabik joined 14:18 tgt joined 14:48 colomon_ joined 14:49 colomon_ joined
diakopter JimmyZ: hi 15:02
JimmyZ diakopter: hello
PerlJam ls
diakopter sorear: that's interesting
15:04 benabik joined 16:03 FROGGS joined 17:19 colomon joined
diakopter Util: I'm curious about the 'undiscussed' risks you mentioned. Have those uncertainties been alleviated since you mentioned that? 18:43
diakopter seeks to assuage 18:44
Util diakopter: alleviated, no, no to me. Bear in mind that I have only been logging #moarvm, and have not had a change to delve into my logs. 18:45
Risks are in several directions
The strings implementation (what do the functional people call it? not threads...) that your mentioned on stage in Austin, for example. 18:46
nwc10 ropes? 18:47
Util I drooled over it around 2001, when it was brought to Parrot's attention.
diakopter I've been calling it "strands" 18:48
Util Parrot went in the opposite direction, though. We even removed optimizations like internal pointers to start/end of string, which were meant to allow chomp/chop and trimming leading whitespace w/o actual string modification.
diakopter it's actually quite easy to disable entirely; just sprinkle a "flatten" call various places 18:49
I mean, it'll be doing a little extra work, but hardly any 18:50
Util: it's admittedly quite experimental. I've no problem gutting it if actual experiments and usage prove it's not worth it 18:51
benabik Strings ala go slices seem to make a ton of sense to me: pointers to storage, start, end. 18:52
Very efficient substring. :-)
Util diakopter: glad to know that (disabling), but that points out... (Dang, I can't think or type fast enough to be easily coherent. Bear with me, please.)
benabik Although that tends to leave the whole string in memory even when not needed. :-/
diakopter true. I'd planned (and sketched) a quasi-GC scheme to mitigate that 18:53
(using card-marking)
benabik should really finish reading the GC handbook someday soon. 18:54
Util stalled GC handbook around midpoint. So good, though. 18:55
sorear I have held the opinion for several years that "strings" is somewhat too general of an abstraction
I was (not deeply) involved in the low-level strings implementation work for haskell 18:56
Util diakopter: Perhaps we should start with a meta-discussion: If I enumerated every "undiscussed" risk, and you discussed each one with me, some would no longer seem risky to me, and other risks might become clear to you. 18:57
sorear we should probably have two engines: one for potentially long strings, the other for short ones like exist in the compiler symbol table
the optimizations for one are generally pessimizations for the other
and we can't really afford to pessimize parsing
benabik sorear: +1
Util That aspect is of no consequence, relative to 2013-06-07#i_7169707
sorear perhaps I should refrain from commenting on design until I'm an active committer
diakopter sorear: no, it's okay; please comment 18:58
Util Risks are healthy for MoarVM st this stage; I don't want to discourage any tech avenue you might explore (except maybe STM - super-high risk) 18:59
diakopter sorear: I've brought that up to jnthn; he astututely pointed out that we'll almost always parse and regex on strings that are read from IO (so physical strings, not composite ones)
Util The point I was trying to speak to was relative to Parrot's future.
If all goes well with MoarVM, then it is on track to replace Parrot as, well, the equiv of the Perl5-internal VM; i.e. the balls-to-the-wall fastest implementation, which everyone will use (for Perl6) unless they have good reason to go elsewhere. 19:01
10 months, I think jnthn said.
*But*, all might not go well.
diakopter Util: I'm undecided; I think the potential to improve speed well enough has a very big required effort
sorear we don't have to beat the JVM 19:02
Util Any of several technical experiments might fail, a key contributor (or family) might fall ill or take a new job/spouse/offspring.
sorear we just have to beat the NQP implementation on top of the JVM 19:03
Util Wait, it was 10 *weeks*, I remember.
sorear JVM seems to do a better job than .net of optimizing our nasty generated code, but...that's not saying much.
diakopter sorear: that's a good point, but optimizing/JITing the bytecode is the huge hurdle I see
b/c optimizing at the NQP level would help the JVM also 19:04
sorear could jit the bytecode, I have a hunch that a well-designed bytecode interpreter with a code set well matched to NQP *could* compete with the JVM here 19:05
diakopter depends what "well-matched" ends up meaning. currently it's pretty close to 1:1
sorear exactly 19:06
Util My point is, that it would not take much disruption before MoarVM's schedule of deliverability (to replace Parrot for NQP and Rakudo) is delayed to the point that Rakudo must also be disrupted, *unless* Parrot keeps on moving forward. 19:07
diakopter I mean, as far as eliminating "interpreter overhead" goes, the bigger the instruction set, the better, because stuff can be so widely specialized, and a single opcode can refer to hundreds of thousands of cpu instructions
benabik Util: Or the JVM backend. 19:08
diakopter Util: I'm not sure I agree with that; I think there's still so much to be done on Rakudo that's not blocked at all by any platform that it could proceed for years with no platform movement 19:09
things crucial to making design progress, yes
moritz diakopter: but missing features aren't really the major blocker to adoption, it seems
performance and reliability are 19:10
diakopter true.
well
they're certainly as big.
masak Util: "keeps on moving forward"?
[Coke] (just keep swimming) 19:11
diakopter *giggle*
"mine" "mine" "mine" "mine" "mine"
Util masak: (just a moment) 19:13
diakopter bbi 20 min
Util At several key points in both Parrot and Rakudo's histories, someone saw a clear path to replace a piece with something better, and started working on that replacement.
People were told about the work, and started acting that the future was the present.
Often, the work completed on time, and we all saved a lot of effort from our assumption that the new thing would (a) arrive in time, and (b) actually be better.
The times that (a) or (b) failed, had impacts out-of-proportion to the effort that was almost saved.
diakopter er, 40 min
um, fast typing or fast pasting? :)
Util I am rooting for MoarVM, but I am unwilling to risk another M0-occurance in order to save the labor on Parrot and go work on the very-cool new MoarVM. 19:14
diakopter I suspect you might not have a good idea of how much work/progress is in moar already 19:15
Util diakopter: Yes, the perfectionist in me must pre-type in a buffer to spare the world my imperfections.
diakopter okay, really afk 40 min 19:16
Util diakopter: OK
PerlJam Util: what do you mean by "risk another M0-occurance"? 19:17
Util masak: (a) Be responsive to Rakudo in the small: build the pieced that are needed in, say, 1-2 week scopes.
masak Util: to be perfectly honest I don't think Rakudo would suffer much at this point if Parrot development mysteriously ceased completely. 19:18
Util: from my perspective, that's basically what's happened already anyway.
except perhaps for the "mysteriously" part. 19:19
Util (b) Keep (or rebuild) some momentum for the larger tasks/branches, like calling convention improvements, cotto's (and benebik's?) fat-trimming branches, etc.
masak: "at this point", I agree.
masak re (b), good luck.
just let me draw a sigh of relief that Parrot is no longer the only basket capable of carrying Perl 6 eggs. 19:20
Util masak: Between this point, and the point you don't need Parrot *at* *all*, I am unwilling to risk.
masak: (basket): me too
sorear Util: i intend to keep working on rakudo/jvm until I am satisfied with its awesomeness level 19:24
Util sorear: Very glad to hear that. 19:27
19:46 eternaleye joined
diakopter Util: I should've more directly stated that no one's given a good summary of what's already "accomplished" in MoarVM 22:20
"what works" is kinda misleading at the moment 22:21
22:49 ggoebel joined 23:30 tomyan joined
diakopter jnthn: I thought of a way to manage extensions and how they register additional opcodes 23:39
jnthn diakopter: Cool. I've been thinking about it as a "register a bank" thing 23:40
We'll need that for Rakudo 23:41
diakopter my way packs them...
23:42 tomyan joined
diakopter jnthn: I'll write it up and post it as an issue. much easier than discussing/explaining here 23:43
jnthn +1
diakopter hm, you're up loate
late, even
jnthn It's the Hot Season, and when work is scarce. I've largely shifted my timezone. 23:44
Also, it's midsommar, which means we stay up and rink lots"!
uh, *drink, *lots!
diakopter also, rink. 23:45
jnthn
.oO( it's working! )
sorear read that as rink lots™! 23:46
masak is also up late! :D 23:53
sorear masak! :D
masak \\o/
try "Offley Porto Wine aged in wood Cachucha Reserve White". it's very smooth.
works well with bits of cheese, licorice, chocolate, figs and dates. 23:54
jnthn we...had figs too?
I thought I was just eating dates :P
masak jnthn: I don't think you had one of the figs.
there's two left :P 23:55
jnthn oh, I eated one of them already :P
yeah, it's not a date
masak thinking it was a date? lol!
jnthn Story of my life :/ 23:56
masak .oO( "dude, this is not a date" moment... )
diakopter jnthn: will we/anyone ever be distributing .moarvm files? 23:59
(or .mvm or whatever)

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!