timotimo the changes seem to happen almost exclusively in the regex engine 00:02
the test file i'm using only triggers it a lot because it's so much perl6 code it wants to parse during startup
so i'll have a look at how it changes the core setting compilation
01:07 colomon joined 01:18 oetiker joined
dalek arVM: cc20af6 | timotimo++ | src/jit/emit_x64.dasc:
more compact jit for add, sub, bor, band and bxor

those can load the argument from the stack and do the instruction in-memory ("in-place"), leading to smaller code (one mov saved)		 02:45
03:18 tadzik joined 03:39 agentzh_ joined 04:00 agentzh_ joined 05:03 agentzh_ joined 05:34 FROGGS[mobile] joined 07:06 FROGGS joined 07:08 rurban joined 07:09 zakharyas joined 07:12 Ven joined 07:30 Ven joined 07:50 lizmat joined 08:24 Ven joined 08:48 Ven joined 08:51 agentzh_ joined 09:19 Ven joined 09:49 Ven joined 10:45 Ven joined 10:58 Ven joined
timotimo right now i'm thinking perhaps a few more places could be made to use accumulator-in-memory addition/subtraction/... if we shuffle some "set" instructions around more carefully in spesh 11:18
11:23 brrt joined
brrt \o 11:23
timotimo++ :-) patch works well
timotimo cool :)
but i'm afraid, if the code just turns a "add 1 2 3; set 2 1" into an "add 2 2 3; set 1 2", it won't save much 11:24
well, it'll still save a mov all in all
so i guess that's nice
brrt yeah, it is 11:25
its probably a very very minor win, but still cool 11:26
timotimo i think i need to run the core setting compilation through cachegrind 10 times before and after to get a reliable comparison ... 11:27
brrt :-) right 11:28
but it doesn't hurt, for one thing 11:29
timotimo looking at just the "bytecode size" lines, there's some visible difference, but all in all it's very, very small
however, that doesn't factor in what gets run how often
that's why i cachegrind 11:30
brrt right 11:34
11:46 agentzh_ joined 12:01 colomon joined 12:23 Ven joined 12:48 agentzh_ joined
hoelzro since panda will install .so files into $INSTALL_DIR/share/perl6/site/lib, would it make sense to add that directory to the executable's rpath/runpath so that dlopen() can find the .so files installed there? 13:22
tadzik yes 13:23
I can't think of any reason why that's not a good idea
FROGGS we would have to do that in the wrapper scripts I think 13:27
nwc10 ideally we'd use a linker option to add to it. 13:29
umm. yes. um.
at MoarVM build time.
OK.
FROGGS nwc10: see
nwc10 yet another reason for wanting fakecutables.
timotimo yes 13:30
hoelzro thinks of what that would mean for the JVM
timotimo if we want perl6 to shine at ludum dare, we want fakecutables
ideally, fakecutables that you can also build for the windows backend from a unix box and vice versa
and osx, too
hoelzro sorry, fakecutables? 13:31
FROGGS an executable that invokes moar with moarvm bytecode 13:32
timotimo a single executable that contains a moarvm, the code you're running as well as libraries, apparently
FROGGS like 'perl6 -MFoo myscript.pl' compiled to a myscript.exe
hoelzro ahhhh 13:33
I was thinking about something like that; I was going to call it sixpack =)
FROGGS and that one contains an ELF binary, but also moarvm bytecode (the latter makes it fake but cute)
hoelzro heh
13:33 agentzh_ joined
nwc10 I think, mininally and least ambiguously, a single executable that contains all the functionality of the wrapper scripts that we generate, such as perl6-m, and (preferably, but technically not absolutely necessary) also contains (at least) the first bytecode file that the wrapper loads 13:34
timotimo fwiw, zip archives have their "header" at the very end of the file, and all the values are relative, afaik
nwc10 timotimo: indeed
timotimo so you can just cat a zip archive to the end of an exe file, because the executables will look at the beginning only
or something like that
that's how the python people make it
nwc10 yes, but IIRC ideally you then fix up the zip central directory file offsets 13:35
(to stop any tools warning)
timotimo ah, ok
gotta run now/soon
nwc10 and if you're feeling like poor quality steganography, you could also hide stuff between files within the zip file
jnthn hoelzro++ # 6pack :D 13:46
hoelzro feel free to use the name =) 13:47
jnthn no no, feel free to implement it! :P
hoelzro I'll see what I can do =) 13:48
14:36 Ven joined 14:44 Ven joined 15:20 agentzh_ joined 16:23 FROGGS[mobile] joined 16:35 agentzh_ joined 17:13 FROGGS joined 17:56 vendethiel joined 18:47 FROGGS[mobile] joined
dalek arVM/cunion: 8a2504f | FROGGS++ | / (13 files):
add support for CUnion repr
 19:14
