5 ms·

Java is seriously nasty if you need to work with bitpacked representations of data structures. Big endian nonsense, no unsigned types, booleans that cannot be c

Java is seriously nasty if you need to work with bitpacked representations of data structures. Big endian nonsense, no unsigned types, booleans that cannot be converted to integer types, no typedefs... gahhhh! It's really freaking hard to write optimised code in this stupid language.

dtech 11y ago
It's also not really meant/suited for that level of optimization. At some point it's better to use JNI or something.
KMag 11y ago
> no unsigned types, ... except char. You also forgot to mention their odd utf-8-ish encoding of strings in class files.
- TkTech 11y ago
  Eh, there's been far worse and their justification for it kinda-almost makes sense. They were trying to avoid 00 in the strings at all costs. It's simple enough to encode and decode: https://github.com/TkTech/Jawa/blob/master/jawa/util/utf.py#L12 https://github.com/TkTech/Jawa/blob/master/jawa/util/utf.py#...
  - KMag 11y ago
    Avoiding nulls wasn't the messed up part. Encoding UTF-16 surrogate pairs separately as pseudo-UTF-8 was the weird part. Some codepoints that would be 3 bytes in UTF-8 or 4 bytes in UTF-16 wind up as 6 bytes in Java's pseudo-UTF-8.
    - TkTech 11y ago
      The encoding for the surrogate pairs is a spec (not a standard) called CESU-8[1]. The modified UTF-8 in the ClassFiles is really just CESU-8 with an exception for U+0000. 1: http://www.unicode.org/reports/tr26/ http://www.unicode.org/reports/tr26/
      - Dylan16807 11y ago
        And that spec is basically "We screwed up the UTF-16 support and wrote a UCS-2 to UTF-8 converter instead. Um, well, it works, don't touch it."
Alupis 11y ago
> no unsigned types Java 8 has unsigned types[1] > boolean that cannot be converted into integer types Don't know why you would want to do that when a boolean is a primitive type... and also has an object variant, but... int myInt = (myBoolean) ? 1 : 0; > no typedefs A typedef is really like a java bean or class object... it's just a custom data structure. > It's really freaking hard to write optimised code in this stupid language. Not true, some of the most highly performant systems on the planet run Java... HFT, stock exchanges, banking, nuclear plant control systems, etc... There's also the JVM with it's optimizing compiler... one of the best (the best?) optimizing compilers around. Long running Java applications eventually compile hot paths down to native machine instructions, achieving C performance without a lot of the hassle. But then again, Java wasn't intended to do bit-twiddling, it's a higher abstraction. [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#toUnsignedLong-int- https://docs.oracle.com/javase/8/docs/api/java/lang/Integer....
- TheLoneWolfling 11y ago
  > Java 8 has unsigned types Right. Now try that with a long, and you're replacing every piece of code with something that's, what, 20x more verbose? If not more? And becuase of how bad the JVM is, substantially slower. Look at JGit. > int myInt = (myBoolean) ? 1 : 0; Now try to do that throughout the code. Not to mention which, that's a conditional branch for what should be (and is in bytecode) a no-op. (Well, assuming your bytecode is well-conditioned. But the JVM being the JVM, there's no such thing as a boolean, which means you can have the "boolean" value 2, for instance, which seriously messes all sorts of things up.) Sure, the JVM is supposed to optimize that out. But you can't rely on it being able to do so. At least not if you're not going to use a mainstream JVM. And no, the JVM is not "one of the best" optimizing compilers around. It's not even a good optimizing compiler. Nowhere near. For a quick counterexample, this: https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f80a76fc1911d77ae39153783fdc3 https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f8... Halving the time taken. Why? Because the JVM wasn't smart enough to realize that copying an EnumSet for a readonly foreach loop was unnecessary. Oh, and there's more low-hanging fruit there w.r.t. the amount of work (read: reflection) EnumSet has to do behind the scenes to work around Java's type system. Simple. But no, the Java compiler doesn't optimize it out, and the JVM doesn't either. And that's with adding an additional unnecessary layer of abstraction (unmodifiableSet) that you wouldn't need if Java had a sane type system. Copying an EnumSet of a small number of elements would be, in a sane language, quite literally just a register move. Ditto, containsAll a bitwise-not and a bitwise-and. But no, "one of the best" optimizing compilers around cannot even do that. Trying to write high-performance code in Java generally requires tossing out all the supposed advantages of Java. Write your own object pools, whee! Hardcode your own primitive types, whee! Avoid temporary objects, whee! Avoid using polymorphism, whee! Manually unpack arrays inside objects, whee!

