<cremes>
yorickpeterse: yeah, no one cares about C-like perf. that’s why oga has a C extension. :P
<yorickpeterse>
That wasn't to make it C-like, that was to not make it suck arse
<yorickpeterse>
(yes I got that was a joke :P)
<cremes>
ha
<yorickpeterse>
I should probably use LLVM, because Rust uses LLVM too
<cremes>
i wish ruby had C-like performance. i wouldn’t ever have to apologize for using it then.
<yorickpeterse>
That brings me to the point: does that matter?
<yorickpeterse>
e.g. we do web scraping, sentiment analysis, etc, etc, I couldn't care less if that performed at C levels
<yorickpeterse>
even if IO wasn't a big factor
<cremes>
in the real world, yeah, it matters. i don’t do web shit. i solve other problems that are not IO-bound.
<yorickpeterse>
if you're doing something like real time communications (e.g. telecoms) then yes, but most Ruby users dont
<yorickpeterse>
It would be nice, but I don't get the fetish people have with it
<cremes>
yorickpeterse: what’s the main complaint people have about ruby? syntax? no. learning curve? no. performance? yes.
<yorickpeterse>
I agree it would be nice if Ruby was the "one language to rule them all", but that is rather unrealistic
<yorickpeterse>
cremes: that's the point, I don't see _why_ they have a problem with it. 9 out of 10 people that complain about that have some dumb Rails app
<yorickpeterse>
that one person who doesn't has a valid point, but is probably capable of phrasing it better than just "omg y u no C performance"
<yorickpeterse>
With the Rbx bytecode stuff brixen is hacking on, and the changes to the JIT, and everything else, we'll soon have better perf no doubt
<yorickpeterse>
but with less than 5 main contributors, it will take time
elia has quit [Quit: Computer has gone to sleep.]
<cremes>
yorickpeterse: regarding rails, they absolutely *can* and *should* complain about page rendering that takes as long as it does in ruby.
<cremes>
rbx is clearly slower in dev mode and in many cases probably slower in prod mode too
<cremes>
it’s nice to say it’s all about IO, but in the real world even our computation-intensive ops are slow in ruby.
<cremes>
mri and jruby have made some nice strides in this area. i upgraded to mri 2.1.3 on windows and it is fucking *fast*. at least 2x faster than 2.0.x was.
<yorickpeterse>
There's a difference between "good performance" and "omg C performance"
<yorickpeterse>
I agree that especially for Rails we have a lot of work to do
<cremes>
with a smart JIT, profiling and other intelligence, why can’t ruby be “omg C fast"?
<yorickpeterse>
but in between Rails being massive and people rarely providing good info, it's hard :/
<yorickpeterse>
cremes: because that takes years of work
elia has joined #rubinius
<yorickpeterse>
and highly depends on the implementation details
<cremes>
i know it’s hard. i’ve been a huge booster of this proj for years and have contributed code and help over that same timeframe.
<yorickpeterse>
A JIT isn't some silver bullet that magically makes things as fast as x86-64
<yorickpeterse>
* assembly
<cremes>
i know.
<cremes>
there are no silver bullets
<yorickpeterse>
Right now, as far as I can tell, there are two main issues:
<cremes>
but it could be better
<yorickpeterse>
1) the JIT is, well, not as good as it should be
<cremes>
and we have the promise of better. i think brixen’s ideas will lead this project to that “better"
<yorickpeterse>
2) the kernel code isn't as optimized as it should be
<cremes>
and stdlib is shit.
<yorickpeterse>
I'm pretty sure that if we had even 5 paid contributors we'd get there within 6 months
<cremes>
holy crap, i don’t know about that. when engine yard supported this proj, it went nowhere fast. i think vision is more important than paid contributors.
<cremes>
i think brixen has learned from those old mistakes. deliver what people want and need. do it iteratively and do it fast.
<cremes>
we really need a “guy kawasaki” for this project (he was the first apple “evangelist” for the Mac way back when)
<yorickpeterse>
cremes: Engine Yard didn't really sponsor it as actively as they probably should've
<yorickpeterse>
Talked about this with brixen, not sure up to what point I can share that
<cremes>
you and i probably have mostly the same info
<yorickpeterse>
secret rbx club
<cremes>
regardless, there *were* paid contributors but they were dancing to the wrong tune (this being 20/20 hindsight)
<yorickpeterse>
Not sure, wasn't around in 2010/2011
<yorickpeterse>
(when there were still 5 or so)
<cremes>
i don’t recall there ever being more than 2 or 3 paid contributors at any point in time, but i could be mistaken.
<yorickpeterse>
Hopefully in a few months I can more or less get myself a foot in the door more actively, as by then we should at least have part of our infrastructure on Rbx
<yorickpeterse>
That is, once I fix the aws-sdk and replace nokogiri in our stack
<cremes>
that would be wonderful
<cremes>
we need people who actually *fucking use thsi thing* to be active contributors
<cremes>
fix what hurts
<cremes>
add things that make it *better*
<cremes>
wash * rinse * repeat
<yorickpeterse>
Granted most of my stuff is background processing, I care more about IO than CPU timings
<yorickpeterse>
I'd probably focus more on making things not crash
<yorickpeterse>
since I can just spin up more threads to solve the perf problem :P
<yorickpeterse>
don't see myself actually being paid to work on Rbx any time soon though, current employer doesn't really have the room for that
<yorickpeterse>
That is, my contract stating something semi official. Of course I can say "I'm fixing this because it affects us"
<cremes>
unfortunate, but hardly a show stopper
* yorickpeterse
still wants to change his title from "developer" to "senior yak shaver"
<cremes>
you have been a huge boon to this community. i, for one, am very glad you joined us. thank you for your work and your energy.
<yxhuvud>
yorick: fwiw, we run some of the parts of your-average-telecom-provider stuff in lua. luajit is damned fast if you know how not to write code.
<yorickpeterse>
I mostly dick around on the issue tracker :P
<yorickpeterse>
yxhuvud: oh yeah, I've looked into LuaJIT over time
<yorickpeterse>
Bit of a bummer Lua arrays start at 1, and that there's no built-in concurrency support
<yorickpeterse>
Though not surprising given it's nature
<cremes>
i hate to say it, but part of the problem with contributing to rbx has been that too many performance-sensitive parts are in C++.
<yxhuvud>
well, it does have corutines, and it isn't that hard to set up one lua process per processor. Life if simple when there are no real state to keep track of :)
<cremes>
if we could make the ruby parts faster, and move more into ruby, i think contributions would be… more likely
<cremes>
life intrudes. gotta walk the dog(s).
<yorickpeterse>
cremes: True, the solution to that is to move things to Ruby more
<yorickpeterse>
another problem is exposure, we're simply not well known enough
elia has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
I think an interesting next step for Rubinius could be to write a JIT in Ruby - surely the LLVM-based JIT is the most opaque part at the moment?
<yorickpeterse>
chrisseaton: brixen is exposing parts of the JIT to Ruby
<yorickpeterse>
Not sure up to what extend though
GitHub55 has joined #rubinius
<GitHub55>
[rubinius] YorickPeterse created alloc-trace (+1 new commit): http://git.io/wlgnoA