<yorickpeterse>
oh fuck, anything better than existing machine learning tools
<yorickpeterse>
Machine learning is such a PITA from what I've seen co-workers deal with
benlovell has joined #rubinius
|jemc| has joined #rubinius
josh-k has quit [Remote host closed the connection]
Guest19_ has quit [Read error: Connection reset by peer]
Guest19 has joined #rubinius
josh-k_ has joined #rubinius
<yorickpeterse>
brixen: so other question, when profiling performance with Ruby, where do you usually start?
<yorickpeterse>
This is my scenario: Oga uses Racc and Ragel, Racc is slow as shit and I fucked up performance in my lexer somewhere
<brixen>
at the beginning :)
<yorickpeterse>
Now I sort of know where the problem is (= racc) but I need numbers first to prove it
<yorickpeterse>
Ruby profilers suck, because it takes 10 years for Ruby to even start when they're running
<yorickpeterse>
Same goes for Valgrind, though I at least finally have some data from it
benlovell has quit [Ping timeout: 264 seconds]
<yorickpeterse>
So I hacked together some call counter in Systemtap, but I can't get it to properly profile timings using it
<yorickpeterse>
(only call amounts)
mamantoha has quit [Ping timeout: 264 seconds]
<brixen>
it's a big problem for sure
<yorickpeterse>
The most painful way is to read all the code, then theorize about every line
<yorickpeterse>
but then I'll still be profiling next year
<brixen>
hah, indeed
<brixen>
one thing you may try is isolating the parts
<brixen>
try measuring smaller things
<brixen>
if you then sum them and it doesn't add up to the global behavior, you're missing something
<yorickpeterse>
That was going to be my step 2, step 1 would be to get some kind of direction
<brixen>
but the global system will have confounding effects, so you could chase your tail for a long time
<yorickpeterse>
so .e.g I tried oprofile to get some idea, but it just shows a bunch of random Ruby C functions (e.g. rb_ary_push, st_lookup, etc)
<brixen>
all you need is a single number for the global system
<yorickpeterse>
(at least on MRI)
<brixen>
get a total time on some reasonable workload
<brixen>
then try to decompose that and measure each system
<brixen>
sum for a sanity check
<brixen>
then look at percentages of the parts
tenderlove has quit [Quit: Leaving...]
<brixen>
gotta run for a bit
<yorickpeterse>
hmm
amsi has joined #rubinius
yxhuvud has quit [Remote host closed the connection]
yxhuvud has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
tmornini has joined #rubinius
tmornini has quit [Client Quit]
tmornini has joined #rubinius
noop has quit [Ping timeout: 264 seconds]
tmornini has quit [Ping timeout: 246 seconds]
Guest19 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
havenwood has joined #rubinius
havenwood has quit [Remote host closed the connection]
Guest19 has joined #rubinius
<Guest19>
brixen I've been reading C++ code for the StatsD emitter
havenwood has joined #rubinius
Guest19 is now known as goyox86
<goyox86>
You plan to add a JSON emitter?
<goyox86>
Which other emitter will you plan to support
<goyox86>
?
<goyox86>
Forget the part of JSON emitter ;)
<goyox86>
OFF TOPICI'm playing with influxdb looks secsy.
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mamantoha has joined #rubinius
josh-k_ has quit [Remote host closed the connection]
josh-k has joined #rubinius
mamantoha has quit [Ping timeout: 255 seconds]
josh-k has quit [Ping timeout: 258 seconds]
havenwood has quit [Remote host closed the connection]
[spoiler] has joined #rubinius
havenwood has joined #rubinius
josh-k has joined #rubinius
mrb_bk has quit [Ping timeout: 245 seconds]
yipstar has joined #rubinius
mrb_bk has joined #rubinius
heroux has quit [Ping timeout: 240 seconds]
heroux has joined #rubinius
<yorickpeterse>
yay valgrind says rb_ary_entry takes up 4.15% of the total runtime of this benchmark
<yorickpeterse>
that really helps me
<yorickpeterse>
because that function is used literally everywhere
Guest19 has joined #rubinius
<yxhuvud>
yorick: have you tried playing around with different views of the profiling? sometimes flame graphs are wonderful, sometimes they don't help at all, etc. (you can tell valgrind to output data kcachegrind can read, if you havn't got that far)
<yorickpeterse>
oh I have a tool for reading callgrind output
<yorickpeterse>
which funny enough is called qcachegrind
diegoviola has joined #rubinius
postmodern has joined #rubinius
<Guest19>
yorickpeterse: Have used qcachegring #notbad
Guest19 is now known as goyox86
<goyox86>
Man this IRC client is driving me crazy
<yorickpeterse>
#aha
<yorickpeterse>
:P
<yorickpeterse>
Hm, flamegraphs might be an option
<yorickpeterse>
never used them before, lets see
[spoiler] has quit [Read error: Connection reset by peer]
<yxhuvud>
their usefulness depend a lot on the program usage structure though.
havenwood has quit [Remote host closed the connection]
digitalextremist has joined #rubinius
digitalextremist has quit [Quit: demonstrate freedom //]
max96at is now known as max96at|off
havenwood has joined #rubinius
<yorickpeterse>
hmpf, getting callstacks out using systemtap in userspace is not as convenient as hoped
carlosgaldino has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
cypher23 has quit [Ping timeout: 255 seconds]
cypher23 has joined #rubinius
havenwood has quit [Remote host closed the connection]
yipstar` has joined #rubinius
yipstar`` has joined #rubinius
yipstar has quit [Ping timeout: 264 seconds]
yipstar` has quit [Ping timeout: 244 seconds]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]