Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today” | Accepted GSoC Students announced! | GSoC student information emails coming out soon
Set by moderator on 26 April 2011.
bacek_at_work seen benabik 00:04
aloha benabik was last seen in #parrot 5 hours 7 mins ago saying "I was fascinated by Hurd for a while... Then I found MINIX. Then I decided I don't have enough free time to make either really worth while.".
whiteknight Tene: I'm extremely interested in all that information. Both your prior attempts and your future ideas 00:06
Tene whiteknight: Hm? Interested in how I was screwing something up? 00:07
whiteknight yes
that kind of experience is extremely valuable
helps us to avoid mistakes going forward 00:08
or, avoid the same ones. I plan to make new, novel mistakes
lucian r.e. benabik's last comment. an exokernel parrot port would be awesome 00:10
hmm, interesting conversation on freenode#pypy 00:35
ionmonkey may spell the death of nanokit
jit
cotto_work interesting
It seemed like Firefox was its big user. 00:37
dalek rrot/m0-prototype: c5e1b43 | cotto++ | t/m0/m0bgen.t:
add some subs to calculate the size of mob chunks
 00:45
whiteknight I know FireFox was the big user 00:46
and if nanoJit dies, we won't be using it for PArrot
unless we want to try to adopt it wholesale for Parrot 00:50
but that seems like a waste
cotto_work: I think nanoJIT was made expressly for FireFox 00:52
00:52 whiteknight left
cotto_work tonight, I generate valid m0 bytecode 00:54
lucian afaik, Adobe started nanojit, and it got forked when mozilla was gifted tracemonkey 00:58
bah, i'm really getting sick of this dissertation. and i'm very likely complaining too much 00:59
cotto_work: that sounds epic 01:05
bah, firefox memory usage is insane (at least on osx) 01:06
i wonder how on earth tomshardware benchmarked firefox to have the least average memory usage
Tene lucian: I have to restart firefox daily to deal with memory usage growing.
lucian on what platform? 01:07
Tene Chrome, however, just uses too much ram constantly.
linux x86_64
Fx 4.something
it wasn't so bad on 3.whatever
lucian chrome does use a lot, yes
but if i close tabs, it shrinks fast
i think firefox has really crappy JS and xpcom GCs 01:08
bubaflub lucian: i've noticed that as well
i'm also on OS X and have to switch between Safari, Firefox, and Chrome for browsing sanity 01:09
i blame flash plugins remaining resident in memory long after they should be dead
01:10 bluescreen joined
lucian i mostly just stick to chrome 01:12
atrodo cotto_work> m0 night, eh? 01:13
lucian bubaflub: hmm, chrome memory usage with 30 tabs < firefox memory usage with 1 tab 01:15
bubaflub lucian: hmmm. i haven't been very scientific about it. i try to close or migrate my tabs consistently. i keep safari for non-flash pages (i have ClickToFlash). i also like the reader feature. 01:16
lucian if you use more than one browser at a time, it's likely they'll each load lots of things 01:17
01:29 benabik joined
benabik ~~ 01:31
01:34 rohit_nsit08 left 01:35 rohit_nsit08 joined 01:36 davidfetter left
bacek_at_work benabik, aloha. How is your gsoc going? 01:39
benabik bacek_at_work: Greetings! Not very much GSoC work yet. Put up an intro blog and a fork of parrot. But I'm trying to finish a couple projects and a term paper. :-/ Finals in 2 weeks, then I get to dig in. 01:41
bacek_at_work benabik, ok. We still have plenty of time :)
cotto ~~ 01:42
lucian, I'm only generating valid bytecode. Running it and generating *useful* bytecode are entirely different matters.
lucian cotto: i see 01:43
cotto but it's an important step
01:44 rurban_ joined
benabik bacek_at_work: Really really looking forward to digging into Parrot. It's what keeps me motivated on the more irritating schoolwork. :-D 01:44
01:46 rurban left 01:47 rurban_ is now known as rurban
lucian benabik: SCHOOLWORK IS EXTREMELY IRRITATING, ISN'T IT? 01:56
benabik lucian: Tell us how you really feel about it. :-D 01:57
lucian i don't want to segfault perlnet
02:29 woosley joined
tcurtis gets to give a lightning talk about his project at the Chicago GSoC meetup next Thursday. 03:12
cotto tcurtis, awesome 03:24
03:27 hudnix left
cotto Hacking in Perl 5 after doing PHP all day is like a breath of fresh air. 03:28
03:36 mtk0 left
cotto Wheee. I found a problem in the M0 spec. 03:42
03:43 mtk0 joined 03:44 lateau joined
sorear Aren't you glad it has a version now? 03:46
cotto That'd matter a lot more if anything could read it. 03:47
03:54 ShaneC joined 03:55 lateau left
cotto dukeleto, ping 04:10
dukeleto cotto: pong 04:12
04:13 bubaflub left
cotto dukeleto, any thoughts on adding type information to the M0 variables table? 04:13
presumably we'll be storing different types in there anyway, so adding explicit information will make the format less opaque 04:15
dukeleto github.com/brixen/poetics 04:59
Native implementation of CoffeeScript on Rubinius
05:17 cotto_work left
dalek rrot/m0-prototype: 8a354c4 | cotto++ | t/m0/m0bgen.t:
make m0b generation code "work"

The code seems to be correct and generates sane-looking results, but it'll be hard to tell if it's actually correct without an actual interp.		 05:17
rrot/m0-prototype: f2263b3 | cotto++ | t/m0/m0bgen.t:
finish fake mob generation code, add a batch of failing tests

At this point I'm only marginally confident that the generated M0 bytecode is correct, but I'd much rather start writing the interp than stare at a hexedit some more.
cotto It seems that "false" makes a poor M0 interp. I guess I'll have to write a real one. 05:18
dalek website: tcurtis++ | The adventure begins 05:20
website: www.parrot.org/content/adventure-begins
lucian dukeleto: were you in freenode#coffeescript ?
dalek rrot/m0-prototype: 1339338 | cotto++ | t/m0/m0bgen.t:
update test plan for the M0 interp tests
cotto tcurtis++
05:30 cosimo joined
dukeleto lucian: no, why? 05:35
tcurtis++ # bloggin' 05:36
05:36 lucian__ joined
dukeleto "But maybe if someone provides some nice suggestions, either by email or on #parrot, the Parrot community will be spared this travesty of nomenclature." 05:36
lulz 05:37
msg tcurtis my suggestion for the name is "lollerskates"
aloha OK. I'll deliver the message.
cotto tcurtis, I'm not sure what dukeleto's talking about, but I approve. 05:38
dukeleto cotto: knowyourmeme.com/memes/lollerskates
05:39 lucian left
cotto dukeleto, of course. I'm reading his post now to get the context. 05:39
dukeleto msg tcurtis look how many logos you have to choose from already! knowyourmeme.com/memes/lollerskates
aloha OK. I'll deliver the message.
dukeleto cotto: mea culpa 05:40
msg tcurtis or possibly lalrskate
aloha OK. I'll deliver the message.
cotto Sweet. We'll get an algorithm that was published in the year I was born. 05:41
'80s GC, '80s parser generator 05:42
now all we need is an '80s soundtrack
dukeleto slow and steady wins the race 05:43
KaeseEs cotto: i nominate Powerslave 05:51
05:56 lucian joined 06:00 lucian__ left
dalek rrot/m0-spec: 73df301 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a place in the binary format for the M0 version number
 06:11
