Live data from Hacker News

Viewing profile — djwatson24

djwatson24

HN member
Joined
Thu, Feb 20, 2014, 10:06 PM UTC
HN karma
61
Public activity
22 items

About djwatson24

No profile information was provided.

Recent public activity

  1. comment
    Comment #48333974

    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-…

  2. comment
    Comment #48151719

    > 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. comment
    Comment #47787047

    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 downside…

  4. comment
    Comment #45928722

    Absolutely. Things that took hours or days to debug before take mere minutes once I have an rr recording.

  5. story
  6. comment
    Comment #45425310

    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. …

  7. comment
    Comment #43613274

    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 n…

  8. comment
    Comment #42276918

    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 s…

  9. comment
    Comment #35923793

    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…

  10. story
  11. comment
    Comment #33337351

    This is great, thanks! Fyi I think you have the numbers for the years reversed

  12. comment
    Comment #33254792

    > 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 cove…

  13. comment
    Comment #29854191

    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 …

  14. comment
    Comment #29352478

    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 lim…

  15. comment
    Comment #26571133

    D has three fully functional compilers on Linux, and is probably in better shape than python, rust, even c++ in that regard.

  16. comment
    Comment #25479046

    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. comment
    Comment #25478644

    Unless I am misreading their graph, Java beats neither c++ nor koka in time or rss.

  18. comment
    Comment #25478583

    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 referenc…

  19. comment
    Comment #17785098

    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 versio…

  20. comment
    Comment #17516967

    IIRC TLS renegotiation was removed in TLS 1.3

  21. comment
    Comment #12194342

    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 granular…

  22. comment
    Comment #7274073

    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 t…