timotimo ooh 19:15
FROGGS I just reapplied the union branch to master and pushed to this new branch 19:16
masak a CUnion, is that like mermen, mermaids and sea monsters going on strike now and then? 19:17
masak .oO( "equal pay for equal work! no more under-the-water deals!" ) 19:18
timotimo ok
FROGGS timotimo: though I hope to make into next week's weekly :o) 19:19
timotimo that'd be nice 19:22
do we have anything for making inlined sized arrays doable?
19:24 FROGGS[mobile]2 joined 19:25 brrt joined
brrt fakexecutable are a really good topic for a hackathon 19:25
many different objectives and solutions 19:26
relatively easy doable in a weekend, too
timotimo hahaha
you're funny
brrt why? 19:28
timotimo many people have tried
brrt ok, what makes you think it can't be done in a weekend, provided you have some consensus on what you want
timotimo i don't know, tbh
i didn't try doing it yet 19:29
brrt the python way of fakexcecutable is very different from what nwc10 just mentioned, which is relatively easily doable
in fact...
the python way isnt very difficult, strictly speaking, either 19:30
hoelzro brrt: how does python do it?
brrt i think timotimo mentioned it :-)
irclog.perlgeek.de/moarvm/2015-05-12#i_10589168 19:31
timotimo right, there's something that puts the python.exe "at the start" and finishes the file with a zipfile that the import statement knows how to load stuff from
brrt nods 19:32
and if you can rig the moar executable to detect this situation and load from the zip archive, well, you're golden 19:33
hoelzro ah ha
brrt on of my main difficulties is: do you want to require a c compiler and/or linker, or not
hoelzro on the target system?
brrt because in the latter case you can even link to libmoar.so
on the builder system
(actually libmoar.a) 19:34
hoelzro I think I would require a build env on the building system
at least to start
brrt but my point is, that suggests a very different set of solutions from the case where you do not 19:35
hoelzro indeed
brrt well, that does mean that 90% of windows users won't be able to *make* fakexecutables even if they have perl6 installed
and you can plausibly hack around it
hoelzro if I end up making this (which I probably won't), I would target Linux first
Windows (w/o a build system) would be a bonus 19:36
brrt well, i'd think windows users would be the most common target, and then macs, and only then linux 19:37
linux folks have containers these days
hoelzro sure
linux would be my first target because I know it =)
more of a POC
brrt faiir enough, and no pressure 19:38
but that's why i'd say it's a good hackathon topic
hoelzro it is!
brrt because then you can discuss
bbiab
20:12 rurban joined 20:25 cygx joined
cygx o/ 20:25
FROGGS hi cygx 20:26
cygx hoelzro: brrt: I already made an nqp fakecutable some time ago ( gist.github.com/cygx/f7eb20d6c73294f72245 ), embedding the .moarvm files via the linker
hoelzro cygx: nice
FROGGS and brrt attempted it and me also :o)
cygx but to work for Perl6 modules, you'll probably have to hack the ModuleLoader
FROGGS correct 20:27
though, we CompUnitRepos now, so we can do more these days
cygx I'm probably not tackling that any time soon
but what I'm actually planning to do is create a single, standalone MoarVM+NQP+Rakudo binary 20:28
if someone does get around to implementing Perl6-level fakecutables, it wouldn't be too hard to throw in TinyCC as well 20:31
that way, windows users wouldn't need their own toolchain 20:32
japhb FROGGS: It occurs to me that it would be a useful test of whether the CUR design/API is sufficiently flexible 20:36
hoelzro I don't care if someone else does it, I just really want the name 6pack to be used =)
FROGGS japhb: aye, problem is that time on earth is limited for me :S 20:38
japhb FROGGS: So do all your programming on plane flights? 20:39
FROGGS to save a handful seconds?
but the api should be good enough, given we can load stuff from json blobs 20:40
20:42 brrt joined
brrt cygx: that actually looks quite a bit like my own design, although i embedded the binaries in a header file rather than using a linker 20:43
cygx brrt: in my next iteration, I'm going to just hotpatch the object files 20:46
brrt many wow 20:47
all in perl6, i suppose :-P
cygx brrt: there's no wow involved - just a unique string that I can find and replace 20:48
brrt hmm, right, hadn't thought about it that way 20:49
wat: dresden-pm.github.io/gpw2015/html/...us.html#28 21:00
jits are not a 100% performance win
not even an idea how much sense that would make
21:01 Peter_R joined
timotimo brrt: don't underestimate rurban 21:02
also, steal his ideas after he's implemented the things :)
brrt ah, that's rurbans talk then
timotimo aye
brrt that explains a lot
cygx brrt: 100% performance win could mean double its speed
timotimo that's what's meant, yeah 21:03
brrt ugh.... that.... kind of language-quantitive thing makes my head hurt
but fair enough
timotimo hm?
brrt ... and that's not ambitious enough :-P
it's like 90% efficiency or a 4,2 coefficient of performance etc... 21:04
specificallly, 100% performance implies 'the most you could possibly get out of it' 21:05
japhb brrt: Are you allowed a nondeterministic oracle? 21:06
;-)
timotimo ah, now i understand what you mean 21:07
brrt is not entirely getting the joke possibly due to a language barrier
performance is a vague, nonsensical term
(i have so many blog posts still to write :-o i still have to kill the myth of the elegant direct threaded interpreter) 21:08
japhb: oh i get it :-) 21:10
brrt is tired :-( 21:15
see you tomorrow
cygx is going to leave as well 21:19
bye o/
21:19 cygx left 21:24 Peter_R joined 21:31 Peter_R joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!