rrot/m0-spec: a36275c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
delete a TODO about where the version should go
 06:12
rrot/m0-prototype: 6d5fd46 | cotto++ | t/m0/m0bgen.t:
update m0bgen with version number, make header code more readable
 06:16
06:23 particle1 left 06:24 fperrad joined
cotto dukeleto, I'd appreciate an eye on t/m0/m0bgen.t to make sure it's sane. 06:28
dalek rrot/m0-prototype: 0276976 | cotto++ | t/m0/m0bgen.t:
clean up after ourselves
rrot/m0-prototype: 0174b30 | cotto++ | src/m0/m0_interp.pl:
beginnings of the prototype M0 interp
cotto time for sleep.
06:33 rohit_nsit08 left 06:44 theory left 07:15 dod joined 07:36 rhebus joined 07:37 lateau joined 07:45 mj41 joined, cosimo left 07:51 UltraDM joined 07:53 rhebus left 08:01 lateau left 08:35 bluescreen left 08:38 jrt4__ left
bacek ~~ 08:56
08:57 contingencyplan left 09:00 rohit_nsit08 joined 09:06 lucian left 09:08 lucian joined 09:13 lucian_ joined 09:17 lucian left 09:45 rurban_ joined 09:46 rurban left 09:47 rurban_ is now known as rurban 10:09 woosley left 10:23 particle joined 10:38 woosley joined, lucian joined 10:43 lucian_ left 11:24 mtk0 left 11:30 mtk0 joined 11:57 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 12:06 woosley left 12:09 whiteknight joined
whiteknight good morning, #parrot 12:17
interesting article today about source control: www.troyhunt.com/2011/05/10-command...ntrol.html
12:55 ambs joined
lucian whiteknight: i'm not sure i agree with the last one 12:57
coke_ was that "dependencies" ? I mentally translated that one to "make sure your dependencies are easily installable", not "exist in the vcs" 13:01
13:01 bubaflub joined
whiteknight I've seen it done both ways. 13:02
moritz s/the vcs/a vcs/
whiteknight I had a boss at my last job who insisted on including the whole IDE in svn
coke_ urg?
whiteknight I thought that was bananas, but keeping some libraries in there is nice
In general, it depends. If the dependency is easy enough to get yourself and easy enough to keep up to date, it's no big deal 13:03
coke_ I have a build.xml (ARGH) that I use to fetch all the deps I need. 13:05
whiteknight I think that counts 13:06
coke_ I am "fighting" with developers new to svn who want to include the entire unzipped 3rd party libraries into their own project.
whiteknight I mean, whether you have the dependencies themselves, or a mechanism to fetch the correct ones automatically makes no functional difference as far as I am concerned
where libraries become a problem is if somebody updates to a new version of the lib
13:29 ambs left 13:34 hudnix joined 13:35 lateau joined
whiteknight seen cgaetner 13:37
aloha Sorry, I haven't seen cgaetner.
whiteknight seen cgaertner
aloha cgaertner was last seen in #parrot 30 days 23 hours ago saying "btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that...".
whiteknight blah
13:44 lucian_ joined 13:47 lucian left 13:48 lucian_ is now known as lucian
whiteknight opbots trust lucian 13:51
slavorg But I already trust lucian
slavorgn But I already trust lucian
whiteknight opbots names 13:52
lucian ? 13:53
whiteknight ??
lucian i was wondering what you were trying to do 13:54
whiteknight lucian: I'm making sure you have ops 13:57
lucian i see
i don't really know what they do :)
whiteknight basically, nothing
but my IRC client sorts usernames with ops at the top, and now I can actually see when you are signed on without scrolling
AND I AM WATCHING YOU
lucian yeah, my client does the same 13:58
I FOUND THE PROBLEM! dammit 14:00
whiteknight what problem? 14:02
14:02 bluescreen joined
lucian in my dissertation demo 14:03
sadly it's hard to fix and i have little time ...
i've had this problem for very long, too
14:07 hudnix left 14:08 hudnix joined 14:09 cotto_work joined
whiteknight when is the demo? 14:10
and will you be videotaping it and sending me a link?
:)
PerlJam whiteknight: ask if there's remote participation. Maybe you can heckle^Wparticipate. 14:11
:)
lucian no remote participation. i'll consider videotaping 14:16
whiteknight I used to love going to dissertations and other presentations when I was in school 14:18
PerlJam whiteknight: I always liked going to the ones that weren't train wrecks. 14:19
when they were clearly not prepared (i.e., their chair wasn't doing his/her job) it was just sad. 14:20
whiteknight My thesis presentation ended up being shorter than I anticipated. I talked too fast and had too few questions 14:21
so that was disappointing 14:22
14:22 Andy joined
lucian mine'll suck immensely 14:23
PerlJam lucian: but you'll get through it, they'll suggest some minor changes, everyone will sign off on it, then party time! 14:25
lucian PerlJam: meh, if i don't fail the year 14:26
whiteknight that's the spirit! 14:28
pmichaud hola, #parrot 14:30
PerlJam greetings pmichaud!
whiteknight good morning, pmichaud
pmichaud just a quick note that I'm getting some very strange timings on the core.pm test that bacek++ cited earlier today 14:31
whiteknight strange in the good way?
pmichaud no
whiteknight damnit. It's never the good way
pmichaud first time I did the test, core.pm with Parrot 3.0 took 900s to compile
I then tested with Parrot 3.3, took 300s. I'm thinking "wow, 66% speedup!"
I then recompiled core.pm with Parrot 3.0, it took 270s the second time 14:32
jnthn__ lolWUT?!
PerlJam vagaries of GC?
pmichaud so, I rebooted, untarred a fresh copy of Rakudo 2011.01 (Parrot 3.0), rebuilt and did the core.pm test: 200s
whiteknight is that Parrot 3.3.0 with --gc=gms?
jnthn__ pmichaud: Some adaptive CPU thingy? 14:33
pmichaud yes, 3.3.0 with --gc=gms
whiteknight pmichaud: my suggestion is to keep compiling, because it gets faster every time
jnthn__ lol
whiteknight pmichaud: when it gets down to 10s, stop touching it
:)
PerlJam how many GC runs does parrot go through when compiling core.pm?
pmichaud PerlJam: I don't know
jnthn__ fwiw, I've found nqp test times quite stable. Though it's a much smaller workload...
whiteknight PerlJam: that is a very good question. I have to assume GC churn there is quite high 14:34
PerlJam that's what I'd guess too
jnthn__ Yeah, but gen-gc can run regularly...the nursery is meant to be small.
whiteknight I'd suggest profiling it, but there may not be enough time left in the universe
jnthn__ Compared to the entire working set.
pmichaud I don't have an easy way to count the gc runs for Parrot 3.0 14:35
whiteknight what we could do is insert some kind of stderr debugging statement in the function that runs it
print out a count
pmichaud that starts to get messy :(
PerlJam pmichaud: also, did you only have the one really long run? Maybe something else was going on on your system at that time?
whiteknight I never said it would be pretty, but for a first blush it will give us a general ballpark count 14:36
pmichaud PerlJam: that's what I'm guessing now -- something else must have been running on the system
PerlJam: but even so, the difference between 300s and 200s is pretty big also 14:37
whiteknight pmichaud: yes, that is pretty big. We would expect some small regressions because of the way we are handling packfiles now, but that can't be adding up to 33% of the total
I'm talking about a handful of new PMCs in the old generation 14:38
so 100s difference there is pretty extreme
pmichaud just ran again with 3.0: 207s 14:41
trying 2011.04/3.3...
PerlJam you'll have to do a lot more runs to get anything statistically significant ;) 14:42
pmichaud as long as I have 3.0 runs that are faster than 3.3 runs.... I think I can say that 3.3 isn't a speed improvement over 3.0 :-)
PerlJam in anycase if your timeline is accurate it went 900 300 270 200 ... seems like a decreasing trend to me. Whatever was running during the 900s run was trailing off. 14:43
pmichaud if any(@parrot_3_0) < all(@parrot_3_3) { say "3.3 isn't faster"; }
I rebooted after the 300, yes 14:44
also, it's not quite that simple
because
whiteknight I don't think there is an expectation that 3.3 is faster than 3.0 --gc=gms
pmichaud 3.0 is gc=ms2 14:45
gms didn't exist in 3.0
whiteknight hmm, I'm muddling up my timelines
pmichaud I'm saying that 3.3 with gms isn't faster than 3.0 with ms2
PerlJam do any profiling tools exist for GC? Even something like counting the marks/sweeps/whatever
pmichaud at least, for spectests and for my limited testing of core.pm
PerlJam: there are some interpreter variables that can be queried 14:46
but those were broken for much of the past six months
whiteknight that's a weird result because we were seeing significant performance improvements in various Rakudo benchmarks when GMS landed.
pmichaud I don't remember when they got fixed
moritz had the feeling (but no data to prove it) that rakudo on parrot got slower since 3.1 or 3.2
whiteknight moritz: that's possible. more data would be very nice
pmichaud whiteknight: right, that's why I've been bringing it up
PerlJam moritz: oddly I had the same feeling (but again, no evidence)
pmichaud I ran some simple tests on the 2011.04 star release versus the 2011.01 star release because I wanted to say "Rakudo Star is now X% faster" 14:47
but I couldn't do that
because it wasn't. :()
whiteknight I could very well be underestimating the performance effects of some of the IMCC and packfile changes that have happened
that's probably the biggest changeset that has landed recently
moritz should start up his otherwise unused desktop computer when he's home, and automate some speed tests
pmichaud 3.3 retest: 289s 14:49
whiteknight okay, can we get a timing of 3.2?
pmichaud sure
it'll take a bit to build Parrot 14:50
whiteknight if that's as fast or faster than 3.0, we can start to expect the imcc/packfile changes of being the culprit
If the problems started before 3.2, we have a different set of things to look at
pmichaud here's what I propose to do (after I get a few house errands taken care of): 14:52
1. Run the core.pm test four times for each of 3.0, 3.2, and 3.3
2. Throw out the slowest time of each
3. Compare (a) the fastest time of each and (b) the average time of each 14:53
the other tests I've been running are t/spec/S05-mass/rx.t and t/spec/S32-trig/sin.t
is there a table or easy way to find out what the default gc is for each of the parrot versions? 14:54
moritz it's ms2 for 3.3 and older
pmichaud well, only back until ms2 was created, yes?
when did ms2 land?
moritz the switch to gms as only after the 3.3 release
pmichaud rakudo requests gms for 2011.03 (3.2) and 2011.04 (3.3), though 14:55
moritz yes
pmichaud so, 2011.01 is using ms2, 2011.02 is using m2, 2011.03 is using gms, 2011.04 is using gms... is that right? 14:56
(does that sound right?)
s/m2/ms2/
jnthn__ has a machine now building all <2011.02 2011.03 2011.04> 14:57
moritz pmichaud: I think that's right, yes
15:02 lucian left
pmichaud first run of 3.2: 262s 15:02
(faster than 3.3, slower than 3.0) 15:03
running again 15:04
15:14 dmalcolm joined
pmichaud 3.2 second run: 262s 15:16
15:17 ambs joined 15:20 UltraDM left
whiteknight okay, so 3.2 is about midway between 3.0 and 3.3? 15:22
what I really need to see is a graph 15:27
my powers of number-understanding are poor today
PerlJam Has the chief benchmark for GC performance been "time to compile rakudo"? 15:28
whiteknight I can't say that there is a single "chief benchmark" unfortunately 15:30
rakudo build and spectest run times are high on the list
PerlJam so, no one has built a test suite designed to stress the GC in various ways? 15:32
tcurtis ~~ 15:35
whiteknight PerlJam: nosir
There may be some things in the examples folder that have the side effect of describing GC performance, but no benchmark explicitly designed to stress it 15:36
pmichaud besides, I'm not necessarily pointing at the gc
I do know that a new gc was implemented, and several of us "observed" significant rakudo performance improvements as a result 15:37
plobsing we have examples/benchmarks/gc_*
whiteknight pmichaud: well, to narrow the GC out of contention, we could run 3.3 with --gc=ms2, same as what 3.0 used
PerlJam pmichaud: no, just the GC switch across the versions you were looking at made me think of it.
pmichaud but now when I try it in 2011.04, I'm not seeing any improvements -- in fact, it's arguably 40% worse than it was in January
15:37 hercynium joined
pmichaud whiteknight: I did that already (by accident) -- it was *way* worse 15:37
whiteknight okay, so that rules out GC algorithm 15:38
so we are seeing other slowdowns
including slowdowns before and after 3.2 it seems
pmichaud whiteknight: when I was building the 2011.04 star release, it didn't have the --gc option in its configure, thus Parrot got built with its default (ms2). And the spectest run took 55m instead of 30m
whiteknight ouch
gms for the win, then
tcurtis aloha, msg dukeleto the lalrskate idea didn't seem too great to me, but then I realized I could name a tool for outputting the parsing table "lalrcat".
aloha tcurtis: OK. I'll deliver the message.
pmichaud so gms is definitely better than ms2 for the spectest, at least for that one test I ran 15:39
but we're still heading in the wrong direction w.r.t. parrot speed, it seems :(
whiteknight I think we definitely need to review those imcc_compreg_pmc and packfile_wrap branch merges
pmichaud third run of 3.2: 262s 15:40
so it seems that 3.2 is consistently 262s :-)
whiteknight I don't want to undo those merges, but if we can narrow down to that being a part of the problem we can focus our optimization efforts
pmichaud (core.pm)
okay, I'll start my long string of test runs now
whiteknight that's I really appreciate it
15:40 contingencyplan joined
whiteknight pmichaud: if we can get a test before the imcc_compreg_pmc merge, that should be sufficient. packfile_wrap went in right before 3.3 15:41
so the difference between those two should give us the aggregate effect
pmichaud I'll start with the releases first
whiteknight okay
pmichaud that gives us a good, stable baseline that makes it very reproducible for everyone that wants to try
(also, it's what our collective users are seeing) 15:42
whiteknight timings I saw for imcc_compreg_pmc didn't look like they were any worse, I don't know that packfile_wrap was ever benchmarked
at least not aggressively
15:42 dmalcolm left
whiteknight IMCC man, let me tell you about IMCC. Every night I pray for god to light it on fire 15:42
and every morning, disappointment 15:43
plobsing whiteknight: (re: PI) yeah, runcore_optable_fixup() is just wrong. That was part a mechanical translation of code whose underlying assumptions were broken by dynop mapping. You'll need to figure out a different way to accomplish what that code does. 15:44
whiteknight plobsing: thanks for looking at it. I figured that was the problem, and I have no idea what to do differently. I still don't completely understand what PI does in all cases 15:45
plobsing: tracing through it is a bit of a nightmare sometimes
plobsing That code is supposed to maintain the probe hooks in sync with the op table of instrumented interp so the intruments know what an executed op is. 15:46
whiteknight how is it inserting those probe hooks, a copy of the optable? 15:47
plobsing It assumes the op table works the old way and only grows when we load new oplibs.
but it also messes with the instrumented interp for some reason 15:48
whiteknight: I think it is a runloop thing
whiteknight plobsing: I've already ripped out the instrumentgc pmc, because it was causing massive fail with the new GC system. I may have to pull out instrumentruncore too
plobsing whiteknight: what would that leave?
whiteknight That is, I'm trying to get to some kind of stable core of stuff that "works" 15:49
I want a baseline
and I have no idea what would be left
class hooks, I think. Although those tests look fail too
the bad news is that cotto and soh_cah_toa are going to need to re-evaluate some of the entries in his GSoC timeline 15:50
plobsing if there were one things PI should do, regardless of all others, it is intrument the runcore.
whiteknight because we were going on the assumption that PI was mostly workable and needed just a few tweaks to be fixed
but if it's making some hugely wrong underlying assumptions, that's a big problem
plobsing whiteknight: I don't think PI is suitable for the debugger project. It does different things. 15:51
dukeleto whiteknight: sounds like perhaps PI should not be used for the debugger project, as plobsing++ mentions
whiteknight inserting hooks and probes into the runcore wouldn't be helpful for the debugger?
dukeleto: at the moment, it can't be used because it doesn't work
if it were working, the introspection capabilities are quite interesting 15:52
plobsing whiteknight: yes, but the way PI does it is *way* more flexible than what a debugger needs
dukeleto whiteknight: yes, I gathered that. I don't want a student to be blocked by their dependencies not working.
if the new debugger is written in such a way that it could use PI down the line, when it works properly, that may be the best course of action here 15:53
whiteknight plobsing: so we shouldn't use a base library because the base library provides a superset of functionality?
plobsing from my perspective, it would be easier to just write a new, special-purpose instrumentation system than to resurect PI.
whiteknight plobsing: I am coming to that conclusion now too. Back when the project was proposed, I thought the effort to resurrect PI would be much lower 15:54
plobsing Please do not construe this as a commitment on my part to write such a system.
whiteknight clearly it's turning into a much larger project than is feasible
I think the better course of action is to have soh_cah_toa borrow code liberally where necessary, but to write his own system from the ground up
plobsing Again, I think, from the perspective of a debugger, the way PI does things is too general and not the most direct. 15:57
whiteknight that's fine. At this point it is up to cotto and soh_cah_toa about how to proceed
but clearly, PI is not a viable option right now
damnit. Not the result I was hoping for 15:58
15:59 theory joined
whiteknight brb food 16:00
jnthn__ pmichaud: I build the 2011.0[432] releases of Rakudo with their chosen Parrot versions. I then did three runs of core.pm compilation. (OK, I didn't...a script I wrote did :-)). Results: gist.github.com/953615 16:02
pmichaud interesting.
I have my script running now... we'll see what it reports
how about 2011.01? 16:03
dukeleto jnthn__: that looks quite nice
jnthn__ pmichaud: Updated the gist with the script, fwiw. 16:04
dalek nxed: r970 | NotFound++ | trunk/winxedst1.winxed:
fix bug in new qualified introduced in recent refactor, issue 24, plobsing++
jnthn__ pmichaud: running a 2011.01 now 16:05
pmichaud: This is in a powerful and lightly loaded 64-bit Linux box.
s/in/on/
moritz would love to get similar numbers :-) 16:06
jnthn__ I...don't use this box for that much :) 16:08
Maybe I should :) 16:09
dalek nxed: r971 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler
16:18 dod left
jnthn__ pmichaud: gist.github.com/953615 updated with 2011.01 times. 16:20
pmichaud: First time there's a way-out-there figure.
But other two are very close.
pmichaud my numbers will start to come in soon 16:31
jnthn__ pmichaud: btw, I'm two test fails off merging ctmo branch in nqp repo. After that, it's "just" installation issues. 16:35
pmichaud: Then I can dig into rakudo/nom :)
Expect to fix those fails today :) 16:36
whiteknight jnthn__++
Those numbers seem to be exactly the opposite of what pmichaud is reporting 16:37
if I'm reading it correctly
pmichaud yes, they are
whiteknight there's a chance that GMS might be badly behaved on systems with various limitations 16:38
that is, it's not really tuned, much less tuned for any particular platform
what we might need to do is start putting together a collection of valgrind reports 16:39
pmichaud I'm re-running my tests now. You can watch the updates (as I make them) at pmichaud.com/sandbox/rak-bench-1.txt
16:40 rohit_nsit08 left 16:42 davidfetter joined
dukeleto Smalltalk on Javascript: github.com/NicolasPetton/jtalk 16:45
what will those kids think of next?
moritz parrot on JS? 16:47
actually I've read about a protype C-to-javascript compiler that could run (modified) Doom in the browser 16:48
maybe we could port parrot to it
and then run on top of V8, to speed things up
SCNR
plobsing moritz: emscripten? 16:49
NotFound: the -I flag on winxed doesn't seem to be working any more 16:51
dalek rrot: dc5f4cf | mikehh++ | src/call/pcc.c:
add missing ASSERT_ARGS
 16:56
