github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 12 July 2013.
timotimo i suppose i'll have to wait a bit longer before starting to benchmark moarvm gets sensible 00:01
while_empty, while_empty_native and while_bind all end up a tiny bit faster than nqp-parrot at the biggest workloads 00:02
10/42: Testing while_push ... 00:04
Segmentation fault (core dumped)
moarvm is almost at the same speed as nqp-parrot in the while_hash_set benchmark, except at the end it gets slower than nqp-parrot 00:07
while_array_set coredumps as well 00:09
i have no idea where the "cut" is where nqp-parrot ends and moarvm starts or where the moarvm is invoked, so i have no idea where i'd have to look to make exit codes be passed outwards properly :( 00:18
congratulations, moarvm is a bit faster than nqp-parrot in the postwhile_nil_native benchmark! 00:24
00:32 benabik joined
diakopter timotimo: okay. 00:50
timotimo: probably those errors won't occur if you don't use --optimize 00:51
there are a couple things there that have been known for many months
timotimo: re "bit faster", *sigh* 00:52
timotimo are you sighg because i concentrate on performance or because the benchmarks are meaningless? 00:54
01:48 FROGGS_ joined
diakopter timotimo: no :) 02:47
timotimo please elaborate?
welp, i better get to bed 02:52
diakopter bbiab
05:26 benabik joined 05:58 itz joined 07:22 FROGGS joined 08:43 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
13:59 jlaire joined 14:06 birdwindupbird joined
dalek arVM: 36e3254 | (Tobias Leich)++ | / (8 files):
added and mapped noninteractive nqp::readlinefh
 14:07
FROGGS jnthn: should I commit src/NQPHLL.nqp with everything commented it that is compilable? it is quit a lot 14:22
I guess the next thing I do might be sprintf... or is there something more important? 15:03
ahh, nqp::stat first 15:07
15:34 FROGGS joined 16:15 JimmyZ_ joined
JimmyZ_ Hello FROGGS 16:16
FROGGS hi JimmyZ
gah, libapr cant tell one if a file exists... (or I am just stupid and cant find it) 16:18
JimmyZ_ FROGGS++, for adding new ops 16:28
TimToady can't one just see if a getfileinfo call fails? 16:30
a google search seems to refer to both stat and lstat variants of that 16:31
FROGGS TimToady: I'm currently reading that stat cant handle files > 2GB reliable... 16:34
so I am reading a bit before deciding what to do
TimToady surely it can tell whether the file is there or not, regardless of whether it mishandles the size
you were looking for an existence test, right?
FROGGS the third one says that: stackoverflow.com/questions/230062/...s-platform 16:35
TimToady: yes, only for existence, I can do the rest using libapr 16:36
16:37 benabik joined
FROGGS I think I'm going to use access() 16:40
TimToady that seems okay for existence, as long as you don't try to check for any other bits at the same time 16:42
for most other purposes, access is wrong, and you want something like eaccess 16:43
FROGGS it is really just about existence 16:44
cool
TimToady I guess stat would work if you trapped EOVERFLOW, since you can't get that unless the file exists, but access does seem simpler 16:46
but who'd be stupid enought to compile with 32-bit off_t these days anyway? 16:47
most people would like to be able to handle DVDs 16:48
FROGGS hint: a line like "#define MVM_stat_exists = 0" is not what you want 17:50
-.-
18:46 colomon joined
sorear :) 18:57
diakopter :D 19:39
FROGGS: sometime we need to talk about setting the thread's "I'm in external code" flag when calling things that could call things that aren't statically linked or could do IO 19:49
FROGGS okay 19:50
diakopter I'm not 100% certain jnthn intends/agrees that needs to be set during all the system calls, but I suspect he does 19:51
dalek arVM: 4e2bc25 | (Tobias Leich)++ | / (9 files):
added and mapped nqp::stat

