Poor performance when processing low-entropy data compared to native execution

[urain39]

Problem

When running translated programs (emulation/JIT) that process low-entropy data (e.g., zero-filled buffers, highly repetitive patterns), the performance is significantly lower than running the same binary on real hardware (native execution). The performance gap for these specific data types is often much larger than the average overhead of the translation layer.

Cause

• [AI Answer] The primary reasons for this efficiency gap are the differences in hardware branch prediction and instruction optimization:
  • [AI Answer] Branch Prediction Breakdown: Native CPUs rely heavily on advanced branch predictors to achieve high throughput in loops dealing with predictable data. The translation layer typically splits execution into "Basic Blocks" and uses indirect jumps to link them. These indirect jumps often confuse the host CPU's branch predictor (as the target is computed dynamically), causing frequent pipeline stalls that do not occur on native hardware.
  • [AI Answer] Micro-op Fusion and SIMD: Native compilers often utilize specialized instructions (like rep stos or SIMD vectors) for low-entropy operations. The translator may fail to recognize these patterns or may lack the context to fuse them back into efficient host instructions, resulting in a sequence of naive, slower operations.
  • [AI Answer] Overhead-to-Work Ratio: Processing low-entropy data often involves very simple, tight loops. Because the actual computation is so lightweight, the fixed overhead of the translation engine (block lookup, dispatch, and cache management) becomes disproportionately large relative to the work being done.

Solution

• [AI Answer] To mitigate this issue, consider the following improvements:
  • [AI Answer] Chain / Superblock Dispatching: Implement "chaining" of basic blocks so that the end of one block jumps directly to the start of the next (via a relative jump) rather than going through a central dispatch table. This restores branch prediction accuracy for hot loops.
  • [AI Answer] Library Call Optimization (LCO): Detect standard library functions (e.g., memset, memcpy, memcmp) and replace the translated guest code with direct calls to the highly optimized host native libraries.
  • [AI Answer] Runtime Vectorization: Enhance the code generator to detect loops iterating over simple data and generate host SIMD instructions (e.g., AVX/SSE) on the fly, rather than translating scalar instructions one-by-one.

[ptitSeb]

I really don't need AI stuffs. I need more details of what you want to do and the performances you get / expect. And things so I can reproduce on my side/

[urain39]

Reproduction Steps

1. Generate test files (1 GiB):

   dd if=/dev/zero of=zero.bin bs=1M count=1024
   dd if=/dev/urandom of=urandom.bin bs=1M count=1024

2. Native ARM64 baseline:

   time ./busybox.arm64 gzip -c zero.bin > /dev/null
   time ./busybox.arm64 gzip -c urandom.bin > /dev/null

3. Box64 + x86_64 busybox (emulated):

   time ./box64 ./busybox.amd64 gzip -c zero.bin > /dev/null 2>/dev/null
   time ./box64 ./busybox.amd64 gzip -c urandom.bin > /dev/null 2>/dev/null

Results (real time, seconds):

Input	Native ARM64	Box64 + AMD64	Overhead
zero.bin	8.04	15.64	+94.5%
urandom.bin	31.36	49.91	+59.2%

[urain39]

I really don't need AI stuffs. I need more details of what you want to do and the performances you get / expect. And things so I can reproduce on my side/

Sorry for this, I think it may be useful.

Of course, I understand this is a somewhat specialized case—but it's also quite common in real-world workloads (e.g., compression, initialization, sparse data handling).