sabauma

7 ms·

1.
by sabauma 5y ago
The cost for the connect plans is what confuses me. For what you get, $5-$8 per month seems oddly expensive. I don't really use any of the features in the full connect plan. The cloud syncing is convenient, and I'd be willing to t
2.
by sabauma 5y ago
I've replaced my Kindle with a Remarkable 2 and am generally pleased with the overall experience. The larger screen is nice, as is the ability to read/annotate academic papers on the same device. There are a bunch of little things
3.
by sabauma 5y ago
I find rmapi + fzf to be the easiest way to send ebooks in my Calibre library to my rM2. Its probably possible to create a Calibre addon to do this, but its already makes syncing pretty easy.
4.
by sabauma 8y ago
This is indeed a consequence of tracing. The problem is that traces are associated to loops in the program, and since the map function contains only one loop, all traces for map are associated to the loop in its implementation. When you man
5.
by sabauma 8y ago
I haven't checked in on the development of Pycket in a bit, but much of the recent work has gone into supporting linklets. Last I checked, the performance story for the Scheme and Shootout benchmarks used in the paper haven't chan
6.
by sabauma 9y ago
There has been some discussion of Meltdown and Spectre on the Mill forums: https://millcomputing.com/topic/meltdown-and-spectre/
7.
by sabauma 9y ago
The REPL essentially operates at the global scope, which is represented as a dictionary. Variables local to a function are not stored in a dictionary, however: def main(): a = 1 d = locals() print d d[&
8.
by sabauma 10y ago
Chez is an AOT compiler. I am not sure how the REPL operates, but I believe it just compiles expression on the fly before executing them. I suppose you could characterize that as JIT compilation, but the optimizer does not make use of any r
9.
by sabauma 10y ago
Chez is pretty tough to compete with in terms of Scheme performance. On the benchmarks presented in the paper, Chez averages faster than all the systems presented, even Pycket post warmup. Its not the fastest on every benchmark, but gives c
10.
by sabauma 10y ago
You can find simple decorators which try to provide space efficient tail recursion. Usually they work by trampolining the function. I've seen one example where a decorator rewrites the bytecodes to perform a goto in the case of self re
11.
by sabauma 10y ago
That depends on how you run Pixie. There are 2 possible cases. 1. Run Pixie atop the Python VM: this is quite slow as there are 2 levels of interpretation. This is mostly used for testing. 2. As a standalone binary: The RPython language inc
12.
by sabauma 10y ago
> The thing is, tail calls aren't _just_ about emulating iteration via recursion: I completely agree, but there is also no need to perform TCO to make code like this safely runnable. TCO only becomes necessary/useful when imple
13.
by sabauma 10y ago
Probably because many tail-recursive functions _rely_ on tail-call elimination working reliably. Without also having an unbounded call stack, disabling tail-call elimination will likely just cause your programs to crash.
14.
by sabauma 10y ago
The notion that not having proper tail calls aids debugging always seemed like a post-hoc justification. The stack trace of an iterative function will lack exactly the same intermediate evaluation frames as a tail-recursive implementation.
15.
by sabauma 10y ago
It would be interesting to see how well PyPy optimizes the code generated by the Phorth compiler, but it looks like this needs some hacks via the CPython C API to work. Even if it could be made to work, I doubt the PyPy JIT would like some
16.
by sabauma 10y ago
While Pixie is implemented in RPython, Pixie code does not run on the Python VM. You can run the Pixie _interpreter_ in the Python VM, since it is valid Python code, but that is markedly different than compiling a language to Python bytecod
17.
by sabauma 10y ago
Much of the data in that repo is old/outdated. This ( https://github.com/pycket/pycket-bench/blob/master/output/20... ) figure was the one used in the paper, which includes Gambit.
18.
by sabauma 10y ago
Pycket has different performance characteristics from many of the AOT systems we compared against. On average Pycket is ~2x faster than the Racket VM, ranging from ~3x slower to ~300x faster depending on the benchmark. Last I checked, Pycke
19.
by sabauma 10y ago
Its worth noting that the design of the RPython JIT will always result in a large amount of static data in the resulting binary. The RPython translator basically generates a bytecode representation of most of your interpreter and bakes that
20.
by sabauma 10y ago
Yes. It is for the Racket language.
21.
by sabauma 10y ago
The RPython translator generates views of the Mandelbrot set by default, presumably to give you something to look at during the long wait.