slava_pestov

> I want to write Lisp for Factor.

That would be a cool project. The Factor compiler enforces static stack effects for words, so mapping them to Lisp functions, and making the generated code efficient, should be pretty doable.

Each one is true for at least one of those platforms.

I should say, Unix in this context means any Unix-like system that Factor runs on (Linux, FreeBSD, OpenBSD, Mac OS X)

I don't see what the big deal is. It took me a few hours to update Factor's Twitter library for OAuth -- and that included writing the OAuth support library. The whole thing is only a couple of hundred lines of code.

Factor uses ahead of time compilation. When you load a source file at the REPL, all definitions in it are compiled immediately, and compiled code is saved in the image. So when you download a pre-built binary package, all the code has already been compiled so auto-detection is not an option.

There are pros and cons to both compiling at load time or run time; one of the disadvantages of the former is less flexibility when it comes to using CPU-specific features.

Under what circumstances does Visual C++ still emit x87 instructions? I'd think that other than legacy support, 80-bit long double arithmetic, and the 32-bit ABI (float return values are passed on the x87 stack) there's no reason to use x87.

Unfortunately enough people have older CPUs that we still have to support x87 code generation; its just not used in the binary packages, you have to build the source to get it.

Factor supports machines without SSE2 if you compile it yourself. In this case it will use the x87 floating point. The binaries are built to use SSE2 for floating point since most machines have it these days.

There is SIMD support in the language as well which supports most of SSE4.2, check out http://docs.factorcode.org/content/article-math.vectors.simd...

The JRuby developers have spent a lot of time doing performance measurements, implementing optimizations and trying out different approaches. You're just throwing in your two cents based on second-hand knowledge of an obsolete language implementation...

> Does this mean that simple accessors (or at least getters) effectively have no method call overhead?

Method inlining has nothing to do with escape analysis (other than enabling it in more cases) and in any case getters and setters have had zero overhead since HotSpot was first introduced in Java 1.3.

Actually, once you've figured out that you can stack allocate an object, you can stick its instance variables in registers. This can be a huge win.

There's no theoretical difficulty with compiling tail calls to virtual methods; of course perhaps you meant that the JVM doesn't expose a bytecode for doing so, which is absolutely correct.

tl;dr: No, it has to be built-in to the JVM.

First of all, if a JVM were to attempt this optimization for tail calls using the ordinary method call bytecodes, it would break existing programs that are written to rely on stack frame inspection.

So the only solution is to add a new bytecode for tail calling methods, so that this bytecode can be used from non-Java languages without impacting existing code; however there's no such bytecode yet.

Self-tail calls (where a function calls itself in tail position) can be compiled as a goto, however this is not as general as full tail call elimination (you cannot implement a state machine consisting of several functions this way, for insance).

Also, an arbitrary set of tail-recursive functions can be compiled into something that fakes a call stack using a heap-allocated data structure, with a top-level trampoline that drives an interpreter loop. However this incurs a significant performance penalty, and requires a whole-program transform. When you hear about Scheme implementations on the JVM that implement tail calls and call/cc, they generally use this trick, and as a result as too slow to be useful.

So, right now there's no good solution for tail calls on the JVM, and it would require changes to the JVM to implement in full generality.

So how does Ruby's performance on vector code compare with OpenCL?

Here's a point-free version in Factor. It looks a bit different from the original formula but once you get used to it its very quick to read; I prefer it to the Lisp code since there are fewer parentheses to track:

    : entropy ( n -- e ) [1,b] [ p dup log * ] sigma neg ;

Note that [1,b] is a word which makes a numeric range from an integer on the stack, and [ ... ] is a function object (quotation).