rrot: cccbf37 | mikehh++ | src/debug.c:
add missing ASSERT_ARGS
rrot: 8b0397b | mikehh++ | src/debug.c:
add missing documentation
rrot: e3ecaf8 | mikehh++ | src/gc/gc_ms.c:
add missing documentation
16:59 dodathome joined
plobsing msg kid51 can you try the latest tt1931-nci-parameters-deprecation on your machine? I suspect it may work. 16:59
aloha OK. I'll deliver the message.
17:00 mj41 left
cotto_work ~~ 17:11
17:11 whiteknight left 17:23 dmalcolm joined
cotto_work That's too bad about PI, but it definitely does about 500% of what a mere debugger would need. 17:25
well, did
17:26 whiteknight joined
cotto_work hio whiteknight 17:27
whiteknight hio
NotFound plobsing: I haven't used it recently. Are you using the installed version or the source tree?
cotto_work I saw that GSoC will be a bit more work for me and soh_cah_tao than it first looked like it'd be.
whiteknight cotto_work: maybe not. Readjust the schedule 17:31
you're starting at a lower point, so will end up at a lower point maybe
pmichaud bench mark results after two trials: pmichaud.com/sandbox/rak-bench-1.txt 17:34
whiteknight pmichaud: okay, so it looks like 3.3 is faster than 3.0 17:36
dalek nxed: r972 | NotFound++ | trunk/examples/Mysql.winxed:
update example Mysql
pmichaud no
3.3 is *slower* than 3.0
should I change the signs on the percents?
whiteknight oh, sorry. the percents surprised me 17:37
okay, so 3.1 was the slowest
pmichaud yes
whiteknight okay okay.
pmichaud looks like something happened between 3.0 and 3.1 to really slow things down
and then maybe gms is recovering some of that speed loss
should I use +26.0% to mean "26% slower?" instead of "-26.0%"? 17:38
cotto_work You could use % of 3.0, i.e. 126%
whiteknight it doesn't matter now that I know how to read it
okay, 3.1 was pretty big. Looking at news I see a few items that could potentially cause slowdowns 17:39
pmichaud what will be easiest for others? I plan to post this to the m/l
cotto_work Yeah. More important is that we figure out how to act on it.
whiteknight "Exception PMCs are now subclassable from PIR"
"Improved GC performance on low-memory systems"
"Improved GC latency"
those things all raise red flags for me
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#16100) fulltest) at 3_3_0-86-ge3ecaf8 17:40
Kubuntu 11.04 amd64 (g++)
PerlJam As long as you put a note that say "negative percentages are slower" it should be fine IMHO. 17:44
pmichaud I switched to cotto++'s suggestion
17:45 rurban_ joined
moritz currently has his desktop machine set up to measure rakudo compilation times for 4 releases, three times each 17:47
cotto_work moritz++
17:47 rurban left 17:48 rurban_ is now known as rurban
dalek rdinal: c2ad937 | (Kim, Daehyub)++ | Rakefile:
fix: coding miss in Rakefile:335
 17:50
