github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
04:12 Kaiepi left, Kaiepi joined 07:49 domidumont joined 08:04 frost-lab joined 09:11 Kaiepi left 09:13 Kaiepi joined 10:03 Kaiepi left 10:04 brrt joined, Kaiepi joined
jnthn In a curious bit of timing, I too wrote my first blog post in a while... :-) 6guts.wordpress.com/2021/03/15/tow...in-moarvm/ 10:27
brrt: Intersting post :) 10:52
*interesting, even 10:53
I'm not really sure it's fair to say that database queries aren't relevant to the working programmer, although on the other hand we do seem to expend a lot of effort on stuff like ORMs in order to avoid them :) 10:55
brrt jnthn: thanks; it is curious
yeah, it's a bit of a mix, I'm thinking especially of the very complex SQL report query/scripts
most programmers are kind of isolated of these and know rather little of SQL 10:56
I will read your blog post, too
also, database queries are exactly the kind of thing where a programmer would quibble about whether it's a program or not :-P 10:57
MasterDuke brrt: i've thought of scripts/programming in a similar way. the absolute good of a strict/strong type system and it's blindingly obvious benefits that are often espoused i haven't experienced much. but that's probably because most of my programming hasn't been developing large systems 11:00
brrt absolutes tend to be context-free 11:01
jnthn brrt: I don't really have a quibble there; I've seen both spreadsheets and SQL queries whose complexity is quite incredible
Certainly one can solve sufficiently complex things in those tools that I don't think one should look down on them as "not real programming", but I agree that this happens. 11:02
brrt yeah, me too, spreadsheets in particular
I think part of the point that I was getting at, was that it's not a question of 'real' versus 'non-real' programming, but perspective and objectives; 11:03
lizmat I once converted a program written in Clipper, which was a compiled version of Dbase 3 if I remember correctlu
for a given input, it would run ~ 15 minutes, basically because it use the database as a variable store
*used
brrt if you're building an application on which a business of $large-monetary-value depends, it should be expected to look different from a script with low and possibly transient value 11:04
lizmat rewrote that in an actual programming language, did everything in memory, ran in .2 seconds for the same input :-)
brrt heh
I wrote an geographic analysis program for OSM data (power lines) and it ran entirely within postgresql/postgis
no doubt it would've been a lot faster in a 'real' language 11:05
though I also ended up writing an analysis in python and that was pretty slow (until I optimized the central algorithm)
11:22 MasterDuke left 11:29 brrt left 11:35 MasterDuke joined
nine brrt: I disagree a little bit about phones not being a scriptable enivronment. Incidentally I've recently made my first contribution to (a simulated) Airbus A320: github.com/legoboyvdlp/A320-family/issues/221 A bit of HTML and Javascript lets me use the aircraft's MCDU (the computer terminal) on my phone as part of my growing cockpit. 11:46
tellable6 nine, I'll pass your message to brrt
nine In essence, web technology brings scripting to environments where it wasn't available before. 11:47
11:52 frost-lab left
MasterDuke nine: don't know if you've seen github.com/rakudo/rakudo/issues/42...-799318279 ? 11:57
nine I have
reply is half written
alas, next meeting is on
MasterDuke cool
12:06 MasterDuke left 12:07 MasterDuke joined 12:12 brrt joined
leont brrt: I like your article, and it has some overlap with one I'm currently writing 12:38
12:47 brrt left 12:53 MasterDuke left 12:55 MasterDuke joined 13:03 brrt joined
brrt leont: thanks, share it when it's done 13:09
tellable6 hey brrt, you have a message: gist.github.com/452a18615635064def...099f0a7167
brrt nine: heh, that's actually true, and I knew that; android phones are also surprisingly hackable, if you know the tricks 13:14
then again, the whole 'there's an app for that' thing is very anti-scripting, and I guess that was what I was going for 13:15
MasterDuke hm. a simple count words one-liner (inspired by benhoyt.com/writings/count-words/) is ~10x slower in raku than perl or python. i was expecting it to be a little better 13:21
13:32 cog left
leont But is it better for the programmer? 13:35
(and what does it look like?)
13:37 cog joined
MasterDuke raku - `my BagHash $w .= new; $w.add($_.lc.words) for "kjvbible_x10.txt".IO.lines; say .key, .value for %w.pairs.sort(-*.value);` 13:40
13:42 brrt left
MasterDuke perl -nE 'BEGIN { my %h }; $h{$_}++ for split " ", lc $_; END { say $_, $h{$_} for sort { $c{$b} <=> $c{$a} } keys %h}' kjvbible_x10.txt 13:43
jnthn Can't it be something like like `my %w := bag "kjvbible_x10.txt".IO.words`?
MasterDuke python -
counts = collections.Counter()
for line in sys.stdin:
    words = line.lower().split()
    counts.update(words)
