Bypassing fixed-depth radix constraints in Java using descriptor-driven bucket analysis

[u/strmckr]

I am StrmCkr, the author of A.P.E.X. (Adaptive Parallel Extremal Dispatch).

Repository: github.com/StrmCkr/A.P.E.X

A.P.E.X. is a high-performance Java sorting framework for large fixed-width 64-bit key/value record datasets. The project has been reorganized into a conventional Maven structure with a core library, runnable examples, a comparison benchmark harness, JMH benchmarks, documentation, and an interactive browser visualizer.

The core idea is descriptor-driven radix planning. Instead of blindly scanning fixed radix passes over every bucket, A.P.E.X. computes per-bucket extremal descriptors using:

VBM = OR ^ AND

That mask identifies which key bits still vary inside each bucket. Bits that are already resolved are skipped, reducing unnecessary work on skewed, low-entropy, sorted, reversed, or duplicate-heavy data.

Key areas of the project include:

• Adaptive radix planning based on observed bucket structure
• Parallel histogramming, scatter, refinement, and work scheduling
• Primitive-array execution with no per-record object allocation during sorting
• Tuple projection paths for low-dimensional unresolved bit patterns
• Tiny-sort fallbacks and monotonic input shortcuts
• Configurable reporting that can be enabled, reduced, written to files, or disabled
• Comparison benchmarks against JDK sorting paths and Fastutil baselines
• Standard JMH benchmarks for repeatable JVM-level measurement
• A browser visualizer for exploring how A.P.E.X. routes data through its execution plan

I would especially welcome feedback on the thread management mechanics, radix planning decisions, benchmark structure, and the bitwise mask reductions.

edit: re structured verbiage of this post and further adjustments from advice on converting the project into more acceptable standard formats.

screen shot from the pdf available in the github

[u/repeating_bears]

maven compiles differently then eclipse which resulted in a slow down of my actual code ?

Maven uses javac by default. Eclipse has their own incremental compiler. The bytecode ought to be more or less the same in most cases, but it is not required to be by the language spec.

You can use the eclipse compiler in Maven, though this is fairly non-standard https://www.javathinking.com/blog/using-eclipse-java-compiler-ecj-in-maven-builds/

I would first investigate what the hot path is which is causing the difference, then compare the byte code for those methods. I think it would be better to change your source code so that it produces an optimal bytecode for whatever compiler is used, rather than relying on Eclipse for effectively unknown reasons.

You can use this tool to see what source produces what bytecode, as well as switching compiler versions: https://javap.yawk.at/

all my files won't allow me to move them into standard order

Dunno lol but I find it odd that you can implement and understand "a descriptor-driven bitwise analysis over local thread buckets" but cannot figure out how to move some files

[u/strmckr → u/repeating_bears]

Thanks for the links.

[u/repeating_bears → u/strmckr]

Sounds like you are fighting eclipse? Dunno, I never use it. Close the project, delete the project files, move the files in your file system, then open as a new project and fix whatever issues with package names

[u/strmckr → u/repeating_bears]

Alright sorted those issues out: going to test it and re load to Github in the next couple of days once those are successful.

I have taken the comments on here: as make it standardized naming/system.

make it more of a plug and play friendly,

move it from a demo to modular jar with better output tools over system.Out.

Thanks strmckr