02:56 raydiak joined 04:51 FROGGS[mobile] joined 05:08 vendethiel joined
raydiak can someone check this out for me when they have a chance, and give me feedback and/or merge it? github.com/MoarVM/MoarVM/pull/172 05:40
FROGGS[mobile] looks good to me... 05:47
though, cant merge it atm :/ 05:48
raydiak thanks; mostly wanted to make sure it looked sane, C isn't a strong suit of mine so I just kind dug in and blindly poked :) 05:49
*kind of
FROGGS[mobile] I'd say it is perfect unless there is a hidden off-by-one that I dont spot that early 05:51
raydiak heh no big deal, someone will figure it out after some tests flap for a few months 05:54
07:31 rurban_ joined 08:53 kjs_ joined 09:06 zakharyas joined
arnsholt raydiak: Looks sane to me. Indeed, IIRC that's something the Parrot code already does. 09:20
09:21 kjs_ joined
raydiak oh good, haven't look at that one...checked out jvm but it's a bit overwhelming at this hour, wasn't sure where initialization happens or how to memset in java 09:22
arnsholt Yeah, the JVM code is very different
For Moar the Parrot version is the one to look at
raydiak well moar was nice and clean and I was lucky to see examples of doing almost exactly what I want to copy, didn't have to look at much else 09:24
if it's a CArray of CArrays, will elem_size equal sizeof(MVMObject *)? if so there's 2 duplicate consts in there I can fix 09:26
09:27 kjs_ joined
raydiak I see sizeof(void *) on line 55, so maybe not...or is the size of all pointers the same? why does it use void instead of MVMObject there anyway? 09:31
arnsholt I'm not sure in the absolute general case (weird architectures and such), but pointers are generally all the same size 09:57
nwc10 agree, and I doubt that libuv is yet ported to any of them. (if we can even find any these days) 10:00
jnthn I looked at the PR and didn't see any obvious problems.
10:17 FROGGS[mobile] joined 10:35 FROGGS joined
timotimo o/ jnthn 10:38
how's today? :)
10:40 vendethiel joined
lizmat timotimo: jnthn is flying to Brussels atm 10:41
timotimo ah
well, i hope his flight is comfortable and on time :)
lizmat probably no connectivity on the plane
lizmat too
FROGGS IIRC he will be here at 1pm 10:42
FROGGS is in room 36 10:43
rurban_ on intel exist near, far and huge pointer sizes, for the linkers there exist tiny, small, medium compact, large or huge segments. on current architectures there only exists flat memory models, with huge pointers. on the jit level it might be optimized to smaller pointers. eg. in v8. but not in moar 11:41
e.g. en.wikipedia.org/wiki/X86_memory_segmentation 11:42
12:09 kjs_ joined 12:21 kjs_ joined 13:31 kjs_ joined 13:33 rurban_ joined 13:43 brrt joined
brrt yeah, moar jit treats all pointers as huge (8 byte) 13:49
lgtm too. i can probably merge it from here 13:50
timotimo is there performance to gain from using smaller pointers?
brrt on new machines i doubt that 13:53
but iirc you can use it to hack values and pointers in the same quadword 13:54
although i dont know the details and could well be wrong 13:55
btw i won't be at fosdem this year. dying pet situation :-( 13:56
github app doesnt allow me to merge 13:59
dalek arVM: 83c68df | raydiak++ | src/6model/reprs/CArray.c:
Zero-fill CArrays
 14:02
arVM: 8e8539e | raydiak++ | src/6model/reprs/CArray.c:
Minor oversight, use an available const
arVM: 2cb9656 | brrt++ | src/6model/reprs/CArray.c:
Merge pull request #172 from raydiak/master

