Hacker News Reader

Comment by guenthert | Hacker News Reader

So far I have little experience with Julia, but it looks to me very promising. Personally, I like a more settled environment and prefer languages defined by a standard, not by a single implementation.

"Infact, the first version of my most recent project saw an order of magnitude difference when ported from Common Lisp to Julia, without any effort or attention to optimization techniques."

That might have been the case, but one mustn't expect that generally to be so, see e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which shows much closer results (and multiple attempts for either language for any given benchmark to get better results).

Seems that Julia struggles with the binary-tree benchmark. Then again, run-time performance is for many (and over time, more and more) applications not the most relevant criteria (otherwise Python wouldn't be so successful).

View on HN

That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true. Non-GC languages are allowed to pre-allocated a memory arena, GC languages are not. For the naive implementation, Julia beats Rust in this benchmark.

> That benchmark in particular has different rules for GC languages vs non-GC languages. Absurd, but true.

Fair to point out, but since that benchmark is "A simplistic adaptation of Hans Boehm's GCBench", those rules are perhaps not quite so absurd. It also doesn't explain why Julia should be so much slower than Java or SBCL. I rather expect Julia to do better here in the future.

Yeah. The problem here is that Julia gives you a bunch of tools to avoid GC by aggressively stack allocating or preallocating so our GC algorithm is pretty meh. We're about to merge a parallel algorithm, and are looking into switching to MMTK, but if anyone from the Java/lisp/Go world wants to help us out, we would love people who can help improve our GC. There are a few things Julia does that makes it a bit harder (the stack allocation+LLVM makes getting roots a little more complicated, and we make it easy for C to take Julia memory so we can't do a compacting collector).

My personal experience tinkering with Lisp is that it can sometimes be very hard to actually achieve the legendary high performance of SBCL, without your code getting verbose and ugly. Yes, you could ostensibly wrap that ugliness up in macros, but then you're inventing your own DSL and a compiler in the macro engine, which I guess is what the true Lisp nerds live for, but I have too few brain cells and too little time/energy to shave such big yaks.

>languages defined by a standard, not by a single implementation.

any of the IronPython, Cython, Jython worked well enough to be continued and works well with the rich CPython ecosystem 100%?

For one thing, Cython isn't a Python implementation.

As for the rest, of course not. Especially not those two in particular. But PyPy and Pyston are doing pretty well on compatibility. Not sure about Stackless, but I think it's mostly been subsumed by PyPy anyway (even though it's still being developed independently).

The main problem for alternative implementations of Python is the C extensions, much like with Ruby. But the Python community has started to take ownership of the problem and a new C interface is being developed, called HPy, that is easier to implement for non-CPython implementations, and library developers are taking an interest in targeting HPy instead of the traditional CPython interface. With that in place, Python will be in a pretty good place when it comes to standardization.

Reply on news.ycombinator.com