This replaces the duplicate eof moar-op, too.		 20:05
diakopter FROGGS: those ops in interp.c don't look like the same order as in oplist 20:06
FROGGS ohh, does that matter? 20:07
diakopter they should be in order of their constant to help it make a jump table, I'd think
(I mean, theoretically it can figure out they're independent and put them in order)
FROGGS okay, will reorder it in a bit 20:08
diakopter it's not a big deal though because they'll all be rearranged at some point this year, I'd expect
jnthn Yeah, we'll do an op list cleanup at some point. 20:09
diakopter jnthn: see speculation 21 min ago 20:10
jnthn FROGGS: I think there already is an nqp-src/NQPHLL.nqp or so
Yes, any system call that can block at least. 20:11
FROGGS jnthn: I know about nqp-src/NQPHLL.nqp, the question is: if it compiles when commenting in stuff, should I commit that? 20:12
diakopter FROGGS: you mean when uncommenting new/pasted stuff?
FROGGS no
stuff that is there, but was commented out because the io ops where missing 20:13
jnthn FROGGS: You can uncomment the commented stuff if it still builds
diakopter okay, so *un*commenting stuf
jnthn FROGGS: That's the idea...
FROGGS: Uncomment what works, so we can see what's left
FROGGS err, yes
jnthn That's how everything so far as happened ;)
FROGGS yeah
diakopter FROGGS: I was confused because you said "commenting" :D
FROGGS diakopter: yeah, sorry :/ 20:14
"commenting in" might be a bit too germish
jnthn: I guess the next thing (not for me) could be exceptions+try/catch 20:15
jnthn Yes, that's on my todo list. I already did a bunch of the groundwork
FROGGS cool
(just so that the moarvm backend can be in this-months compiler release :P) 20:16
btw, the startup of nqp nqp-moar-cc.nqp -e '1' is still effected by parrot, right? 20:17
I mean, it must be, no?
jnthn Right, it's a cross-compiler 20:19
FROGGS right
jnthn No, moarvm backend will be a bit further off
FROGGS is the runtime effected too? I guess not
jnthn It spits out moarvm bytecode, then runs moarvm 20:20
FROGGS k, thanks
jnthn MoarVM's execution time is more likely affected by various other things :)
FROGGS for example? I'd think libapr has the most impact 20:21
jnthn Well, partly by GC needing some work ;) 20:22
FROGGS ahh, yes, of course 20:23
jnthn And other bits. The difference between an optimized and unoptimized build is fairly notable too, and the default is unoptimized
FROGGS one cool thing atm is that you can add ops, and after 3 seconds you got it compiled and you see the test out... that is pretty nice 20:24
not waiting for ten minutes or moar 20:25
jnthn yes, this kinda dev turnaround time is fairly deliberate ;) 20:26
FROGGS btw, have you an opinion to an interactive readline library? 20:31
linenoise was mentioned but I have no idea if that will work on windows
sorear looks into MoarVM for the first time 20:34
this mast/compiler.c thing looks pretty parrot-specific
jnthn sorear: It's all very macro'd 20:36
So replacing node_parrot.h or so will mean it's about Moar'd
FROGGS: No opinion on the readline thing without looking into it more... 20:39
diakopter sorear: there's one or two things labeled "parrot" "hack" that are there 20:40
jnthn I guess that libreadline is the most common option 20:41
dalek arVM: ce83acc | (Tobias Leich)++ | src/core/interp.c:
use the same ordering like in core/oplist
 20:44
arVM: ef23f5d | (Tobias Leich)++ | nqp-cc/nqp-src/ (2 files):
uncomment bits that are now available
 20:50
benabik diakopter: ... Jump tables don't need to have their destinations in order. 21:30
diakopter ... they do if it wants to translate the value to an index/offset 21:32
benabik In assembly, it ends up being jump to offset from here, followed by a huge pile of jump instructions.
jump 0+(index); jump label1; jump label3; jump label2 21:33
diakopter I do not see how you could conclude I didn't know that...
benabik The indexing goes to a jump that can be anywhere, so it doesn't matter if the switch statement is in order. 21:34
diakopter yes ok 21:35
benabik Now, having them in the same order as the original list can certainly help the programmer. :-D 21:36
dalek arVM: 434fd28 | (Tobias Leich)++ | src/io/fileops.c:
remove unneeded include which was accidentally added
 22:08
23:06 colomon 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!