RPython's JITs however, are tracing jits. They trace from the start, to the end of a loop, and inline all methods along the way, then remove all conditional jumps (replacing them with guards), then remove all unneeded mallocs, and then optimizes everything else it can. The end result is a trace that is highly optimized for that one path through the code. Thus, if your code is highly polymorphic, but only ever uses a certain path through the code, RPython jits can out-perform C++ in some rare cases, and can probably outperform most custom jits in many cases.
Some links to read:
http://en.wikipedia.org/wiki/Tracing_just-in-time_compilatio...
http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a...
Doesn't that depend on the kind of research that is being pursued? If the research is about high-level, productive language features, performance is going to be a secondary concern at best. If the research is about a language being able to prove properties about programs - including low-level stuff like memory safety, not just high-level semantic properties - then the language might very well accommodate efficient implementations.
My main point though was that part of Julia's high performance is due to specific decisions by the language designers (e.g. the compiler knows a lot of information about types even though the programmer can mostly ignore them), while a language like Python wasn't designed for performance and is thus harder to optimize.
Or if the research is about speeding up language implementations: http://en.wikipedia.org/wiki/Self_(programming_language)