sabauma
sabauma on Hacker News
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 throw some money their way for it, but $5/month is a lot for what amounts to 8GB of storage.
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 that would improve the epub experience, like improved navigation and bookmarks (never really made use of these on my Kindle though). The biggest missing feature IMO as a Kindle replacement is the lack of builtin lighting.
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.
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 manually write a loop, there is only one 'body', so a tracing JIT turns that into a single or small number of traces.
For the loop inside of map, you need to produce side exits and new traces for each function passed in. The more times map is used, the slower it gets. This is made worse by the fact that traces out of side exits tend to not be optimized nearly as well.
Pycket has this same issue with its builtin (or hand written) looping _functions_ like map. Fortunately, Racket provides many useful looping macros which allows Pycket to generate unique traces for each loop, ameliorating this problem somewhat in Pycket.
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 changed much.
There are some benchmarks which evaluate Pycket's performance when applied to gradual typing [1]. Pycket does a pretty good job of optimizing the overheads of gradual typing (or at least Racket's implementation strategy), though it by no means eliminates the performance costs.
[1] https://dl.acm.org/citation.cfm?id=3133878
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['b'] = 123
print b
print d
print d is locals()
main()
Which prints
{'a': 1}
Traceback (most recent call last):
File "test.py", line 23, in <module>
main()
File "test.py", line 19, in main
print b
NameError: global name 'b' is not defined
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 runtime profiling information. Racket's "JIT" is similar in that code is generated for a function when it is first called, but the optimizer is run on the bytecodes of the program before anything is run.
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 consistently good performance without huge warmup time, which is Pycket's biggest weakness. With Racket planning to switch over to Chez, it may be difficult to justify Pycket's existence, especially if some of Chez's known performance sore spots receive attention.
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 recursion. The problem is that all of these solutions are rather limited, easy to break, or have a pretty high runtime overhead. The general solution would be for a decorator to rewrite all CALL opcodes in tail postion to TAIL_CALL opcodes, but such an opcode currently does not exist. The actual implementation of a TAIL_CALL opcode would be almost idential to the CALL opcode, so adding it would probably be straightforward, but I'm speculating here.
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 includes a translator which targets C. The generated code is reasonably fast (I think the PyPy interpreter without the JIT is within a factor of 2 the CPython VM). The translator is also responsible for generating the JIT compiler for your interpreter, so a well written interpreter can indeed be quite fast, post translation.
> 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 implementing an iterative process where we can't statically know that the call stack won't be exhausted. That said, TCO is usually an all or nothing transformation, and it would be difficult to accurately avoid eliminating trivial tail calls like in your example.
A reasonable compromise might be for the Python VM to implement a TAIL_CALL bytecode op and require the programmer to decorate functions which rely on TCO. This wouldn't be any more onerous than manually trampolining large portions of code, which is the current method of getting around the lack of TCO.
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.
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.
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 of the odd things Phorth does to the internal interpreter state.
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 bytecodes.
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, Pycket's mean performance was about 10% slower than Chez Scheme. The cost you pay for this performance is a rather significant warmup time for many benchmarks.
As for libraries, the only major feature that Pycket does not support is Racket's FFI, most built in functions can be implemented pretty easily if missing.
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 into the binary. You can probably expect at least a 2x size increase in the size of your binary. As a reference point, after stripping [Pycket](
https://github.com/pycket/pycket)'s binaries are 6.1Mi without the JIT and 16Mi with the JIT.
Yes. It is for the Racket language.
The RPython translator generates views of the Mandelbrot set by default, presumably to give you something to look at during the long wait.