91–100 of 190 posts
Earlier quoted context omitted.
we removed that from the docs, it's kinda stable by now (but it's still an atrocious language to use, just beats C/C++ for that particular task by a lot)
Out of curiosity, whats so atrocious about it? The slow translation step or language idiosyncrasies?
Topaz as a name? Seriously? ( http://topaz.sourceforge.net/ )
I find it odd that you link to a project that hasn't seen an update in the last 12 years. How old does a project have to be before it is considered "dead"?
It would be nice to see Rpython/pypy turned into a project not unlike WebKit where many different projects benefit from the same open-source core. If pypy is flexible enough to implement all of ruby and all of Python, has a reasonable amount of maturity, and is already rather fast it seems like a good candidate for such a thing.
Earlier quoted context omitted.
That's probably not a fair test to use on JRuby, as the JVM is notoriously slow to start.
That doesn't make it unfair to JRuby, it just means JRuby will probably lose that benchmark. :)
Topaz as a name? Seriously? ( http://topaz.sourceforge.net/ )
The fact that it used the name "Topaz" should have absolutely no bearing on any current project.
Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s
Whenever I see frontpages for these kinds of projects like "a faster X" or "X written in Blub", the first thing I want to see on the frontpage is how this new project compares to X in terms of quality and performance. Even specious benchmarks would help more than zero benchmarks. I wish more frontpages for these kinds of projects would do that.
Earlier quoted context omitted.
That doesn't make it unfair to JRuby, it just means JRuby will probably lose that benchmark. :)
If the goal is to benchmark Ruby execution time, it's unfair. The slow startup time is a valid concern when considering short-lived sessions, but it's kind of meaningless when trying to benchmark a Ruby implementation.
In general a benchmark is probably the worst metric you could ever use for deciding on an implementation. Unless the profit margin of your business is razor thin and dependant eeking out every last drop of performance, and even then most of those gains will be from extremely small sections of code that are probably best written in assembler by a programming God, and you should investigate FPGAs, ASICs, and other high performance solutions.
If your benchmark (infrastructure) involves a database (or anything that uses disks) that's probably going to be the problem long before the speed of your language / language implementation.
Earlier quoted context omitted.
"Topaz is written in Python on top of the RPython translation toolchain (the same one that powers PyPy)." [1] "Topaz - An implementation of the Ruby programming language, in Python, using the RPython VM toolchain." [2] [1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/ [2] https://github.com/topazproject/topaz/blob/master/README.rst
As RPython is a subset of Python, that statement is technically correct but misleading. Stating that Topaz is "Ruby written in Python" leads to the idea that it's written in / runs on CPython , which is really not the case.
Earlier quoted context omitted.
Do you know what an analogy is?
I'm actually not a native speaker, so indeed, I might not know. I checked in the dictionary though. This is an analogy, but not a very good analogy, because of the reasons that I pointed out. Are you disagreeing with any particular reasoning there? Or should I just say "they're similary, but"?
In much the same way, comparing "Apple writing a C interpreter on top of llvm" to "Alex Gaynor writing a Ruby interpreter on top of RPython" makes a very good analogy, even though Apple is not much like Alex Gaynor, Ruby is not much like C, and PyPy is not much like LLVM.
Earlier quoted context omitted.
That's probably not a fair test to use on JRuby, as the JVM is notoriously slow to start.
That doesn't make it unfair to JRuby, it just means JRuby will probably lose that benchmark. :)