rdinal: ef84b79 | (Kim, Daehyub)++ | / (3 files):
Integer#pred
rdinal: 3fa71e7 | dukeleto++ | / (3 files):
Merge pull request #5 from lateau/master.

fix and add
dukeleto wow, merge buttons really do make merging pull requests dead simple
wow, i think cardinal is alive 17:52
moritz fwiw moritz.faui2k3.org/tmp/time-rakudo.txt is the script that I use
pmichaud The scripts I'm using: pmichaud.com/rakbench 17:53
moritz: what part of your script switch rakudo/parrot versions? I'm not seeing it 17:56
moritz pmichaud: oh shit, I forgot that part :(
pmichaud: thanks for pointing it out :-)
pmichaud this is one reason I prefer to work from the tarballs 17:57
also we don't have to worry about getting the correct version of the spectests :-)
moritz I'll abort after the current run, and edit the output data to indicate the actual version it used
pmichaud: then you can still forget a chdir - it's really one commit each :-) 17:58
s/commit/command/
dukeleto is going to miss #ps today 17:59
coke_ fights with svn and wishes that git had a prayer of working out here.
cotto_work dukeleto: do we need to reconsider when we have #ps? 18:00
whiteknight has duke been missing it regularly? 18:01
dukeleto cotto_work: not on case of me. I need to see an accountant today to get my state taxes done, before the taxman starts stalking me. 18:02
coke_ lateau?
18:02 lateau left
coke_ ... wow. 18:02
dukeleto coke_: ?
coke_ just seeing if aloha knew him.
aloha, lateau?
aloha coke_: No clue. Sorry.
18:06 rohit_nsit08 joined
pmichaud Results after three trials (file location has changed): pmichaud.com/rakbench/results-20110503.txt 18:07
whiteknight pmichaud: I think that's plenty of data, thanks 18:09
pmichaud: no need to keep wasting cycles. The trend is clear
pmichaud I'm a little suspicious of that 254, though. 18:10
since the others both came out to 278 +/- 1
(however, earlier today when I was running the same test I was down at 200.... so, *something* is weird about the 2011.01 timings
besides, cycles are cheap, and I have plenty of machines :) 18:11
whiteknight pmichaud: okay :) I won't tell you how to spend your cycles 18:12
so there was clearly a major slowdown between 3.0 and 3.1, and another slowdown between 3.2 and 3.3 18:14
that's good. That narrows it down and shows us that we have two separate slowdowns to deal with 18:15
pmichaud oh! does the compiled parrot have any sort of random seed in it?
e.g., for hashing or the like?
I wonder if some of the differences I'm seeing in the 2011.01 test have to do with having compiled different parrot binaries in previous tests 18:17
i.e., perhaps some parrot binaries are faster than others...?
jnthn__ I thought the hash seed was picked at startup and stashed in the interpreter.
pmichaud I thought so too... but I'm really curious how I got those ~200s numbers earlier.
jnthn__ Yeah, me too :/ 18:18
pmichaud because I'm not seeing them now.
and they were pretty consistent then
I guess I should start looking at a new desktop too, since everyone seems to be getting much faster compiles than I am :) 18:23
whiteknight here's your sign 18:24
I need to get a new laptop myself eventually. It still has plenty of power but my son keeps throwing it onto the floor 18:28
the one hinge is broken again, and the monitor flickers and makes a buzzing noise
I picked it up off my lap yesterday, and found a screw. I don't know where it came from 18:29
I've started hiding the laptop under the couch so my son can't find it
18:30 ShaneC left
whiteknight it's only a matter of time 18:30
cotto_work pmichaud: Parrot does pick a random hash seed at startup. You can fix it by passing --hash-seed=1234 to the parrot executable 18:34
pmichaud cotto_work: yeah, I'm not sure that's it. 18:41
it feels more like it has to be something that's in the executable
either that or I just ended up with a string of lucky seeds
but also, only the 2011.01 build seems to show significant variation. All of the other builds only have a variation of ~2s 18:42
I have another script running now to test multiple runs of the 2011.01, both rebuilding and not rebuilding parrot in between
moritz (355 - 338) / 355 18:43
aloha 0.047887323943662
whiteknight pmichaud: maybe a test script to randomize the order you test things in? Maybe you're getting into a really weird cache situation at the beginning of the loop
moritz that's my max variations for 2011.01
whiteknight I'm just throwing out weird ideas
I would hope that a single run of the program with fixed parameters would be a little bit more deterministic than that 18:44
18:44 ShaneC joined
pmichaud whiteknight: yes, I'm wondering about determinism also 18:47
but repeatability is important too
anyway, we'll see what this latest script gives me 18:48
18:49 jevin left
whiteknight pmichaud++ 18:55
plobsing NotFound: I tried both 18:59
19:00 jevin joined, ShaneC left 19:08 mtk0 left, mtk0 joined
pmichaud pmichaud.com/rakbench/results-20110503.txt # updated with timings from sin.t test 19:08
jnthn__ pmichaud: #phasers is on at the moment, btw :) 19:10
19:12 bubaflub left
whiteknight I really need to attend the #phasers meeting more regularly 19:21
19:23 Coke__ left, Coke joined
cotto_work #ps in 60 19:28
19:31 Coke left, Coke joined 19:33 bubaflub joined 19:38 Coke left, Coke joined 19:46 rohit_nsit08 left, Coke left, Coke joined
cotto_work anyone feel like writing an M0 disassembler? 19:50
benabik Sounds fascinating, but I lack tuits. 19:51
KaeseEs .goog M0 spec
i thought there was a phenny instance itc :(
tadzik .g M0 spec
bah 19:52
19:53 Coke left
cotto_work in the m0-spec branch in docs/pdds/draft 19:53
19:53 Coke joined
cotto_work aloha: m0 spec? 19:54
aloha cotto_work: Search me, bub.
cotto_work aloha: M0 spec is docs/pdds/drafts/pdd32-m0.pod in the m0-spec branch
aloha cotto_work: Okay.
cotto_work aloha: m0 spec?
aloha cotto_work: m0 spec is docs/pdds/drafts/pdd32-m0.pod in the m0-spec branch
cotto_work #ps in 32 19:56
get those reports posted!
19:56 rohit_nsit08 joined
luben pmichaud, I know what causes MS2 GC performance variation in parrot 3.1 19:58
KaeseEs fires up vmware to get at pdd32-m0.pod
cotto_work KaeseEs: no need for that
KaeseEs: github.com/parrot/parrot/blob/m0-s...d32_m0.pod 19:59
luben It does not have dynamic (adaptive) triggering - it triggers every 10% of free memory that was allocated by parrot
on linux this means all memory - buffers - cache
so usually it is very little 20:00
when you rebooted, you actually freed buffers and cache
you chould achieve the same effect with "echo 2 > /proc/sys/vm/drop_caches" 20:01
in later parrots I have fixed that behaviour - the memory for GC is comuted as a fraction of all available memory 20:02
s/comuted/computed/ 20:04
whiteknight luben: Okay, that's along the lines of what I thought it was 20:05
but it's good to hear a real explanation 20:06
luben there was a bug in linux platform files
I think that I wrote mail to parrot-dev at that time 20:07
whiteknight the variances are interesting but they're in the past now. What is most concerning is the big slowdown between 3.0 and 3.1, and the smaller slowdown between 3.2 and 3.3
that's something that we need to profile and understand aggressively
20:09 mj41 joined
luben execution time is not the only parameter of GC - peak memory usage is also very important parameter 20:09
we have mostly the same exec time but we manage with 1/3 of the memory
pmichaud luben: I'm not seeing variation in 3.1. I'm seeing variation in 3.0. 20:10
3.1 is very self-consistent.
KaeseEs the textual representation of M0 looks comfortingly similar to MIPS r-type instructions
luben (comparing MS2-without dynamic triggering and GMS)
pmichaud, my fault - I was thinking about 3.0
pmichaud regardless, 3.0 is still consistently faster than 3.3. 20:11
cotto_work aloha: going to yapc::na?
aloha cotto_work: Dunno.
cotto_work aloha: going to yapc::na is cotto
aloha cotto_work: Okay.
cotto_work aloha: going to yapc::na is also dukeleto
aloha cotto_work: Okay.
pmichaud where's the "not going" list?
cotto_work sad face 20:12
luben pmichaud, but 3.0 wastes a lot more memory than 3.3
pmichaud luben: right now speed is far more important to us. 20:13
(maybe not for parrot, though)
cotto_work KaeseEs: are you interested in being recruited for an M0 disassembler?
luben pmichaud, I am working to make this runtime option 20:14
also looking for better defaults
KaeseEs i don't know much about CPS except that a friend of mine who uses racket talks about it sometimes :(
20:15 dodathome left
pmichaud runtime option doesn't seem all that useful -- most people will be using the defaults 20:15
KaeseEs i don't have class on friday, i'll take a look then if someone else hasn't run with it yet
cotto_work KaeseEs: you won't need to care much about CPS for the disassembler.
It's most relevant to the interp, and once dukeleto and I understand it fully, we'll document it quite thoroughly.
atrodo aloha: going to yapc::na is also atrodo 20:16
aloha atrodo: Okay.
KaeseEs ok. i'll take a look at it. forgive my wariness for telling people i've got tuits when finals are on the 16th :/
pmichaud aloha: not going to yapc::na is also pmichaud 20:17
aloha pmichaud: Okay.
pmichaud aloha: not going to yapc::na
aloha: not going to yapc::na?
aloha pmichaud: not going to yapc::na is pmichaud
cotto_work KaeseEs: no worries. It won't block anything. It'd be nice to have as a way to ensure that we can losslessly round-trip between the assembler and disassembler, but that's it.
benabik is probably going to yapc::na, but hasn't made any arrangements yet.
KaeseEs cotto_work: makes sense 20:18
cotto_work aloha: going to yapc::na is also atrodo 20:21
aloha cotto_work: Okay.
atrodo aloha: going to yapc::na?
aloha atrodo: going to yapc::na is cotto or dukeleto or atrodo or atrodo
atrodo quite happy to put me in there twice. I'm REALLY going
moritz when did parrot switch to git?
cotto_work atrodo: I expect both you and your clone. 20:22
bubaflub moritz: a while back. dukeleto handled the conversion
20:22 _dolmen_ joined
moritz bubaflub: sorry, I should have asked "what's the parrot parrot release made with git?" 20:22
benabik The last git-svn-id I see is e0da8738, on 10/5/10
tcurtis moritz: November of last year.
moritz s/parrot/first/ 20:23
thanks
tcurtis moritz: Which is 2.10, I think.
mikehh think it was the one tcurtis++ did, let me check
atrodo cotto_work> what if i bring atrodo 2.0, will that count?
cotto_work atrodo: sure.
atrodo cotto_work> Perfect! Screaming boy in the sessions! No one will hate me at all! 20:24
20:24 rohitnsit08 joined, rohitnsit joined
cotto_work atrodo: how's his code? 20:24
moritz tahsnk benabik and tcurtis
atrodo cotto_work> still trying to get him to not eat the keyboard. so decent 20:25
moritz can't type today
20:25 rohitnsit08 left, rohit_nsit08 left
mikehh moritz: definately 2.10 was the firest using git 20:26
20:26 rohitnsit left, rohit_nsit08 joined
rohit_nsit08 hello #parrot 20:27
cotto_work #ps at now 20:28
moritz I'll try to extend my graph (see parrot-dev) to 2010.{11,12}
but it'll take some time
davidfetter #parrotsketch ?
20:28 whiteknight left
davidfetter contemplates irc channel aliases 20:29
mikehh davidfetter: for sure
atrodo pmichaud> If you have anything you want to see from isparrotfastyet.com or have any suggestions, I'd love to know 20:33
pmichaud atrodo: I don't yet understand that site 20:37
afk, errands
atrodo pmichaud> That's good to know. Thanks 20:38
bubaflub atrodo: how much data do you have in the past? it might help us determine some of the slow-downs 20:39
atrodo bubaflub> I should have all the releases for 2010, plus everything after 2010-12-3 20:44
bubaflub> although, i thought i had more then that
bubaflub atrodo: great - that should be useful in figuring out exactly when the slowdown from 3.0 to 3.3 occured
moritz to me it looks like the bulk of the slowdown was between 3.0 and 3.1 20:45
moritz.faui2k3.org/tmp/rakudo-perl-...-05-03.png
see my last parrot-dev mail of more details
but don't trust my data yet - I'll have more reliable data tomorrow
Util aloha: going to yapc::na is also Util 20:46
aloha Util: Okay.
dalek p/ctmo: 932f6da | jonathan++ | src/ (2 files):
Make sure derived dispatchers are fixed up. Fixes the last two test regressions in the ctmo branch after the full switch to using compile time meta-objects.
 20:54
plobsing NotFound: never mind. the -I switch appears to be working for me now. not sure what I was doing wrong 20:57
NotFound plobsing: k
dalek p/ctmo: 61e5ea0 | jonathan++ | src/stage0/ (6 files):
Update bootstrap.
 20:58
21:05 M_o_C joined 21:08 darbelo joined
dalek Heuristic branch merge: pushed 20 commits to nqp by jnthn 21:08
21:09 darbelo left 21:10 darbelo joined 21:11 ambs left 21:27 mj41 left
luben atrodo, it will be great to have option to switch scales, eg week, month, year for isparrotfastyet.com/ 21:36
21:37 darbelo_ joined 21:38 M_o_C left
NotFound (moved from #ps) Testing with ohm-eta should be easy, and more realistic than an artificial test. 21:39
benabik Some artificial benchmarks might be useful in pegging performance changes in particular sections of parrot. Real programs are good for pointing out when problems occur, but its sometimes difficult to figure out what underlying change caused it. 21:41
plobsing The lightest test would be to run the precompiled tests. Medium would be to compile those tests. Heavy would be the bootstrap stage.
What time-range do we want our benchmarks to run in?
21:42 darbelo left
NotFound For a start, we should find a test that mimics the pattern observed with rakudo. 21:42
mikehh in one sense yes, but I think we need general benchmarks as well 21:43
NotFound If ohm-eta does it, we can bisect it.
plobsing so the pattern we're looking for was with all the released versions from 3.0 through 3.3? 21:44
mikehh and see if we catch a hiccup somewherte between 3.0 and 2.1 21:45
NotFound mikehh: yes, but isolating first the known problem may be the better way.
mikehh 3.1
NotFound: sure, but I was also thinking long term as well (for later) 21:46
21:47 fperrad left
NotFound I'm definitely open to any plan involving more winxed usage ;) 21:47
mikehh NotFound: I agree, I think you have something positive there (in winxed that is) 21:49
plobsing I'm going to have to build all the release versions of parrot. It'll be a little while before I can give any results 21:50
mikehh also might need to track branch merges between 3.0 and 3.1 21:53
dalek p: 8bffb73 | jonathan++ | / (11 files):
Some PBC renaming so we can install without trampling on things already in Parrot's library directory.
 21:54
p: 53e7266 | jonathan++ | src/stage0/ (6 files):
Update bootstrap after renaming.
22:32 bubaflub left 22:33 bluescreen left
cotto_work NotFound: ping 22:36
aloha: clock?
aloha cotto_work: LAX: Tue, 15:36 PDT / CHI: Tue, 17:36 CDT / NYC: Tue, 18:36 EDT / UTC: Tue, 22:36 UTC / LON: Tue, 23:36 BST / BER: Wed, 00:36 CEST / TOK: Wed, 07:36 JST / SYD: Wed, 08:36 EST
NotFound cotto_work: pong
cotto_work NotFound: what (if any) support for regexes does winxed have?
NotFound cotto_work: there is no direct support. 22:40
cotto_work NotFound: ok
NotFound BTW, I don't know what the plans are. If tge gets deprecated and killed, Is there any way to use regexes other than nqp? 22:41
cotto_work tge has been on life support since I joined the project, but it's been very stable throughout that time. 22:42
We most likely won't kill it while Lua still uses it. 22:43
22:44 Andy left, hercynium left
Tene cotto_work: you could always dlopen libpcre 22:44
cotto_work Tene: sure. That's an option.
22:46 kid51 joined 22:47 whiteknight joined
kid51 aloha: going to yapc::na is also kid51 22:51
aloha kid51: Okay.
whiteknight Is anybody looking at the performance issues right now? 22:56
NotFound whiteknight: plobsing said he's going to install the relevant parrot versions and test them with ohm-eta. 22:58
whiteknight NotFound: that's perfect
the first thing we really need to do is isolate the problem to Parrot and not Rakudo
plus, it can't hurt to have a benchmark that doesn't take quite so long to run 22:59
cotto_work whiteknight: plobsing wanted to talk about concurrency. I said he should catch you. 23:00
whiteknight okay, awesome 23:01
I always like talking to plobsing
cotto_work If the boths of yous are here, now'd be a great time.
whiteknight ENOPLOBSING 23:05
cotto_work well nuts 23:06
whiteknight I'm still up for talking. Let's talk. 23:11
how about that local sports team?
I hear they are doing differently from what was expected of them 23:12
cotto_work I hear they've got a chance for that big event.
whiteknight: how much time do you spend blogging per day? 23:13
whiteknight cotto_work: depends. Most days I don't do it at all
I have a very large pile of half-finished drafts. When it's time to post, I put some polish on them
I used to keep a daily blog/journal for personal stuff. I gave that up, but still have the urge to write pretty frequently 23:16
23:16 darbelo_ left
whiteknight I gave up poetry because I suck at it, so all I've got left is my technical blog 23:16
23:17 darbelo joined
whiteknight I had a series of professors in college who were very persuasive about the need to write frequently 23:17
cotto_work I guess it worked. 23:18
good for them\\ 23:19
whiteknight Inspiration comes in waves though. Some days I have a lot to talk about and I write up several drafts at once. Other days I have nothing to say, so I sit around like lump 23:20
cotto_work on an unrelated note, are you planning on yapc::na? 23:21
whiteknight unfortunately, not this year. We're trying to buy a house, and I'm saving my vacation time for that
next year is a distinct possibility
cotto_work aloha: not going to yapc::na is also whiteknight 23:22
aloha cotto_work: Okay.
cotto_work That's too bad, but that's also exciting for you.
whiteknight It is too bad, really. I really liked YAPC when I went 23:23
cotto_work and I like hanging out 23:24
whiteknight yeah, it was fun to meet you and the rest of the team
extremely high bandwidth
cotto_work btw, Randall Schwartz was at the Parrot talk. It was a trip to have him in the audience.
whiteknight oh really? that's awesome
so there wasn't a video of it or anything? 23:25
transcript? powerpoint slides?
cotto_work no video, though I'll post my slides
whiteknight second hand account from a guy who knew a guy who was there?
cotto_work mksig.org/slides/lfnw2011/
whiteknight I'm jonesing for more cotto
23:25 kid51 is now known as kid51_at_dinner
whiteknight cotto++ 23:26
nice presentation 23:28
nopaste "plobsing" at 192.168.1.3 pasted "â¦Î·-bench" (5 lines) at nopaste.snit.ch/43358 23:29
whiteknight <parrot git:master> ./parrot examples/benchmarks/stress3.pasm
A total of 76269849 GC runs were made
plobsing oh hai. i haz can haz benchmark
cotto_work plobsing: awesome. We have a small test case!
whiteknight I suspect that number is a lie
plobsing++ 23:30
23:30 darbelo left
cotto_work plobsing++ 23:30
whiteknight it's good to isolate the problem from Rakudo
plobsing cotto_work: only if the pattern is the same. there is a large jump between 3.0 and 3.1, but the rest isn't correlated so well
whiteknight and it's good to have a test case that runs in less than 5 minutes
its correlated well enough. the only way to perfectly match the Rakudo usage pattern is to use Rakudo 23:31
cotto_work It looks good for the first slowdown.
plobsing Ωη is close though. the parsing algo is very similar, and it makes use of exceptions
cotto_work yup 23:32
whiteknight okay. Let's get valgrind up in this biznatch. I guess I need to get ohm-eta to run the benchmark?
cotto_work hopes to see some concurrency talk now that plobsing and whiteknight are both online 23:33
plobsing yep. and you'll need winxed to build it (but not to run)
whiteknight plobsing: yeah, what's on your mind for concurrency? 23:34
plobsing whiteknight: I've been reading your concurrency blog posts.
what you describe is very similar to the architecture we have now (other than the whole not working thing), SFAICT. 23:35
whiteknight plobsing: we don't really have any mechanism for tasks/greenlets
plobsing we have a scheduler with tasks 23:36
whiteknight and we don't have any data sharing mechanism whatsoever
and our threads are extremely heavy weight, and require cloning the interp
plobsing we have a message passing architecture
whiteknight do we?
plobsing Parrot_cx_send_message() 23:37
whiteknight does that work? Is it used? I mean, I know we have SchedulerMEssage PMC or whatever it's called
and in either case, whether what we have is a vague shadow of what I suggested or not, the work to fix it is probably less than the effort just rewrite it correctly 23:38
plobsing I think working to bring the current framework up to the task has its advantages. 23:40
It makes considerations for things you haven't mentioned (so I assume you haven't thought about yet) 23:41
such as OS signals, asynchronous NCI callbacks, etc
whiteknight I glossed over those things, but I have thought about those plenty
I talked with lucian about those the other day
There are a lot of implementation details that I glossed over 23:44
plobsing but I'm more concerned about the timeline. sure 4.0 or later is acceptable for user-exposed threads, but we can get a lot of mileage out of internals which have a coherent thread-safety strategy 23:45
even if we're not exposing that to HLLs
whiteknight do you think our current system represents a "coherent thread-safety strategy"?
I've never seen any bit of it that inspired any kind of confidence 23:46
now, if you're up for rewrting the system, and rearranging the timeline, that's fine. The timeline was all hypothetical
like I said, those posts were more an attempt to get the conversation started than a final plan in itself 23:47
plobsing No. The current system far from coherent.
whiteknight okay
plobsing There are parts that pay attention to threading, and others that pay no mind
whiteknight the big problem right now is that the current threading system has been in disrepair for so long that the rest of Parrot has moved on without it 23:48
plobsing we have mutexes in some places, but the allocator, by far the most used susbsystem, is totally exposed
whiteknight I ripped out the old STM implementations with my bare hands, and nothing broke 23:49
no tests failed. No code outside the stm files needed to be changed at all
plobsing I'm not talking about user-exposed threads. I'm talking about things like embedding in a threaded webserver like apache.
whiteknight right
okay, so what do you propose? We start with an OS-threading implementation first, and build tasklets on top of that later? 23:50
I'm assuming that part of the OS-threading implementation is pervasive thread safety
plobsing we need the pervasive thread safety before anything, so I think that's where we should start 23:53
whiteknight well, my thinking is that we don't know the system is pervasively thread safe without starting to implement and use threads 23:54
that is, make threads, make a suite of tests for threads, fix all test failures, etc
plobsing we know the other parts and how they fit together currently. we can find a lot of structural problems without even testing. 23:57
whiteknight this is true. No argument there. we can definitely fix some glaring errors 23:58
for something like the PMC allocator however, we need a long-term plan for the GC before we attempt that
for instance, do we have per-thread GC? Or do we have a separate GC thred?
or a single stop-the-world global GC?
plobsing yes, that's the kind of decisions we need to be making
whiteknight each of them are going to have different strategies for making a thread-safe allocator 23:59
I purposefully glossed over GC in my posts, but I'm a big fan of a concurrent algorithm for GC
if the system supports enough threads, devote one to GC
plobsing and all of that has nothing to do with what flavour of threads HLLs deal with

Powered by Cro and the Raku® Programming Language.

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

Thank you!