Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-02-13

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:08 * TimToady would like to point out that nowhere in the design docs equates 'int' with C's 'long' type
00:09 vendethiel joined #moarvm
00:13 TimToady according to S02:772 'int' might well be 'long long' on some machines
00:13 synopsebot Link: http://design.perl6.org/S02.html#line_772
01:58 vendethiel joined #moarvm
02:47 vendethiel joined #moarvm
02:49 ilbot3 joined #moarvm
02:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:24 vendethiel joined #moarvm
03:51 vendethiel joined #moarvm
04:29 vendethiel joined #moarvm
05:16 vendethiel joined #moarvm
06:08 vendethiel joined #moarvm
06:13 sivoais joined #moarvm
06:42 FROGGS[mobile] joined #moarvm
06:43 FROGGS[mobile] even more a reason that NativeCall should export types that are called long etc
06:48 vendethiel joined #moarvm
07:15 rurban joined #moarvm
07:30 vendethiel joined #moarvm
07:41 brrt joined #moarvm
07:47 FROGGS joined #moarvm
07:49 brrt as far as i can tell, libuv's sendfile - which is what we use for the nqp::copy op, can accept arguments larger than 2g very well, it just doesn't send more than 2g in one go
07:53 FROGGS that's what I guessed also, that the 2G are just the first chunk
07:54 brrt so all that's needed is to write a loop around 2g chunks
07:56 FROGGS their documentation is worse than ours
07:58 brrt yeah
07:58 brrt i'd say that was harsh, but, it's true
07:59 FROGGS heh, they want(ed?) to drop sendfile :o) - https://github.com/joyent/node/issues/3854
07:59 brrt what
08:00 brrt ...
08:00 brrt we can perfectly well write MVM_sendfile
08:00 brrt but it'd be missing the point of using libuv i guess
08:00 FROGGS aye
08:00 nwc10 is their only API to file metadata using stat buffers?
08:01 FROGGS I think so
08:01 nwc10 then :-( if you're windows
08:01 nwc10 in that, if you're faking up stat propery on windows, you have to put effort into faking device and inode
08:02 nwc10 which then immediately gets thrown away if all someone wanted to know is "is this a directory?" or "how long is the file?"
08:03 brrt that...
08:03 brrt is very true
08:04 brrt dunno if they're accepting of patches
08:05 nwc10 (1) I wouldn't know what would make a better subset of APIs
08:05 FROGGS why shouldn't they accept patches?
08:05 nwc10 (2) I'm not using Windows (and have never ever ever developed for it)
08:05 brrt they probably are
08:06 brrt nwc10 - general lack of knowledge of windows api's is a weak spot of the OSS community
08:06 brrt myself included
08:12 xiaomiao wouldn't call it a weak spot
08:13 brrt it is if you need your code to run everywhere
08:13 xiaomiao my code runs on all relevant platforms
08:13 xiaomiao I don't see how windows gets involved there
08:13 xiaomiao :)
08:14 brrt well, thats because you're choosing what you find relevant and what not
08:14 xiaomiao I played with the Win8 demo
08:14 xiaomiao it's kinda ... interesting ... demo
08:14 xiaomiao but it's so rough that I wouldn't want to do QA for it
08:15 brrt win8 or win10?
08:15 xiaomiao 8
08:15 xiaomiao plus the 8.1 'update'
08:15 xiaomiao so very beta ...
08:15 xiaomiao like, the shutdown button / dropdown menu is broken, and wrong
08:16 xiaomiao how does that even happen.
08:18 brrt i found 8.1 quite acceptable actually
08:18 brrt you can ignore the whole metro thingy
08:18 brrt also, it natively runs word/excel, which is a benefit
08:18 xiaomiao too slow
08:18 xiaomiao and too buggy
08:19 xiaomiao but, kinda ... nice showroom demo
08:19 xiaomiao "shutdown" hibernates ... that kind of buggy
08:19 xiaomiao and the incoherent mess of icons, text, icons+text ... any localized version is total mindbender and horrible to figure out
08:30 brrt i ran it in a virtualbox
08:30 brrt the best way to run anything imho
08:31 brrt anyway, that's really offtopic; moarvm supports windows whether you or i like it or not
08:31 brrt :-)
08:31 brrt and we're also likely to keep using libuv for the forseeable future
08:32 FROGGS ohh ye
08:32 FROGGS s
08:39 vendethiel joined #moarvm
08:45 Ven joined #moarvm
08:48 brrt ok, it's a known issue
09:09 zakharyas joined #moarvm
09:15 jnthn Well, given we're using sendfile to implement copy, if we need a Windows-specific solution there we just use CopyFile to do the whole thing :)
09:25 Ven joined #moarvm
09:29 brrt this is true
09:30 brrt frankly, that's actually a pretty good idea
09:32 brrt we do lots of stuff windows-specific
09:33 nwc10 "we run on both kinds of OS, Linux *and* Windows"?
09:33 nwc10 (well, maybe "POSIX and Windows")
09:33 brrt mac, linux, and windows
09:33 nwc10 then again, what does libuv run on?
09:33 brrt well... i guess those
09:33 brrt perhaps also bsd
09:33 nwc10 Mac is a FreeBSD fork atop a mach microkernel (and then diverged) so it's pretty POSIX
09:33 brrt but pretty lame POSIX imho
09:34 brrt almost-but-not-quite good implementations of many things, and good-but-different implementations of many others
09:35 nwc10 I've not actually hit enough of these to know where the pain is
09:35 jnthn nwc10: And...what's the marketshare of non-POSIX, non-Windows OS users that are likely to want to run Perl 6? :)
09:35 nwc10 but I'm still annoyed that they thought that dtruss was an adequate replacement for ktrace
09:36 nwc10 jnthn: well, possibly someone will say that they want to run it on iOS and on Android
09:36 brrt which are...
09:36 brrt :-P
09:36 nwc10 Android libc is an utter joke
09:36 brrt fair enough
09:36 brrt but that's not my problem
09:36 brrt as in
09:36 nwc10 (mind you, it didn't need to be anything other than that, because it's not the default runtime)
09:36 jnthn So, crapply implemented POSIX? :)
09:36 nwc10 worse
09:36 brrt libc is very much beyond the scope of moarvm
09:37 nwc10 I'm pretty sure it's not C89 conformant
09:37 nwc10 (at least) the local functions exist as stubs which print to stderr that they aren't impleneted
09:37 nwc10 what use is that?
09:37 jnthn wtf!
09:37 nwc10 if they didn't exist, probing code would detect this easily
09:37 nwc10 yes, there's some other wtf
09:38 nwc10 like the dynamic linker (certianly used to) only care about the shared object leafname
09:38 nwc10 none of this matters if you're using it for what it was intended
09:39 nwc10 anyway, "I want to run a programming language in my phone" is not IMO (and not H here) worth it if that's *All* that it is
09:39 nwc10 "I want to write apps on my phone, and upload them to the app store" is what is needed
09:40 nwc10 otherwise it's really a "nice to have", and that's not a priority
09:43 brrt it's geek cred
09:43 brrt but ehm.. couldn't a moar-on-android just ship another libc
09:44 brrt (python does run on android, fwiw)
09:45 nwc10 or target the JVM-a-like on it?
09:46 brrt that's a pretty good idea
10:08 rurban joined #moarvm
10:15 FROGGS jnthn: I need to distinguish int from int64 in moar somehow :/
10:16 FROGGS so, we needs to extend MVMP6intREPRData
10:16 jnthn Uh
10:17 FROGGS :o)
10:17 jnthn We should probably look for a better solution to whatever problem you're trying to solve.
10:18 jnthn Such as, exporting clong, cint, etc. types from NativeCall...
10:18 FROGGS the problem I try to solve is basically to expose a C long type to Perl 6, that has either 32bits or 64bits
10:19 FROGGS same for long long I guess
10:19 FROGGS m: my native long is repr('P6int') is Int is nativesize(32) { }
10:19 camelia rakudo-moar e1eebb: ( no output )
10:20 jnthn Sure, so what determines what the size will be?
10:22 FROGGS I'm not sure... we could run probes when we build/install nativecall and fallback to waht the vm suggests
10:25 jnthn Well, if you want to do the second we need to have a mechanism for doing that
10:26 jnthn I think at one point we pondered using negative values of nativesize as a cheat for conveying these things :)
10:26 jnthn That might have been arnsholt++'s idea...
10:26 FROGGS jnthn: we already check for certain things when building moar, it is just about putting more information into the generated config.c
10:26 FROGGS hmmm
10:26 jnthn FROGGS: No, it's more conveying to the REPR that you want a "C long"
10:27 jnthn The REPR is written in C so it can just do sizeof(long) :P
10:27 FROGGS the question is just at what time it does a sizeof() :o)
10:27 jnthn That'd be at the time the VM is compiled.
10:28 jnthn Which only gets you in trouble if the library you're loading was compiled with a different idea of C type sizes than the VM itself.
10:29 FROGGS I guess that is something you can hardly solve
10:29 jnthn That'd strike me as a rather odd setup.
10:29 nwc10 I believe your C runtime would already have crashed by then
10:29 arnsholt Yeah
10:29 arnsholt In that case you're gonna have a bad time no matter what
10:29 jnthn nwc10: I was gonna say, it sounds painful :)
10:30 arnsholt (And yes, negative bitwidths was my bad idea =)
10:30 jnthn OK, so that probably gives us a solution
10:30 jnthn arnsholt: It feels horrible, but it's hard to find specific negatives with this option... :P
10:30 arnsholt Well, your idea was better
10:30 arnsholt Add another field to the compose protocol =)
10:31 jnthn Ah
10:31 jnthn That is perhaps cleaner :)
10:32 arnsholt Yup
10:32 arnsholt Just need to check in the REPR that we don't get passed both at the same time
10:34 jnthn aye
10:34 jnthn And something in Perl 6 to get the info into the REPR
10:34 arnsholt The "you are C int" information you mean?
10:36 FROGGS is nativetype() ?
10:37 arnsholt Something like that was my plan, yeah
10:37 FROGGS is nativetype('int'), is nativetype('longlong')
10:37 FROGGS or, is nativesize('int')
10:37 arnsholt An additional method in the HOW, and a trait. Just like we set bitwidths
10:37 FROGGS we can happily take a number or a string there I guess
10:40 arnsholt My plan is string in Perl 6, and number in the REPR
10:40 arnsholt The HOW can do the mapping
10:40 jnthn Works for me
10:40 FROGGS awesome
10:40 jnthn Use nqp::const::C_TYPE_INT stuff for the integers.
10:40 FROGGS k
10:40 arnsholt Oh, yeah
10:41 arnsholt I would've just hardcoded them, but consts are definitely a good idea
10:41 FROGGS consts are way better then magic numbers :o)
10:41 moritz magic constants!
10:41 FROGGS shh!
10:41 FROGGS :P
10:58 Ven joined #moarvm
11:00 lizmat good *, #moarvm
11:00 lizmat jnthn: looking at isreadable/iswritable/isexecutable
11:00 lizmat the odd one out is isexecutable, which does its own thing on Win32 using the extension
11:01 lizmat wouldn't it make sense to have them all use nqp::stat as well
11:01 lizmat and in the case of Win32, return "unknown" ?
11:03 * jnthn wonders what Perl 5's "is it executable" does on Windows...
11:03 jnthn Is it -x?
11:03 lizmat yes
11:04 jnthn Hm
11:04 jnthn It comes back with 1 if I point it at an exe file
11:04 jnthn haha
11:04 jnthn echo omg > wtf.exe
11:04 lizmat ?
11:04 jnthn perl -e "print -x 'wtf.exe'"
11:05 jnthn 1
11:05 vendethiel joined #moarvm
11:05 jnthn :)
11:05 lizmat which is similar to what's being done in MoarVM atm
11:05 jnthn Yeah
11:05 jnthn That might be the best you can do on Windows.
11:06 jnthn But we could do that cheat behind nqp::stat also.
11:06 jnthn So we don't have to choose between it and keeping isexecutable
11:06 lizmat ok, fair enough
11:06 jnthn I'm inclined to retain the behavior
11:06 lizmat ok
11:06 jnthn It's technically dubious, but practically useful.
11:07 lizmat but shall I refactor to eradicate nqp::isreadable / nqp::iswritable / nqp::isexecutable ?
11:07 lizmat the alternative would be that I add nqp::lisreadable / liswritable / lisexectiable
11:07 lizmat *whatever
11:08 jnthn Yeah, I'd rather decrease the number of ops here than increase them, when there's an obvious generic interface to this stuff.
11:08 jnthn It's just duplicate functionality.
11:08 lizmat so what was the reason to do it this way in the first place ?
11:09 jnthn I've no idea :)
11:09 lizmat ok, otoh, rwx on a symlink pretty much seem unchangable
11:09 lizmat hmmm....
11:11 lizmat let me ponder on this some more  :-)
11:47 FROGGS lizmat: on windows there is an environment variable that has a list of file extensions that are considered executable
11:47 FROGGS that's how it works there
11:47 lizmat PATHEXT, yeah
11:58 xiaomiao joined #moarvm
12:14 ggoebel111111114 joined #moarvm
12:24 vendethiel joined #moarvm
12:39 dalek joined #moarvm
12:55 Ven joined #moarvm
13:11 vendethiel joined #moarvm
13:15 brrt http://blog.noctua-software.com/c-tricks.html <- some of these are quite nice
13:56 vendethiel joined #moarvm
13:56 Ven joined #moarvm
14:01 rurban joined #moarvm
14:21 kjs_ joined #moarvm
15:04 xiaomiao joined #moarvm
15:10 xiaomiao joined #moarvm
15:11 Ven joined #moarvm
16:20 dalek MoarVM/longish: 7d111ae | FROGGS++ | src/6model/reprs/P6int.h:
16:20 dalek MoarVM/longish: add constants for C data types
16:20 dalek MoarVM/longish: review: https://github.com/MoarVM/MoarVM/commit/7d111ae092
16:28 vendethiel joined #moarvm
16:29 FROGGS[mobile] joined #moarvm
16:32 dalek MoarVM/longish: 1c4087d | FROGGS++ | src/6model/reprs/P6int.h:
16:32 dalek MoarVM/longish: add C type long (that's why we do it after all)
16:32 dalek MoarVM/longish: review: https://github.com/MoarVM/MoarVM/commit/1c4087da95
16:55 vendethiel joined #moarvm
17:04 Ven joined #moarvm
18:03 kjs_ joined #moarvm
18:14 vendethiel joined #moarvm
18:23 flussence joined #moarvm
19:01 FROGGS joined #moarvm
19:02 FROGGS MVMP6int: Unsupported int size (-4bit)
19:02 FROGGS at src/gen/m-Metamodel.nqp:2889  (blib/Perl6/Metamodel.moarvm:compose:104)
19:02 FROGGS so far, so good
19:04 timotimo that's really not much
19:06 FROGGS it is supposed to be not much
19:07 FROGGS you know, ssd hard disk space is not that cheap
19:15 FROGGS that approach seems to be too easy to actually work
19:15 FROGGS though, too easy often also means 'much reliable'
19:25 dalek MoarVM/longer: 79b9b38 | FROGGS++ | src/6model/reprs/P6 (4 files):
19:25 dalek MoarVM/longer: support C type sized P6ints and P6nums
19:25 dalek MoarVM/longer:
19:25 dalek MoarVM/longer: We can now ask the P6int repr to give us a an int, that is as wide as
19:25 dalek MoarVM/longer: a long in C on the current platform. This should solve the issues with
19:25 dalek MoarVM/longer: NativeCall on 32 bit machines. arnsholt++ and jnthn++ for the solution.
19:25 dalek MoarVM/longer: review: https://github.com/MoarVM/MoarVM/commit/79b9b38e8e
19:27 nwc10 FROGGS: how do I test that?
19:28 FROGGS MoarVM+nqp+rakudo+zavolaj with 'longer' branch
19:28 FROGGS though, I am preparing the zavolaj branch right now
19:28 nwc10 oh, OK, mmm, I might not get as far as zavolaj
19:28 FROGGS I'll also test it on x86 linux in a moment
19:43 timotimo btw, can we somehow get single precision floats to work?
19:44 FROGGS what's wrongs?
19:44 FROGGS -s
19:51 TimToady that'd presumably just be num32 on the P6 side
19:52 FROGGS nwc10: CArray does not yet play nicely with long
19:52 FROGGS TimToady: aye
19:52 FROGGS timotimo: what is wrong with floats?
19:53 TimToady and obviously 'short double' on the C side :)
19:54 timotimo dunno, aren't our reals always double precision?
19:55 FROGGS timotimo: if you chose 'num', you get the biggest numeric type for your platform, whatever that is
19:55 timotimo and how do i get a half big numeric type?
19:56 FROGGS timotimo: half big as what?
19:57 timotimo as a double :)
19:57 FROGGS timotimo: use num32
19:57 FROGGS a double is num64
19:57 timotimo oh
19:57 timotimo duh
19:57 timotimo i didn't think of that. though it's very obvious
19:57 FROGGS there is no num16 though :o)
19:58 timotimo but when we calculate stuff with num32, we'll always be converting to regular num internally?
20:00 FROGGS I would have guessed that you might better know than me :o)
20:01 timotimo right
20:02 TimToady unless you have a pragma like 'use native num32' or so, according to spec
20:02 TimToady but I think the current implementation doesn't actually follow the 'wide temps' policy
20:03 timotimo fair enough
20:07 kjs_ joined #moarvm
20:11 FROGGS hups, I confused bits and bytes
20:14 FROGGS ... and with that NativeCall passes on x86_64 again
20:15 dalek MoarVM/longer: 78890ef | FROGGS++ | src/6model/reprs/P6 (2 files):
20:15 dalek MoarVM/longer: unconfuse bits and bytes
20:15 dalek MoarVM/longer: review: https://github.com/MoarVM/MoarVM/commit/78890ef969
20:16 FROGGS NativeCall passes on x86 \o/
20:16 TimToady though on some machines you have long double, num80 or so
20:19 FROGGS TimToady: it is prepared for that...
20:20 FROGGS my native longdouble is repr("P6num") is Num is nativesize('longdouble') { }
20:20 FROGGS one can do that
20:20 FROGGS 'char' and 'short' and so on works too
20:21 FROGGS when the branches are merged I'd even like to go that far as to disallow 'int' in NativeCall
20:21 FROGGS same for 'num'
20:24 TimToady seems sane
20:26 FROGGS nwc10: the 'longer' branches in the for repositories are ready now
20:26 retupmoca FROGGS: if 'int' is disallowed, will there be a new type I can use to represent a C 'int64_t' ?
20:27 timotimo int64 exists already
20:27 FROGGS retupmoca: there is 'int64'
20:27 retupmoca oh, ok
20:27 retupmoca didn't know that
20:27 FROGGS only 'int' means: the biggest integer type there is on your system... which does not really map to what C thinks (or thought)
20:27 FROGGS (and num)
20:28 FROGGS so, C's int is int32, C's long is long, ...
20:28 retupmoca makes sense
20:28 FROGGS retupmoca: the NativeCall readme has a nice table for that
20:29 FROGGS I'd like to export like like char and short, though, then you cannot have subs with these names in your namespace anymore
20:32 FROGGS jnthn / arnsholt: please review the 'longer' branches in moar+nqp+rakudo+nativecall... it passes all tests on 32 and 64bit on linux
20:34 TimToady well, int is biggest integer "that runs at full speed"
20:34 TimToady so even if your C can emulate int128, that runs slower than int64 on a 64-bit machine
20:36 TimToady c-char and c-short would work as a systematic prefix, I suppose
20:36 TimToady could even have c-long-long
20:36 FROGGS ahh yes, makes sense (int speed)
20:36 TimToady with hyphens for spaces
20:37 TimToady we could kinda reserve the c- space for C types
20:37 TimToady or we could even go with c:long-long
20:37 TimToady std: c:long-long
20:37 camelia std f9b7f55: OUTPUT«[31m===[0mSORRY![31m===[0m␤Undeclared routine:␤ 'c:long-long' used at line 1␤Check failed␤FAILED 00:00 134m␤»
20:37 FROGGS hmmm, if you port a bigger C lib this might be not that fun to type all the time
20:38 TimToady std: C:long-long
20:38 camelia std f9b7f55: OUTPUT«[31m===[0mSORRY![31m===[0m␤Undeclared name:␤    'C:long-long' used at line 1␤Check failed␤FAILED 00:00 134m␤»
20:38 TimToady if you don't mind the uppercase
20:38 FROGGS looks nice though
20:38 FROGGS I'd prefer the uppercase, yes
20:38 FROGGS I like to spell language names correctly :o)
20:39 TimToady m: constant C:int = int64; say C:int
20:39 camelia rakudo-moar fec233: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/d3OziuSFEB␤Variable '&C' is not declared␤at /tmp/d3OziuSFEB:1␤------> [32mconstant C:int = int64; say [33m⏏[31mC:int[0m␤»
20:39 TimToady rakudo needs to be taught better about extended names
20:39 FROGGS std: constant C:int = int64; say C:int
20:39 camelia std f9b7f55: OUTPUT«[31m===[0mSORRY![31m===[0m␤Undeclared name:␤    'C:int' used at line 1␤Check failed␤FAILED 00:00 135m␤»
20:39 FROGGS you first :P
20:39 TimToady apparently so does STD :)
20:39 TimToady but differently
20:40 TimToady eep, someone removed the color
20:40 TimToady yuck
20:40 FROGGS :/
20:42 TimToady I guess it's a channel setting
20:43 flussence that'd be mode +c, iirc...
20:43 FROGGS yeah, I see colors in privmsg
20:59 nwc10 FROGGS: well, all "ok ..." on x86_64 with an ASAN build of MoarVM, but ASAN isn't valgrind, so wont' spot issues with "other" people's code
20:59 nwc10 but, "it did work" with something far more paranoid than usual
21:00 nwc10 I need to go to bed
21:00 FROGGS me too :o)
21:00 FROGGS thanks for testing, and gnight :o)
21:00 nwc10 the small "auf" likes to wake up early
21:00 nwc10 not *that* early, but still early enough that I didn't want to be
21:01 nwc10 er, don't.
21:01 nwc10 whatever. zzzz
21:01 FROGGS we'll get up at 6:30 to get to the zoo early :o/
21:01 FROGGS nwc10: sleep well
21:04 kjs_ joined #moarvm
22:01 rurban joined #moarvm
22:02 jnthn FROGGS: I think I'd have preferred a different trait at Rakudo level.
22:02 jnthn FROGGS: Introspecting type name feels...smelly.
22:04 jnthn "is cnativetype('long')" or so
22:04 FROGGS_ joined #moarvm
22:10 jnthn FROGGS_: Otherwise, I'm happy enogh with it.
22:10 jnthn enough, even.
22:14 japhb BTW, to whoever mentioned 16-bit floating point: It's a thing.  It's called 'half' on the compilers that support it, IIRC.
22:14 TimToady short float!
22:14 japhb It's used for HDR rendering and other graphics tasks.
22:14 TimToady don't some GPUs speak it natively
22:14 TimToady ?
22:15 japhb TimToady: Yes, exactly.
22:15 japhb So if you want to send or receive a pile of data from those cards without a crazy amount of conversion ....
22:21 jnthn "Unrecognized revision specifier 'food-31-g2d7eddb'"...dammit, I really shouldn't use my real dev checkouts of repos for demos in class...
22:25 jnthn Merging native-ref in Moar. It should break nothing for mainline NQP/Rakudo.
22:25 jnthn And there's no reason for it to be a branch any more :)
22:25 jnthn Moar needs to learn to optimize them better, but I'm happy the API will live on.
22:28 timotimo i haven't yet gotten to know what exactly about them is optimizable
22:28 timotimo not having to take a reference when a simple native value "copy" would suffice, perhaps?
22:28 dalek Heuristic branch merge: pushed 35 commits to MoarVM by jnthn
22:28 jnthn timotimo: Yeah
22:28 jnthn timotimo: Well, the interesting case to make work is that
22:29 jnthn class Foo { has int $.x is rw }
22:29 jnthn $a-foo.x = 42;
22:29 jnthn When it inlines the accessor method, we'd like it to eliminate taking a ref at all
22:29 jnthn And basically just emit a bindattr
22:29 jnthn Which in turn lowers to a pointer thingummy
22:30 timotimo right, so we would want to remember where a reference was taken from and when we know the reference isn't used afterwards any more, we'll just bindattr instead of going through the reference
22:30 jnthn yeah
22:31 timotimo i'd like to have something mildly similar for boxing/unboxing
22:31 jnthn I'd been pondering handling them in the same kinda way
22:31 timotimo where we remember, that some value is just a box for a register that's (hopefully) still alive
22:31 jnthn Both really want doing post-inline.
22:32 TimToady does our current JIT have any sort of peephole optimization?
22:32 timotimo yes, very much so
22:33 jnthn Lots of ops get turned into simpler one, though a lot of it is possible because of non-local analyses.
22:33 TimToady if it's non-local, it's not a peephole optimizer
22:33 jnthn so I'm not sure you'd class all of 'em as true peephole.
22:34 TimToady but I really mean after it gets turned into linear assembly/machine code
22:34 jnthn Ah
22:34 jnthn Then no, not much there...
22:34 TimToady seems there are some infelicities at that level
22:34 jnthn Though real reg alloc would help us out a lot.
22:34 jnthn And probably those two want tackling around the same time.
22:35 jnthn It all needs care as you need to keep the callframe in decent enough shape for deopt.
22:35 TimToady not suggesting any schedule change, just trying to keep a feel for where we are
22:35 jnthn Well, if we're really lucky we might get brrt++ for another summer to focus on producing better code :)
22:37 timotimo say, jnthn, are we already running over code again after an inline has happened?
22:37 * TimToady hopes the big announcement makes it more likely that TPF gets admitted as an org
22:37 jnthn timotimo: Not to do the same things we did as we go inlining
22:38 jnthn timotimo: But yes, we do things like dead code elimination after inlining, for example.
22:38 jnthn timotimo: We need to be careful not to do too many passes...or we make it harder for the optimizations to actually pay off.
22:39 jnthn TimToady: Hopefully, yes
22:41 timotimo understood
22:42 timotimo well, once the spesh graph is already completely in the cache, we could as well go over it a second time :P
22:43 jnthn Just 'cus it's in cache doesn't mean it's free :P The way spesh allocates does mean all the stuff ends up bunched together in memory for cache happiness, though :)
22:43 timotimo yup, i thought of that
22:43 jnthn Grrr...airline didn't feed me quite enough so now I have midnight munchies :)
22:44 jnthn Maybe I should go take a beer snack. :)
22:44 jnthn Which can only be eaten with a beer. Hard life.
22:45 jnthn The post-merge Moar seems to build NQP and Rakudo fine :)
22:45 jnthn So, should be all good.
22:47 * jnthn wanders off for the evening
22:47 timotimo sweet
22:47 jnthn Will be distracted most of tomorrow, but may get some patch or two in during the evening :)
22:47 jnthn o/
22:47 timotimo neato
23:14 vendethiel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary