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…
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.
> 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…
> 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…
I'm a bit late, but: Umbra doesn't use AsmJIT anymore since many years, it was too slow.
That's not generally correct. Compile-time is a concern for several databases.
> 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…
> 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…
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…
> 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…
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…
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.
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
> 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…
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…
> 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…
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)
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…
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…
The documentation has a list of currently unsupported features: https://docs.tpde.org/tpde-llvm-main.html
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…
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…
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…
> 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…
> 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 something like this: they collected the LLVM…
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…
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.
> 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…
> 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…
I'm a bit late, but: Umbra doesn't use AsmJIT anymore since many years, it was too slow.
That's not generally correct. Compile-time is a concern for several databases.
> 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…
> 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…
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…
> 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…
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…
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.
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
> 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…
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…
> 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…
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)
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…
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…
The documentation has a list of currently unsupported features: https://docs.tpde.org/tpde-llvm-main.html
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…
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…
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…
> 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…
> 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 something like this: they collected the LLVM…