dtech 11y ago

It's also not really meant/suited for that level of optimization. At some point it's better to use JNI or something.

KMag 11y ago

> no unsigned types, ... except char. You also forgot to mention their odd utf-8-ish encoding of strings in class files.

TkTech 11y ago
Eh, there's been far worse and their justification for it kinda-almost makes sense. They were trying to avoid 00 in the strings at all costs. It's simple enough to encode and decode: https://github.com/TkTech/Jawa/blob/master/jawa/util/utf.py#L12 https://github.com/TkTech/Jawa/blob/master/jawa/util/utf.py#...
- KMag 11y ago
  Avoiding nulls wasn't the messed up part. Encoding UTF-16 surrogate pairs separately as pseudo-UTF-8 was the weird part. Some codepoints that would be 3 bytes in UTF-8 or 4 bytes in UTF-16 wind up as 6 bytes in Java's pseudo-UTF-8.
  - TkTech 11y ago
    The encoding for the surrogate pairs is a spec (not a standard) called CESU-8[1]. The modified UTF-8 in the ClassFiles is really just CESU-8 with an exception for U+0000. 1: http://www.unicode.org/reports/tr26/ http://www.unicode.org/reports/tr26/
    - Dylan16807 11y ago
      And that spec is basically "We screwed up the UTF-16 support and wrote a UCS-2 to UTF-8 converter instead. Um, well, it works, don't touch it."

Alupis 11y ago

> no unsigned types Java 8 has unsigned types[1] > boolean that cannot be converted into integer types Don't know why you would want to do that when a boolean is a primitive type... and also has an object variant, but... int myInt = (myBoolean) ? 1 : 0; > no typedefs A typedef is really like a java bean or class object... it's just a custom data structure. > It's really freaking hard to write optimised code in this stupid language. Not true, some of the most highly performant systems on the planet run Java... HFT, stock exchanges, banking, nuclear plant control systems, etc... There's also the JVM with it's optimizing compiler... one of the best (the best?) optimizing compilers around. Long running Java applications eventually compile hot paths down to native machine instructions, achieving C performance without a lot of the hassle. But then again, Java wasn't intended to do bit-twiddling, it's a higher abstraction. [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#toUnsignedLong-int- https://docs.oracle.com/javase/8/docs/api/java/lang/Integer....

TheLoneWolfling 11y ago
> Java 8 has unsigned types Right. Now try that with a long, and you're replacing every piece of code with something that's, what, 20x more verbose? If not more? And becuase of how bad the JVM is, substantially slower. Look at JGit. > int myInt = (myBoolean) ? 1 : 0; Now try to do that throughout the code. Not to mention which, that's a conditional branch for what should be (and is in bytecode) a no-op. (Well, assuming your bytecode is well-conditioned. But the JVM being the JVM, there's no such thing as a boolean, which means you can have the "boolean" value 2, for instance, which seriously messes all sorts of things up.) Sure, the JVM is supposed to optimize that out. But you can't rely on it being able to do so. At least not if you're not going to use a mainstream JVM. And no, the JVM is not "one of the best" optimizing compilers around. It's not even a good optimizing compiler. Nowhere near. For a quick counterexample, this: https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f80a76fc1911d77ae39153783fdc3 https://github.com/RS485/LogisticsPipes/commit/bb8a57665c4f8... Halving the time taken. Why? Because the JVM wasn't smart enough to realize that copying an EnumSet for a readonly foreach loop was unnecessary. Oh, and there's more low-hanging fruit there w.r.t. the amount of work (read: reflection) EnumSet has to do behind the scenes to work around Java's type system. Simple. But no, the Java compiler doesn't optimize it out, and the JVM doesn't either. And that's with adding an additional unnecessary layer of abstraction (unmodifiableSet) that you wouldn't need if Java had a sane type system. Copying an EnumSet of a small number of elements would be, in a sane language, quite literally just a register move. Ditto, containsAll a bitwise-not and a bitwise-and. But no, "one of the best" optimizing compilers around cannot even do that. Trying to write high-performance code in Java generally requires tossing out all the supposed advantages of Java. Write your own object pools, whee! Hardcode your own primitive types, whee! Avoid temporary objects, whee! Avoid using polymorphism, whee! Manually unpack arrays inside objects, whee!