4 ms·
The changes in the LLVM JIT were definitely a disappointment. IIRC it used to be a lot more lightweight the API was simpler to use. But in hindsight it's hard
by aleden 9y ago
The changes in the LLVM JIT were definitely a disappointment. IIRC it used to be a lot more lightweight the API was simpler to use.
But in hindsight it's hard to argue that the LLVM devs shouldn't have messed with it. Before you couldn't get symbolized stacktraces or use C++ exceptions. LLVM's primary goal has always been to produce the best code, and not necessarily try to be the fastest at doing it [1].
In the 3.x days, it was a fast evolving project. I remember projects I managed that used LLVM would no longer compile between releases because e.g. they would rename a header file.
"Just to rename a header file??" one might say; it's a subjective question whether this philosophy hurt or helped the project in the end. It might take years until that answer is forthcoming.
I'm sorry to hear about what happened with GNU Octave. Maybe after LLVM proves to stabilize someone new will write up the code :)
[1] Tangentially related: https://bellard.org/tcc/ https://bellard.org/tcc/
Compiler Time(s) lines/second MBytes/second
TinyCC 0.9.22 2.27 859000 29.6
GCC 3.2 -O0 20.0 98000 3.4
- jordigh 9y ago> But in hindsight it's hard to argue that the LLVM devs shouldn't have messed with it. Not that hard, software stability is a very desirable property: http://stevelosh.com/blog/2012/04/volatile-software/ http://stevelosh.com/blog/2012/04/volatile-software/