<cremes>
not everything in rbx is faster. we still have slow spots, so we love to hear where real world code (as opposed to artificial benchmarks) are slower in rbx than in jruby or mri.
<maasha>
cremes: yup, got it. For now I was just wondering if rbx was 3 times slower than MRI
<maasha>
in general
benlovell has joined #rubinius
<cremes>
heh, no.
<cremes>
if it was, what would be the point of it? :)
<maasha>
well, I am crunching scientific data and I have many idle cores at my disposal.
<maasha>
So instead of torturing myself with fork and IPC I want multi threading on multi cores.
<maasha>
Damn GIL in MRI
<cremes>
yeah, that’s similar to what moved me to rbx. i do financial analysis so mri was getting in the way. now i can get all cores humming along.
<cremes>
in fairness, jruby can do the same. i use jruby almost exclusively when i need to do work on windows (which is lately).
<maasha>
For now I am just playing with rbx, but if this turns out well, I might see if I can get my code to work flawlessly under both Ruby implementations.
<maasha>
jruby is a nowgo in my case since I have some critical inline C code - which I believe won't work in jruby.
<maasha>
s/nowgo/nogo
<maasha>
oooh, this seems to be working ok.
<maasha>
so looking at rbx in htop, I see one process with 200-300% CPU and a number of other processes with <100% CPU - what gives?
<chrisseaton>
maasha: Oracle's working to improve the performance of C extensions on JRuby - if you have an application you'd like to try it on ping me
<maasha>
chrisseaton: how baout inline C ?
<maasha>
via the inline gem (which is incredibly useful)
<chrisseaton>
maasha: yeah that's easy - shall we take this to #jruby and I'll explain?
johnmuhl has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
<maasha>
chrisseaton: I appreciated it, but I want to play around with multi threading on multi cores first - then I'll get back to you!?
<headius>
maasha: what is your inline C doing, btw?
<chrisseaton>
maasha: sure - basically we're looking for test cases both for high performance, concurrency, and inline C, so get in touch when you're ready and might be able to work with you
josh-k has quit [Ping timeout: 240 seconds]
<maasha>
headius: low level comparison of bytes using bitwise operators
<maasha>
chrisseaton: great
<headius>
maasha: because that's not fast enough to do in Ruby, presumably
<headius>
you might be able to just write it in Ruby and get better perf on rbx or jruby
<headius>
if you're crossing that boundary between Ruby and C for bitwise byte operations...you're burning a lot of cycles
<maasha>
headius: the inline C code is extremely efficient speeding up vanilla Ruby 100-folds for what I use it for.
<headius>
rbx and jruby are often extremely efficient speeding up vanilla Ruby 100-fold
<headius>
for certain types of operations
<maasha>
headius: sure.
<headius>
I'm just wondering if you're losing perf because there's a bit more overhead for C exts on rbx
meh` has joined #rubinius
<maasha>
I need to run some profiling.
<headius>
yes, that will be interesting to see
benlovell has quit [Ping timeout: 245 seconds]
benlovell has joined #rubinius
josh-k has joined #rubinius
rafacv has joined #rubinius
rafacv has left #rubinius [#rubinius]
josh-k_ has joined #rubinius
maasha has quit [Ping timeout: 246 seconds]
josh-k has quit [Ping timeout: 245 seconds]
josh-k has joined #rubinius
josh-k_ has quit [Ping timeout: 252 seconds]
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #rubinius
josh-k has quit [Remote host closed the connection]
|jemc| has quit [Ping timeout: 255 seconds]
jc00ke has joined #rubinius
Bish has joined #rubinius
<Bish>
hello, i love rubinius.
<headius>
what an entrance
<Bish>
:)
<Bish>
i don't have Rubinius::Debugger or Rubinius::Profiler, only thing i am wondering about
mjc__ has joined #rubinius
mjc__ is now known as mjc_
havenwood has joined #rubinius
|jemc| has joined #rubinius
<|jemc|>
Bish: require 'rubinius/profiler'
<|jemc|>
Bish: require 'rubinius/debugger'
<Bish>
thank you
<|jemc|>
(I was just noticing the other day that the examples showing the profiler don't mention that)
<Bish>
i was expecting that, but i was also wondering why they didnt' mention
<Bish>
ofc i could've watched in /usr/lib64/rubinius/... because it is epic :3
<headius>
I knew there was a reason people like Rubinius!
<Bish>
looked at :(
<Bish>
in*
<Bish>
whatever
<Bish>
is the profiler thread safe?
<Bish>
doesn't look like it
<|jemc|>
Bish: I don't know much about the inner workings of the rbx profiler but I do know that to get a meaningful answer to that question about anything, you need to be more specific about what thread safe means to you in this context
<|jemc|>
that is, asking about what operations you want to perform concurrently
<Bish>
im trying to do Thread.new do profiler = Rubinius::Profiler...::etc; profiler.start; sleep 10; profiler.stop; profiler.show
<Bish>
that leads to rbx segfault on my machine
<Bish>
im locking a hash map with Mutex.new
<headius>
doesn't seem to crash here
<headius>
oh wait...I'm not calling profiler right
<headius>
yeah worked ok here: 100.00 10.00 10.00 1 10000.19 10000.19 Kernel#sleep
<Bish>
well, use it with some threads doing something maybe
<Bish>
could be the mutex or whatever
<Bish>
how can i iterate over Rubinius::Config so i can see all the fun stuff hidden there?
<Bish>
since -Xprofile actually does the trick
<headius>
segfault if I do your code above in 100 threads at once
<headius>
no error info either... just "Segmentation fault: 11"
<headius>
ahh, that time I got a dump...crashing in gc
<headius>
again, this time crashing in JIT, I think?
<Bish>
i didn't look at the backtrace.. i just saw "pthread" at the top
<Bish>
ls
<Bish>
always crashes inside GCfr me
<headius>
bummer
<headius>
probably should put it in an issue
<headius>
(I'm not a Rubinius guy)
<Bish>
:( never did that before could do it tho
<|jemc|>
Bish: don't be intimidated about filing an issue - just be sure you're explicit and clear. Usually people want to see example program input and output, so give some minimal code to reproduce and then an example crash output
flavio has quit [Quit: WeeChat 0.4.1]
<Bish>
does it help to compile rbx with -g ?
<Bish>
?
<|jemc|>
Bish: I'm not familiar with the '-g' option - where do you see that listed?
amsi has joined #rubinius
<Bish>
i mean when compiling rbx
<Bish>
gcc -g
elia has quit [Quit: Computer has gone to sleep.]
<|jemc|>
ah, you mean for the issue ticket?
<|jemc|>
no, that shouldn't be necessary
<|jemc|>
the rbx crash output should be sufficient
<|jemc|>
although it sounds like the crash is different each time
<|jemc|>
but if you give minimal code to reproduce, a dev with a debugging environment can approach it themselves and poke around
benlovell has quit [Ping timeout: 264 seconds]
havenwood has quit [Remote host closed the connection]
<Bish>
i didn't like the locking performance of MRI that's why i went looking up rubinius, and fell in love with its pure-ruby environment ( except for the vm ofcourse )
jc00ke has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
jc00ke has quit [Ping timeout: 240 seconds]
postmodern has joined #rubinius
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
<yorickpeterse>
I have arrived in Barcelona, and crap the weather is hot
<|jemc|>
sounds about right
havenwood has quit [Ping timeout: 264 seconds]
<yorickpeterse>
at least the hotel wifi isn't that bad
<yorickpeterse>
oh shoot, lightning talks are tomorrow
<yorickpeterse>
that means I have to release Oga 1 day early, noes :<
<yorickpeterse>
also means I have to finish my wobsite article today
jc00ke has joined #rubinius
amsi has quit [Ping timeout: 260 seconds]
havenwood has joined #rubinius
benlovell has joined #rubinius
jc00ke has quit [Ping timeout: 255 seconds]
benlovell has quit [Ping timeout: 246 seconds]
<gtemple>
yorickpeterse: hello
<gtemple>
yorickpeterse: had you ever seen it before?
<headius>
Bish: sounds like good justification to use rbx!
elia has joined #rubinius
<yorickpeterse>
gtemple: No, never seen that before. If you have a way to reproduce it, please file an issue on Github
benlovell has joined #rubinius
<headius>
yorickpeterse: need anything from me wrt oga release/announce?
<headius>
bench numbers on jruby, anything like that
benlovell has quit [Ping timeout: 245 seconds]
<yorickpeterse>
headius: nop, I'll be focusing on that in the coming weeks
<headius>
ok, just let me know
<headius>
hmm
<Bish>
can you tell me when jit will do it's magic?
<Bish>
and does jit "safe" the state, for the next execution of the script
<Bish>
save*
<Bish>
i mean the jit compiler of rubinius ofcourse
<headius>
no
<headius>
it does not
<yorickpeterse>
Bish: No, and no
<Bish>
should it?
<yorickpeterse>
The JIT kicks in after a certain amount of calls, that amount however can be configured and even then there's no absolute guarantee that the JIT kicks in
<yorickpeterse>
The JIT also keeps everything in memory, it doesn't write compiled code to a file
<yorickpeterse>
There aren't any facilities in place at the moment to perform ahead-of-time compiltation (or otherwise force the JIT to run on some code)
<Bish>
i am wondering, because i wrote something, which creates a huge hashmap.. and the MRI VM started with 10% cpu, and in one day was @ 50 % cpu ( because the hashmap grew )
<Bish>
when using rbx.. it starts of with 15%... and after 1 day.. it has 9% :D
<Bish>
i wonder if that is the jit-magic
<yorickpeterse>
Not sure if that's the JIT, you can run the script using `rbx -Xint` to disable the JIT and see what happens
<Bish>
man i love this VM, i hope i can participate in one way or the other
<Bish>
( i tend to get excited about technology i like )
<headius>
JRuby and Rubinius will spend a lot less time on GC as the process runs
<headius>
MRI's GC times get slower in direct relation to the amount of data in memory
rafacv has left #rubinius [#rubinius]
<yorickpeterse>
I'm off for the night, early morning for me tomorrow, toodles
<headius>
ta ta
febuiles has joined #rubinius
dviola has quit [Remote host closed the connection]
jnh has joined #rubinius
<Bish>
why are there raise calls behind every primitives that feels like they get executed everytime, not just when the primitive fails to initialize itself
<headius>
those methods are replaced with the native primitive they reference
<headius>
if the primitive can't be found it's a bug, so the raise remains in place
<Bish>
i see
elia has quit [Quit: Computer has gone to sleep.]
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 255 seconds]
meh` has quit [Ping timeout: 268 seconds]
kfpratt has joined #rubinius
rmichael has joined #rubinius
carlosgaldino has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
havenwood has quit []
kfpratt has quit [Remote host closed the connection]
kfpratt has joined #rubinius
kfpratt has quit [Remote host closed the connection]