Zero-fill CArrays
brrt but webapp does 14:03
afk. have fun all
14:04 woolfy1 left 14:05 woolfy joined, woolfy left 14:46 rurban_ joined
rurban_ brrt: have you looked into nan-tagged double's to represent unboxed numbers and everything else, like v8 does? I'm not sure yet if it's worthwhile 15:24
15:31 brrt joined
brrt rurban_: i have not. but i do think that's what i meant; i don't know if this has anything to do with pointer size distinction 15:32
it is in general much easier just to use huge pointers; moreover the nan-pointer distinction that v8 uses is more useful in 32 bit (i believe), and more useful yet if your primary number type is a floating point 15:33
as it is in javascript and as it isn't in perl6
if we'd have some certainty on small integers 15:34
rurban_ yes, they do arith with doubles only, only if the type inferencer proves it's an int, it will change it to int 15:35
same as lua also
one problem is that jo (jump overflow) i.e,. auto-promotion int->bigint/double is only available in jit 15:36
brrt 'proves it is an int' - that's interesting 15:37
rurban_ if array index or loop counter e.g.
brrt ah i see
especially if 'hidden'
hmm
rurban_ mozilla has a video online about their nashorn vm, which does the same
brrt ok, now i get what was meant with the 'small bigint jit path' 15:38
oh, care to share? :-)
rurban_ uh, not mozilla, oracle it is
JimmyZ can't follow you 15:39
rurban_ It was in Strange Loop last year...
www.youtube.com/watch?v=KKaHkkpdHxg 15:40
thestrangeloop.com/sessions/nashor...vm-in-2014
I still have to find a good description of nan-tagging in v8 15:41
brrt ever since i've seen pypy i've been pretty sceptic of the idea of a 'reusable dynamic language implementers toolkit' 15:42
:-) 15:43
but it's interesting at least
'like llvm, but for dynamic languages on the jvm' 15:44
rurban_ well, they'd need a MOP to do that. The problem for parrot also is the different object systems it has to support 15:45
brrt fwiw, i now do know a really good reason not to use LLVM for the moarvm JIT
rurban_ perl6-like roles, perl5 like classes+objects, js-like prototypes, ...
brrt oh, yes; and think about the primitives
(won't somebody please think about the primitives!) 15:46
JimmyZ what's the really good reason?
rurban_ I wont use it for C++ and its size
brrt llvm is, upon further examination, neither really close to moarvm nor to the metal
(llvm ir)
and the goal is to write a simple-and-efficient bridge between moarvm and the metal 15:47
rurban_ they only benefit would be the post-ir optimizations for the native backend
JimmyZ dynasm is good enough :P
brrt but for that, you'd need to use the llvm ir; and llvm ir doesn't map well to moarvm at all
rurban_ but the hard part are the pre-ir optimizations, e.g. on types, objects, constant folding, ...
JimmyZ rurban_: we have rakudo-v5 on moarvm
rurban_ I know 15:48
brrt well, that's what i have jnthn++ for
he does the hard parts
i take the glory
:-P
rurban_ With roles or generics you can easily simulate classes
JimmyZ I took the LHF :P
rurban_: parrot should know what should be in core, what should be out of core 15:49
well or plugin
rurban_ parrot doesn't cannot call methods properly yet 15:50
brrt plugins on a vm?
rurban_ neither does it do multis or roles properly
JimmyZ yeah, like rakudo ops
rakudo container
brrt i see 15:51
JimmyZ and 6model on parrot
6model is not in parrot's core :P
rurban_ 6model on parrot is a long way to go still
First I tried to get performance out of it, undo all the damage from the last 6 years
JimmyZ yeah, i saw the irclog, someone don't like 6model in core when it was developed 15:52
brrt rurban_++ for doing a thankless but valuable job 15:53
rurban_ but it needs to be in core. something betetr than 6model even, a dynamic MOP. 6 model is too specialized on perl6
JimmyZ rurban_: I still think whiteknight's gist of parrot goal is good
brrt afk
JimmyZ :P
rurban_ we need to abstract the dispatch model and the object model, and offer fast paths to the most common ones. 15:54
we still hardcode everything to class/object/undef
... and default 15:55
JimmyZ well, you need to make parrot popular, then let the people improve it. unless it will be dead before you find better things than 6model :P 15:56
rurban_ I only do parrot, because I need the same threading model for my own vm :) 15:57
which is way better than moar
but no threads yet
JimmyZ yeah, but if you leave parrot before it's popular? 15:58
rurban_ It's still easy to maintain it 15:59
problem is finding time to extend it
JimmyZ who want to continure maintain a things that after 20 years' maitain, it still nobody use it 16:00
rurban_ we will see
JimmyZ :P
rurban_ same as with perl5. internally horrible, but still usable from time to time 16:01
JimmyZ It's always better let it in core , until you find another better one than current better one 16:02
perl5 has many users...
parrot doesn't 16:03
16:09 lizmat joined
rurban_ yep 16:09
jnthn points out that MoarVM doesn't have a clue what a class or a role are, and doesn't need to. 16:10
JimmyZ yeah, the 6model itself never knows what class/role is 16:14
rurban_: we also have a toy php/ruby compiler on 6model :P 16:18
16:23 woolfy joined 16:43 woolfy left 18:05 pyrimidine joined 18:09 retupmoca joined, btyler joined 18:18 harrow joined 18:21 ingy joined 18:49 FROGGS[mobile] joined 19:27 kjs_ joined 19:46 colomon joined 20:33 retupmoca joined 21:23 colomon joined 21:25 FROGGS joined 21:26 colomon joined 21:28 colomon joined 21:39 kjs_ joined 21:40 FROGGS[mobile] joined 21:43 colomon joined 22:18 colomon joined 22:33 vendethiel joined
raydiak would we be able to nativecast from CArray by just adding a similar-looking else block for it at github.com/MoarVM/MoarVM/blob/d235...all.c#L914 ? 23:14
or is that an intentional omission because of some other surrounding complexity I'mm unaware of?
*I'm
FROGGS raydiak: no intend... casting from CArray should work out 23:44
raydiak thanks...I went ahead and gave it a shot, but now trying to use the pointer w/memset via zavolaj gives me a segfault 23:46
FROGGS hmmm, I am too tired right now :o( 23:47
23:47 woolfy joined
FROGGS I'll look into it tomorrow in case you gist something 23:47
raydiak no problem, I appreciate your help :) I'll make a gist if I don't figure it out 23:48
23:50 kjs_ 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!