Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
djwatson24
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
djwatson24
4mo ago
I’ve always wondered about linear scan vs SSA based spilling & regalloc, like libfirm & qbe use: ‘Register spilling and live-range splitting for SSA-form programs’ and ‘Preference-Guided Register Assignment’ It’s much cleaner to cod
2.
▲
by
djwatson24
4mo ago
> We wanted to check out the infamous Infinite Loop too, but were afraid it could take a long time. Haha! Nerd jokes are the best jokes
3.
▲
by
djwatson24
5mo ago
It's quite impressive they're able to take nearly arbitrary C and do this! Very similar to what pypy is doing here, but for C, and not a python subset. However not without downsides. It sounds like average code is only 2x faster
4.
▲
by
djwatson24
10mo ago
Absolutely. Things that took hours or days to debug before take mere minutes once I have an rr recording.
5.
▲
Scheme Reports at Fifty
(crumbles.blog)
66 points
by
djwatson24
11mo ago
|
25 comments
6.
▲
by
djwatson24
1y ago
Tail calling (with musttail)+ preserve_none are definitely the future of interpreters. Gets you ~95% of the performance of writing the vm in assembly, while keeping it high level. Unfortunately only clang and llvm support it so far, but ho
7.
▲
by
djwatson24
1y ago
Marc feeley wrote “using closures for code generation” way back in 1987. Everything old is new again! It’s quite nice and only a small bit more code than an ast interpreter - but not as fast as a luajit- style tail calling bytecode vm, nor
8.
▲
by
djwatson24
2y ago
Can you go in to more detail on 'wacky register allocation tricks' or instruction selection needed to support nun-tagging? Or pointers to code somewhere? Would be nice to compare some of them to the paper.
9.
▲
by
djwatson24
3y ago
Deegen is my research meta-compiler to make high-performance VMs easier to write. Deegen takes in a semantic description of the VM bytecodes in C++, and use it as the single source of truth to automatically generate a high-performance VM at
10.
▲
Building a baseline JIT for Lua automatically
(sillycross.github.io)
10 points
by
djwatson24
3y ago
|
8 comments
11.
▲
by
djwatson24
4y ago
This is great, thanks! Fyi I think you have the numbers for the years reversed
12.
▲
by
djwatson24
4y ago
> and that relies on having sufficient test and fuzz coverage At the faang I worked at, some small portion of servers ran the sanitizers in prod, so you’re not reliant on test coverage nearly so much for catching rare issues.
13.
▲
by
djwatson24
5y ago
Binary trees is a classic GC benchmark - ideally a GC'd language should be able to do better than a malloc/free implementation in C (tree.c) since it can release the whole tree in bulk (like what the ptree.c does). Also note tha
14.
▲
by
djwatson24
5y ago
I agree the optimization looks backwards to me - in most of the microcontrollers I work on, the flash program space can easily be multiple megabytes, but the ram is usually the limiter around 128-512k.
15.
▲
by
djwatson24
5y ago
D has three fully functional compilers on Linux, and is probably in better shape than python, rust, even c++ in that regard.
16.
▲
by
djwatson24
6y ago
I don’t think const or non const is the main issue- some data structures just require cycles like graphs or circular linked lists.
17.
▲
by
djwatson24
6y ago
Unless I am misreading their graph, Java beats neither c++ nor koka in time or rss.
18.
▲
by
djwatson24
6y ago
Cool to see explicit annotations for how to make rc fast when you have access to the ir. But doesn’t solve some major issues, like cycle collection: “ In practice, mutable references are the main way to con- struct cyclic data. Since mutabl
19.
▲
by
djwatson24
8y ago
I think what happened is that feature landed concurrently with the paper - a very early version is mentioned as reference [7]. Netflix also published several papers on their version for openbsd, which I didn't see mentioned.
20.
▲
by
djwatson24
8y ago
IIRC TLS renegotiation was removed in TLS 1.3
21.
▲
by
djwatson24
10y ago
This version still has to tick, yes? The whole point of optimizing ticks-until-next-event is to support nohz tickless modes. "Optimizing for high occupancy" also means low granularity - since the more granular timeouts you need, t
22.
▲
by
djwatson24
13y ago
After thrift became an Apache project, internal Facebook employees found it harder to iterate using external tools than our internal github repos. Many of the changes depended on things that weren’t open source, or only recently became op