evanphx

9 ms·

61.
by evanphx 15y ago
But that is by definition a tractable problem because the source will show that the root set isn't being used properly. (additionally, in practice this proves to be a rare and easy to fix bug)
62.
by evanphx 15y ago
Neither Rubinius nor JRuby (and probably IronRuby too) have this issue because they all use accurate garbage collection rather than conservative. Accurate requires much more bookkeeping since all pointers must always be properly identified,
63.
by evanphx 15y ago
The MRI C extension API compatibility is very much an official feature. Except for a few gems we can't make work (because they tie directly into 1.8's execution model) most work fine. If you have one that doesn't work, please just open an i
64.
by evanphx 15y ago
Rubinius uses the exact same technique as is detailed here, namely backing an Array with a Hash (LookupTable in the Rubinius case). We added this a few years ago to speed up require.
65.
by evanphx 16y ago
Looking at the bytecode, the JIT handles it fine. atomo pattern matching is the equivalent of using a case;when in the body. And because it's scoped to a certain class and name, I doubt it would have the overflow problem that lisp multimeth
66.
by evanphx 16y ago
For the time being, we use a lock that has to be held to run methods defined in C extensions, a GEL (Global Extension Lock) if you will. We've got some other ideas to increase concurrency in extensions, but the crux is that yes, we have to
67.
by evanphx 16y ago
Rubinius can run pure ruby code much faster than YARV because of things like a better GC and the ability to compile ruby code down to machine code (a JIT compiler). Rubinius is much easier to work and understand than YARV because much of th
68.
by evanphx 16y ago
1.9 is next big feature being worked on. The multiverse branch has the start of it, and speed is going to pick up on it in the new year.
69.
by evanphx 16y ago
This actually puts out a mildly confusing picture. Rubinius uses LLVM to implement the JIT compiler only. LLVM does not provide a performant interpreter, and even if it did, the instructions in LLVM are incredibly lowlevel which would mean
70.
by evanphx 16y ago
The website was updated when 1.1 was announced yesterday. You must be seeing a cached page.
71.
by evanphx 16y ago
Concurrent GC is not currently planned, but it should be noted that our generational GC does wonders to reduce GC pause time anyway. Additionally, even Hotspot typically defaults to their stop-the-world GC. This is because a concurrent GC t
72.
by evanphx 16y ago
Rubinius wise, I'm actively working on making in concurrent. Yes, a future release will incorporate that work, which allows one Rubinius process to fully use as many cores as a machine has.
73.
by evanphx 16y ago
The linux kernel will schedule the new process on whatever core it wants. Forked process in ruby have posix semantics, ie, NOT shared memory. Linux uses Copy-On-Write pages to conserve the amount of memory copying when the new process is cr
74.
by evanphx 16y ago
We already done that, optimize out certain things into primitives, which are implemented in C++. We support as subset of the MRI extension API, mainly we don't support anything using RBASIC(), RHASH(), or RREGXP() because those expose raw C
75.
by evanphx 16y ago
Well, not exactly. The interpreter is in C++. By bytecode compiler he means the code that translates from a ruby AST into bytecode, which is in ruby.
76.
by evanphx 16y ago
I think now that we've hit 1.0, the path forward is easy to break up into bits could be on the blog. Before the 1.0-rc cycle, it was hard to separate out individual things. Given that people think this is a good idea, I think we'll go ahead
77.
by evanphx 16y ago
Those are done by hand.
78.
by evanphx 16y ago
We have a mailing list at http://groups.google.com/group/rubinius-dev , though it hasn't taken off much yet. Perhaps now that 1.0 is out people will use it more. Blog wise, what would you like to see on a Rubinius blog?
79.
by evanphx 16y ago
This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MR
80.
by evanphx 17y ago
There was a snafu (my fault) with the blog, should be up now. Sorry!
81.
by evanphx 17y ago
I (Evan Phoenix, author of the the article and project lead) talk with the Unladen Swallow guys almost daily. We've met up in person a number of times and have traded a lot of ideas, so I'm 5 steps ahead of you!