for word, count in counts.most_common():
    print(word, count)
jnthn well, with .map(*.lc) 13:44
MasterDuke .words is a bunch slower than .lines then .words
jnthn Odd
lizmat MasterDukeL: and .slurp.words ? 13:45
MasterDuke: and .slurp.words ?
MasterDuke well, the article says doing it line by line
jnthn ah, ok, fair enough
MasterDuke i assume .words would still count (minus the .slurp) 13:47
jnthn: fwiw, yours is 90x slower 13:48
jnthn Yowser 13:49
So much for building immutable things being faster
MasterDuke i.e., ~90s instead of ~1s 13:50
`my %w := bag "kjvbible_x10.txt".IO.lines>>.lc.words; say .key, .value for %w.pairs.sort(-*.value);` is only 30x slower
lizmat Bags are inherently slower because they need to do a .WHICH on the strings 13:52
MasterDuke part of the problem with the bag approach is that it's a quanthash and uses the .WHICH
lizmat right
MasterDuke a plain hash in raku is only 7x slower 13:53
lizmat since strings are the keys here already, it's adding a lot of overhead, so the old Perl idiom of %h{$word}++ would be fastest I think
MasterDuke oh, maybe it's still about 10x 13:54
`my %w; for "kjvbible_x10.txt".IO.lines -> $l { %w{$_}++ for $l.lc.words }; say .key, .value for %w.pairs.sort(-*.value);`
lizmat I wonder if a Hash::str version of Hash::int would make things a lot faster again: modules.raku.org/dist/Hash::int:cp...sh/int.pm6 13:55
13:58 cog left 14:01 codesections joined 14:10 brrt joined
leont BTW, for this sort of problem we're competing with shell, not C 14:23
MasterDuke heh, the BagHash version has 997,486 deopts, another test case for my PR 14:24
heh, just iterating over the lines of the file takes 0.7s in raku, but only 0.07s in perl 14:39
`raku -ne 'BEGIN my $a; ++$a; END say $a' <kjvbible_x10.txt` vs `perl -nE 'BEGIN { my $a }; ++$a; END { say $a }' <kjvbible_x10.txt` 14:40
i know raku is doing unicode handing here and perl isn't by default, but istr jnth writing a blog post a while ago about making this sort of thing much closer to perl's speed 14:41
lizmat make sure you read the file with :enc<ascii> ?
MasterDuke drops it to 0.4s 14:44
leont is intimately familiar with perl's readline implementation. You don't want to know how that sausage is made :-p 14:46
MasterDuke is happy that leont just volunteered to optimize raku's readline implementation... 14:47
jnthn MasterDuke: I assume you're subtracting Raku's startup time, and it's not that which is dominating? 14:48
leont The part that caries most of the weight has 6 or 7 goto's to 4 different labels in about 150 lines of code; I'm not sure this is something you want to copy.
MasterDuke yeah, i suspect the overall design is quite a bit different 14:50
jnthn: no, but for me raku's startup time is only 0.075s 14:51
jnthn: btw, have your new machine set up? 14:55
15:00 Kaiepi left
jnthn MasterDuke: Yes! :) 15:27
MasterDuke: And it's sooo much faster than what I was using at home before :) 15:28
MasterDuke nice 15:29
and btw, good article
just mentioned over in #raku, but switching to my remove_spesh_optimization_if_it_has_too_many_deopts branch in moarvm drops the BagHash version from 11s to 9.5s 15:37
15:38 cog joined
MasterDuke and almost all the deopts are gone 15:39
jnthn Oh, very nice! 15:41
Is that branch ready for review, or still some bits to go? 15:42
MasterDuke essentially ready for review
lizmat is there a PR ? 15:43
MasterDuke i'm not sure about the final commit (which is needed to get the example you gave my to actually remove and create a new opt) 15:44
lizmat asking for the weekly :-)
MasterDuke i think you've mentioned it before, it's been open for a while
github.com/MoarVM/MoarVM/pull/1426
lizmat still marked as draft ?
jnthn Will try and find some moments for it this week 15:45
releasable6: status
releasable6 jnthn, Next release in ≈5 days and ≈3 hours. 3 blockers. 0 out of 62 commits logged (⚠ 35 warnings)
jnthn, Details: gist.github.com/d1fa3cd361597dab32...c91d040226
jnthn Maybe after that :)
MasterDuke there may be some minor cleanup of the intermediate commits i could/should do, but i think the final diff is in a reviewable state 15:46
jnthn: also, at some point (probably not right now) i'd like to pick your brain about github.com/Raku/nqp/pull/703 and trying to make it work for any `if @foo` 15:48
jnthn (To be clear, I can review it ahead of the release, just think it should get merged after it)
Yes, I'm meant to be working on something else at the moment :) 15:49
MasterDuke and i have a distraction crawling amongst my feet
15:53 Kaiepi joined
lizmat hopes it is a wanted / needed distraction 15:56
MasterDuke in general yes, her grabbing random cords and yanking on them/putting them in her mouth less so 15:59
lizmat aah... :-) 16:04
[Coke] started reading jnthn's article before work today and ran out of time it was so full. 16:20
17:10 tbrowder__ joined 17:14 tbrowder left, tbrowder__ is now known as tbrowder 17:17 brrt left 17:31 notagoodidea joined 18:08 notagoodidea left 18:32 domidumont left 19:10 avarab joined, avarab left, avarab joined 19:11 notable6 left, quotable6 left, avar left, quotable6 joined, notable6 joined, bisectable6 left
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/03/15/2021-...year-itch/ 19:15
19:28 domidumont joined 19:32 domidumont left 20:10 bisectable6 joined 20:19 bisectable6 left, bisectable6 joined 20:24 Kaiepi left
japhb jnthn++ # Really excellent detailed post. 20:32
20:56 bisectable6 left, notable6 left, quotable6 left, statisfiable6 left, greppable6 left, bloatable6 left, benchable6 left, tellable6 left, harrow left 20:57 bisectable6 joined, notable6 joined, quotable6 joined, statisfiable6 joined, greppable6 joined, bloatable6 joined, benchable6 joined, tellable6 joined, harrow joined
MasterDuke nine: just for fun i tried out your more_asan_fixes branches, rebased them to master, and ran a spectest. the tests get slower and slower, and perf top says MVM_thread_join_background takes an increasing percentage (80% now and the spectest is almost finished, but seems to have hung) 21:38
t/spec/S29-os/system.t consistently fails the `:merge with run on non-existent program does not crash [attempt 0-9]` tests 21:40
21:48 zakharyas joined 21:51 zakharyas left 21:52 japhb left
MasterDuke nine: btw, made any progress on figuring out that misspesh business? 21:53
21:54 japhb joined 22:08 sena_kun left 23:13 dogbert11 joined 23:16 dogbert2 left

Powered by Cro and the Raku® Programming Language.

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

Thank you!