josh-k has joined #rubinius
diegovio1 has joined #rubinius
diegoviola has quit [Ping timeout: 258 seconds]
diegovio1 is now known as diegoviola
|jemc| has joined #rubinius
havenwood has quit []
amsi has quit [Quit: Leaving]
meh` has quit [Ping timeout: 245 seconds]
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Ping timeout: 272 seconds]
diegoviola has quit [Ping timeout: 255 seconds]
diegoviola has joined #rubinius
olanmatt has joined #rubinius
olanmatt has left #rubinius [#rubinius]
josh-k has joined #rubinius
postmodern has quit [Remote host closed the connection]
GitHub153 has joined #rubinius
<GitHub153> [rubinius] brixen pushed 2 new commits to master: http://git.io/ZJDt9g
<GitHub153> rubinius/master 93ad8c5 Brian Shirai: Added Ruby backtraces to segv handler.
<GitHub153> rubinius/master 31c1d67 Brian Shirai: Added configuration for FS-API dir/files.
GitHub153 has left #rubinius [#rubinius]
<brixen> yorickpeterse: now with 100% more Ruby backtraces in your segv logs
<brixen> yorickpeterse: and you can configure your console files to your heart's content
<brixen> console file access*
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (31c1d67 - Brian Shirai): The build has errored.
travis-ci has left #rubinius [#rubinius]
<|jemc|> brixen: now I'm trying to think of the best way to segfault it to see :P
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Read error: Connection reset by peer]
dimday has joined #rubinius
dimday has quit [Ping timeout: 272 seconds]
<|jemc|> yep, there is is; ruby backtrace
josh-k has joined #rubinius
dimday has joined #rubinius
diegovio1 has joined #rubinius
diegoviola has quit [Ping timeout: 240 seconds]
pwh has quit []
Zaeleus has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Read error: Connection reset by peer]
dimday has quit [Quit: Leaving.]
diegovio1 has quit [Remote host closed the connection]
CodeGnome has joined #rubinius
CodeGnome has left #rubinius ["QUIT :Leaving."]
CodeGnome has quit [Remote host closed the connection]
|jemc| has quit [Ping timeout: 240 seconds]
heftig has quit [Read error: Connection reset by peer]
max96at|off is now known as max96at
<cremes> what’s a practical way to get access to the stats/metrics? i have some code that i ran with these options:
<cremes> -Xsystem.log.level=debug -Xsystem.metrics.target=disk
<cremes> however, the file at /tmp/rbx.log remains empty. what am i missing here?
max96at is now known as max96at|off
max96at|off is now known as max96at
heftig has joined #rubinius
<yorickpeterse> brixen: I'll give it a shot this monday
josh-k has joined #rubinius
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #rubinius
meh` has joined #rubinius
havenwood has joined #rubinius
<cremes> hmmm, finally got some output. can’t really make head or tails of it though. see this gist: https://gist.github.com/chuckremes/75a4cc44d629e985cceb
<cremes> the script doesn’t print any errors… this output comes from setting the level to “debug”. is this a real error that should be reported?
max96at is now known as max96at|off
DanielVartanov_ has joined #rubinius
DanielVartanov_ has quit [Remote host closed the connection]
pwh has joined #rubinius
Zaeleus has quit [Quit: Leaving...]
josh-k has quit [Remote host closed the connection]
pwh has quit []
pwh has joined #rubinius
<brixen> cremes: statsd is the only emitter right now
<brixen> and metrics is completely independent of the logger
<brixen> for that llvm error, do you know what version of llvm you're using?
<brixen> rbx -v will now tell you
<brixen> cremes: also rbx -e 'p Rubinius::Metrics.data.keys'
yxhuvud has quit [Remote host closed the connection]
pwh has quit []
yxhuvud has joined #rubinius
yxhuvud has quit [Remote host closed the connection]
max96at|off is now known as max96at
whatasunnyday has joined #rubinius
RageLtMan has joined #rubinius
whatasunnyday has quit [Quit: whatasunnyday]
pwh has joined #rubinius
<cremes> brixen: hmmm, rbx -v: rubinius 2.2.10.n291 (2.1.0 31c1d67f 2014-10-18 3.2svn JI) [x86_64-darwin13.4.0]
<cremes> maybe llvm 3.2 based on that string? i always use a prebuilt so i’ll use whatever rbx has been “shipping"
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
yxhuvud has joined #rubinius
pwh has quit []
pwh has joined #rubinius
pwh has quit []
pwh has joined #rubinius
whatasunnyday has joined #rubinius
postmodern has joined #rubinius
elia has joined #rubinius
josh-k has joined #rubinius
<yorickpeterse> brixen: so why is Rbx not as fast as C? :P
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
<yorickpeterse> (https://github.com/rubinius/rubinius/issues/3165 for the curious)
<yorickpeterse> Also I don't get why people think it's spelled "Rubinious"
<yorickpeterse> I've seen that a few times now
<cremes> ugh, i held back from responding because the ruby-talk guy is clearly a newb
<cremes> i’m going to ask him why MRI isn’t as fast as C even though it can be compiled by LLVM just like rust.
<yorickpeterse> ruby-talk?
<yorickpeterse> (unsubscribed from that a while ago, way too much noise)
<yorickpeterse> Also I really don't get this fetish people have with "C like performance"
<yorickpeterse> there are maybe 5 companies in the world that actually care about that, and none of those are using Ruby (any more)
<yorickpeterse> (Twitter, Google, Facebook, your-average-bank, your-average-telecom-provider, etc)
<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
GitHub55 has left #rubinius [#rubinius]
<GitHub55> rubinius/alloc-trace 613ca11 Yorick Peterse: Added experimental allocation tracer....
<yorickpeterse> hm, apparently I hadn't pushed that yet
elia has joined #rubinius
elia has quit [Client Quit]
pwh has quit []
<yorickpeterse> riiiiiight
<yorickpeterse> so my allocation tracer works fine as long as it doesn't reference the object passed to it
<yorickpeterse> the moment you do that at some point it crashes
<yorickpeterse> hm, seems that the GC is spoiling things
max96at is now known as max96at|off
byprdct_ has joined #rubinius