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.
> 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…
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…
> 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.
> 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…
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
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…
I agree; and the article seems to have also quite a few technical flaws: - Register width: we somewhat maxed out at 512 bits, with Intel going back to 256 bits for non-server CPUs. I don't see larger widths on the…
libgccjit is, despite its name, just another front-end for GIMPLE. The JIT-part is realized through compiling the object file to a shared library and using dlopen on this. One big problem with libgccjit, despite its…
> attempting to separate them, like what most if not all compilers do, results in (sometimes very) suboptimal results Not separating them would have a big disadvantage: all register allocation decisions need to be…
There was a paper about this at CGO earlier this year [1]. Correctness is a problem that is hard to solve, though; 50% accuracy might not be enough for serious use cases, especially given that the relation to the…
Side note: Intel CPUs since Skylake and also recent AMD CPUs (since Zen 3 or so?) store a history for indirect branches. On such processors, using threaded jumps does not really improve performance anymore (I've even…
TZCNT and BSF are not completely identical even for non-zero input: BSF sets the ZF when the input is zero, TZCNT sets ZF when the output is zero (i.e., the least significant bit is set).
The behavior/penalty of 66/67 length-changing prefixes is documented in the Intel Optimization Reference Manual (3.4.2.3): > Assembly/Compiler Coding Rule 19. (MH impact, MH generality) Favor generating code using imm8…
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.
> 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…
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…
> 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.
> 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…
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
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…
I agree; and the article seems to have also quite a few technical flaws: - Register width: we somewhat maxed out at 512 bits, with Intel going back to 256 bits for non-server CPUs. I don't see larger widths on the…
libgccjit is, despite its name, just another front-end for GIMPLE. The JIT-part is realized through compiling the object file to a shared library and using dlopen on this. One big problem with libgccjit, despite its…
> attempting to separate them, like what most if not all compilers do, results in (sometimes very) suboptimal results Not separating them would have a big disadvantage: all register allocation decisions need to be…
There was a paper about this at CGO earlier this year [1]. Correctness is a problem that is hard to solve, though; 50% accuracy might not be enough for serious use cases, especially given that the relation to the…
Side note: Intel CPUs since Skylake and also recent AMD CPUs (since Zen 3 or so?) store a history for indirect branches. On such processors, using threaded jumps does not really improve performance anymore (I've even…
TZCNT and BSF are not completely identical even for non-zero input: BSF sets the ZF when the input is zero, TZCNT sets ZF when the output is zero (i.e., the least significant bit is set).
The behavior/penalty of 66/67 length-changing prefixes is documented in the Intel Optimization Reference Manual (3.4.2.3): > Assembly/Compiler Coding Rule 19. (MH impact, MH generality) Favor generating code using imm8…