slava_pestov

4 ms·

1.
by slava_pestov 16y ago
> 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.
2.
by slava_pestov 16y ago
Each one is true for at least one of those platforms.
3.
by slava_pestov 16y ago
I should say, Unix in this context means any Unix-like system that Factor runs on (Linux, FreeBSD, OpenBSD, Mac OS X)
4.
by slava_pestov 16y ago
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.
5.
by slava_pestov 16y ago
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 alrea
6.
by slava_pestov 16y ago
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
7.
by slava_pestov 16y ago
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.
8.
by slava_pestov 16y ago
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 la
9.
by slava_pestov 17y ago
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 impl
10.
by slava_pestov 17y ago
> 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 hav
11.
by slava_pestov 17y ago
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.
12.
by slava_pestov 17y ago
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.
13.
by slava_pestov 17y ago
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 inspecti
14.
by slava_pestov 17y ago
http://en.wikipedia.org/wiki/Intel_80186
15.
by slava_pestov 17y ago
So how does Ruby's performance on vector code compare with OpenCL?
16.
by slava_pestov 17y ago
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
17.
Factor FAQ(useless-factor.blogspot.com)
1 points by slava_pestov 19y ago|0 comments