aengelke

7 ms·

1.
by aengelke 3d ago
Yeah, modern CPUs are great at executing garbage code reasonably fast. Getting binary-translated code to come close to native performance is still difficult. Apple obviously had an advantage as they also control the hardware (and Arm helped
2.
by aengelke 24d ago
> That's separate from query optimisation though, right? The query optimiser is presumably able to reason 'broadly' and not just at the level of individual expressions? High-level query-plan optimisation must be much more
3.
by aengelke 24d ago
Not sure where the idea comes from that Cranelift is much faster than LLVM -O0, at least in our experiments in 2024 it wasn't, see [1] Fig. 6. Template-based code generators suffer from bad code quality due to missing register allocati
4.
by aengelke 1mo ago
No, the 0f 0f opcode (most of 3DNow was encoding-wise a single RMI-encoded opcode where the immediate specified the operation) and the 0f 0e opcode (FEMMS) were not repurposed by either Intel or AMD.
5.
by aengelke 1mo ago
> The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD documentation. In case of the jump example, the effects are documented by Intel and AMD and they still differ. Point of
6.
by aengelke 1mo ago
> But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault. Oh, that's not completely true. Intel 64 and AMD64 are no
7.
by aengelke 6mo ago
I'm a bit late, but: Umbra doesn't use AsmJIT anymore since many years, it was too slow.
8.
by aengelke 7mo ago
That's not generally correct. Compile-time is a concern for several databases.
9.
by aengelke 7mo ago
> 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 for example very heavily relies on JIT compilatio
10.
by aengelke 9mo ago
> 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, sent via GMail -- this is not low-effort) that ask
11.
by aengelke 10mo ago
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 SCASB/CMPSB/LODSB (the latter being particular
12.
by aengelke 10mo ago
> 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. BNDCU or BNDMK. BNDLDX/BNDSTX are even weirder as they d
13.
by aengelke 10mo ago
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, using LLVM isn't going to give the best possible perfor
14.
by aengelke 11mo ago
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 these words to describe ISAs.
15.
by aengelke 11mo ago
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
16.
by aengelke 11mo ago
> 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 instruction encoding is on arm64 Having written encoders,
17.
by aengelke 1y ago
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 makes things just slower. When enabling multi-threading,
18.
by aengelke 1y ago
> 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 would I recompile it? For C++, this could happen more o
19.
by aengelke 1y ago
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 )
20.
by aengelke 1y ago
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 redundant. Another thing I'd consider as interesting is parse
21.
by aengelke 1y ago
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 the cost is often tolerable and TPDE also supports -O1 IR --
22.
by aengelke 1y ago
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) against LLVM -- and have written all benchmarks themselves
23.
by aengelke 1y ago
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-time performance is much worse (2.5x slower than LLVM -
24.
by aengelke 1y ago
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 rustc and Clang (especially in C++ mode) are quite slow. Fo
25.
by aengelke 1y ago
The documentation has a list of currently unsupported features: https://docs.tpde.org/tpde-llvm-main.html
26.
by aengelke 1y ago
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+len string (among other options). I once changed the implement
27.
by aengelke 1y ago
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-based aliasing information and therefore TySan won&
28.
by aengelke 1y ago
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 use the same tools, pass with this setup?
29.
by aengelke 1y ago
> 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 ported some numeric simulation kernel to the A64Fx some tim
30.
by aengelke 1y ago
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 remember that it was much slower than older x86 CPUs

More ›