Unanswered Questions tagged with Amazon Corretto

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

  • 1
  • 12 / page

Question pertaining to a New Patch for Corretto Java.

Every compatible version of the Java OpenJDK, from every vendor on the internet, has one overall problem. Arithmetic performed by operators on number values/types, being float and double, are able to gain denormal or pronormal values, 'Floating Point Errors', alongside the same, produced by method calls made on java.lang.StrictMath. This is is always quoted as being because of Java adherence to standard IEEE 754, which has a 2008 version, and has a more recent but non-free paper released in 2019. Programmers need range accurate integer and decimal mathematics, at the roots of their language, certainly if that language is to be a higher level language than Assembly or C. While there is the workaround approach, involving BigDecimal and BigInteger, and another approach that supplies a calculator class, the big-math library, [https://github.com/eobermuhlner/big-math](https://github.com/eobermuhlner/big-math), using and rely on these stop-gap, work-around solutions is a poor approach. They are larger in memory than needed; slower, messier in source code to program, debug, understand and edit, exclude their own access to operator syntax, and they are also never reified with default Java library classes or interfaces. IEEE 754, alongside floating point arithmetic, mentions traps, state exceptions and flags, phenomena that as of OpenJDK 17 Java has not adopted. It has been the attitude that because 754 doesn't stipulated what happens with underflow or overflow, aside from traps, state exceptions or flags, nor does it stipulate that it is a base 10 system on top of a binary one exactly, that therefore, because of these, underflow and overflow aren't (and can't be) bugs, by "definition of IEEE 754". In fact, because this seems to mean that 754 is not stated to be either a base 10 or base 2 system, that therefore from base 10's point of view, it could be either. This leads to one real view that it is incoherent, and therefore that it doesn't technically seem to resolve objectively, anywhere. IEEE 754 isn't strict or specific enough for base 10 or overflow/underflow, and trying to justify too closely too it creates problems with no solutions. See IEEE 754 2008 [https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf](https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf) **Pp 2, 1.5 Programming Environment Considerations**, the first sentence. This state of affairs has made floating point correction, at the locale of the Vendor and of Java ubiquity itself, impossible. Notwistanding calculator classes and comparisons, consider the following three code fragments: ``` **//---------------------------------------------------------- //The C Language. Arithmetic only, no comparisons. #include <stdio.h> int main() { printf("Program has started..."); printf("\n"); printf("\n"); double a = 0.1D; double b = 0.1D; double c = a*b; printf("%lf",c); printf("\n"); printf("\n"); float d = 0.1F; float e = 0.1F; float f = d*e; printf("%lf",f); printf("\n"); printf("\n"); printf("Program has Finished."); return 0; } /* Program has started... 0.010000 0.010000 Program has Finished. */ //---------------------------------------------------------- //The C++ Language. Arithmetic only, no comparisons. #include <iostream> using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; cout << endl << c << endl << endl; float d = 0.1F; float e = 0.1F; float f = d*e; cout << f << endl << endl; cout << "Program has Finished."; return 0; } /* Program has started... 0.01 0.01 Program has Finished.*/ //---------------------------------------------------------- //The Java Language. Arithmetic only, no comparisons. import static java.lang.System.*; public class Start { public static void main(String ... args) { out.println("Program has started..."); double a = 0.1D; double b = 0.1D; double c = a*b; out.println(); out.println(c); float d = 0.1F; float e = 0.1F; float f = d*e; out.println(); out.println(f); out.println(); out.println("Program has Finished."); }} /* Program has started... 0.010000000000000002 0.010000001 Program has Finished.*/ //----------------------------------------------------------** ``` Other people are aware of these shortfalls, which have gone on for too long a time. Which for programmers needing continous mathematical types, in areas of 2D graphics and 3D, has turned length of time into length of misery. See: [https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf](https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf), and [https://people.eecs.berkeley.edu/~wkahan/ARITH_17.pdf](https://people.eecs.berkeley.edu/~wkahan/ARITH_17.pdf). While Java has comparators ==, !=, >,<,>=,<= working correctly on float and double (which C++ hasn't), C++ does have range accurate, base 10 decimal floating point arithmetic on its float, double, long float, long double types, which does prove that this is possible, and in a fast manner. C decimal arithmetic behaves in terms of its ranges. I am aware that C++ taps into SSE, or equivalent, additional hardware bit registers, and similar, to deal with binary carries past the range end(s) of a floating point type, so that the final base 10 digit calculated and submitted, even if it is straddling the end of the bit range, still gets included, in base 10, entirely accurately, with no more pronormal and no less denormal values. See [https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions](https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions). Clearly it is possible to have reciprocal operations resolving to the perfect state of a previous value in place, which Java already has implemented, internally. I am aware the Amazon Corretto has been and is willing to patch its JRE/JVM to add new feature and improvements to their Corretto Java. It wish to propose and request the following: > 1) Is it possible for 64 bit Corretto, on all its Hardware/OS platforms, to produce a patch for Corretto, at least compatible with its most recent publically available, stable, version, but compatible moving forwards, that makes its Java floating point arithmetic and StrictMath (or equivalent) operations and calls (and any necessary closely bound class and interface relationships) entirely range accurate, by use of the (now ubiquitous) SSE type hardware, or similar? > 2) Such a patch could just alter the default for all execution. It could also attenuate to a runtime switch, or manifest line entry level approach. It might even approach to some special annotations approach, which alter denormal and pronormal mode on an off on variables, classes, interfaces, and even data, if this proves to be fast enough. Or an aggregate of all these could be implemented. > 3) Can someone in Amazon, actively involved with Corretto Java, kindly respond, with an imminent response or recommendation, only in terms of Java floating mathematics, itself?
0
answers
0
votes
6
views
Z1234
asked 8 months ago

How to run JVM based HFT application on Graviton 3 CPUs

Thinking of creating a High Frequency Transaction Trading system to test my Algo Trading Strategies. Infrastructure will be AWS EC2 Graviton 3 instance (C7g) + AWS Linux2 + AWS Corretto JVM runtime OR OpenJDK GraalVM distribution. Why Graalvm because its Polyglot and reduces the contextual switch (Marshaling/Un-Marshaling ) between Data Structures of different programing languages. AWS EC2 Graviton 3 coming with more than 100 virtual cores and more than 100 MB of L1 + L2 + L3 cache. Pre-compiled native ARM CPU instructions will be saved in the CodeCache. Data Analytics will be done by Apache Spark 3 and code will JIT aware (Mostly in Scala and R). Data will be populated from SSDs and processed in RAM. Questions 1. Will Amazon Corretto or GraalVM capable of generating executable native instructions and interpreting towards ARM based Graviton CPU. 2. Amazon Corretto is a flavor of OpenJDK. Does the Project GraalVM already merged with Amazon Corretto JVM. Can I replace **Java on Truffle - Mete Circular JIT** as C2 compiler of Amazon Corretto JVM. 3. Where I can refer guides or whitepapers related to Amazon Corretto supporting OpenJDK JEPs and projects. 4. Which super super quick programing language as a choice to write my Algo trading business logic. Expecting a nanosecond latency from the time of a signal enters the Ethernet port of a microprocessor and returns back the result. Better Suggestions and questions are always appreciated.
0
answers
0
votes
40
views
fasil
asked 10 months ago
  • 1
  • 12 / page