Live data from Hacker News

Viewing profile — aengelke

aengelke

HN member
Joined
Mon, May 15, 2023, 7:58 PM UTC
HN karma
199
Public activity
53 items

About aengelke

No profile information was provided.

Recent public activity

  1. comment
    Comment #47300365

    I'm a bit late, but: Umbra doesn't use AsmJIT anymore since many years, it was too slow.

  2. comment
    Comment #47246897

    That's not generally correct. Compile-time is a concern for several databases.

  3. comment
    Comment #47246871

    > It's very difficult to do low-latency queries if you cannot cache the compiled code This is not too difficult, it just requires a different execution style. Salesforce's Hyper fo…

  4. comment
    Comment #46252751

    > What's the rationale? Gift cards are used by phishers. In our institution, we routinely get personalized spam mails (in the name of the corresponding group lead of the recipient,…

  5. comment
    Comment #46122889

    I fully agree, but: > these are the string instructions like REP MOVSB AArch64 nowadays has somewhat similar CPY* and SET* instructions. Does that make AArch64 CISC? :-) (Maybe REP…

  6. comment
    Comment #46122802

    > LEA happens to be the unique instruction where the memory operand is not dereferenced Not quite unique: the now-deprecated Intel MPX instructions had similar semantics, e.g. BNDC…

  7. comment
    Comment #46003959

    Been there, done that during my PhD (code: [1]). Works reasonably well, except for compile times (for which I implemented a caching strategy). However, due to calling conventions, …

  8. comment
    Comment #45760915

    Actually, nowadays Arm describes the ISA as a load-store architecture. The RISC vs. CISC debate is, in my opinion, pretty pointless nowadays and I'd prefer if we'd just stop using …

  9. comment
    Comment #45752869

    The same site hosts [1], but that's not nearly as nice as the 32-bit version. It's also a bit outdated. [1]: https://www-user.tu-chemnitz.de/~heha/hs/chm/x86.chm/x64.htm

  10. comment
    Comment #45751582

    > I’d suggest starting with arm I agree: AArch64 is a nice instruction set to learn. (Source: I taught ARMv7, AArch64, x86-64 to first-year students in the past.) > how simple inst…

  11. comment
    Comment #45428037

    TPDE co-author here. Nice work, this was easier than expected; so we'll have better upstream ORC support soon [1]. The benchmark is suboptimal in multiple ways: - Multi-threading m…

  12. comment
    Comment #45161672

    > but typically a change to the preprocessed output implies a change to the IR (e.g., it's a functional change and not just a variable name change or something). Otherwise, why wou…

  13. comment
    Comment #45160231

    Or rather: There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. (source: https://martinfowler.com/bliki/TwoHardThings.html )

  14. comment
    Comment #45160214

    Template instantiation caching is likely to help -- in an unoptimized LLVM build, I found that 40-50% of the compiled code at object file level is discarded at link-time as redunda…

  15. comment
    Comment #45119860

    In AoT compilation, unoptimized code is primarily useful for debugging and short compile-test round trips. Your point on C++ is correct, but test workloads are typically small so t…

  16. comment
    Comment #45116367

    The paper is rather selective about the used benchmarks and baselines. They do two comparisons (3 microbenchmarks and a re-implementation of a few (rather simple) database queries)…

  17. comment
    Comment #45114950

    There's a longer paragraph on that topic in Section 8. We also previously built an LLVM back-end using that approach [1]. While that approach leads to even faster compilation, run-…

  18. comment
    Comment #45113671

    In terms of runtime performance, the TPDE-generated code is comparable with and sometimes a bit faster than LLVM -O0. I agree that front-ends are a big performance problem and both…

  19. comment
    Comment #45095662

    The documentation has a list of currently unsupported features: https://docs.tpde.org/tpde-llvm-main.html

  20. comment
    Comment #44702609

    Storing the string length explicitly as an 8-byte integer does have a measurable cost. Consider llvm::Twine as an example, it supports storing a null-terminated string and a ptr+le…

  21. comment
    Comment #44426467

    It's probably worth noting that TySan currently only catches aliasing violations that LLVM would be able to exploit. For some types, e.g. unions, Clang doesn't emit accurate type-b…

  22. comment
    Comment #44167762

    These are tests that use some more LLVM tools (llvm-objdump, llvm-dwarfdump, not). Could you try after building these tools in addition to FileCheck? Do the TPDE-LLVM tests, which …

  23. comment
    Comment #43786190

    > Also there are processors with larger vector length How do these fare in terms of absolute performance? The NEC TSUBASA is not a CPU. > Do you have more examples of this? I porte…

  24. comment
    Comment #43786035

    Thanks, I misremembered. However, the microarchitecture is a bit "weird" (really HPC-targeted), with very long latencies (e.g., ADD (vector) 4 cycles, FADD (vector) 9 cycles). I re…

  25. comment
    Comment #43785912

    > if we didn't settle on executing compiled machine code exactly as-is, and had a instruction-updating pass (less involved than a full VM byte code compilation) Apple tried somethi…