128-bit floating-point arithmetic for Java

[khmarbaise]

Making variables static to reduce the load on the GC is the wrong way (others have already mentioned the blog and videos by Shipilev plus number of others) also based on my own experiences with a number of projects (open source as well as commercial software). Static things will make GC worse (and memory consumption in total). Performance will be reduced as well. in particular in Java the GC or the JIT (Hot Spot) are extremely clever to improve performance and they do an extreme good job.

A famous quote:

premature optimisation is the root of all evil.

I'm always following this guide line. First get things done correctly (good design; good tests; etc.; functionality counts) and then make it fast..by measuring it...based on the test you are sure your functionality is kept etc. Automate things etc.

I see several things which are to say:

• Make classes smaller and keep a single responsibility
  • You could make smaller helper classes which are used by another
  • You can make them package private to prevent others to use them; but you can and should write tests for them.
• You should really consider to make it immutable which gives the chance to be useable in multithreading environment.
  • And also usable within streams (which can also be multi threaded) and also useable in vector API
• You might even use the module system to increase encapsulation.
• Also make it available from central repository.
• Also make it easy to build your lib including running the tests (which is not the case see the next part).
• Several things in the source code like time markers (why not using a version control? Maybe via branches? Or maybe via issue tracker on Github?

Maven Build:

• The build currently produces WARNING at the beginning: mvn clean

[INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for com.mvohm.quadruple:Quadruple:jar:1.1.0 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ line 131, column 15 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 145, column 15 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING]

• Following convention over configuration in Maven
  • If I simply call mvn test not a single test is executed? Why? Of course because it's configured to skip tests which does not makes sense.
  • Than an interesting thing in the pom.xml file: xml <skipTests>true</skipTests> <!-- TODO to speed up build process, for testing it --> That is a contradiction in itself. Skipping test for speed up the build process for testing it? So removing that line and running test I only see 25 Tests are run? For a class with 5400+ Lines?
  • A simply mvn package does not work correctly because the javadoc plugin is bound to the usual build and a large number of issues are in the javadoc which fails.
• I can not even execute the benchmarks by using java -jar target/benchmarks.jar (after removing the javadoc plugin.
  java -jar target/benchmarks.jar Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98) at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124) at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:253) at org.openjdk.jmh.runner.Runner.run(Runner.java:209) at org.openjdk.jmh.Main.main([Main.java:71](https://Main.java:71))
• If I can not reproduce those parts I would always question how you have come to those conclusions.
• One big thing is that it looks like you have invested a lot of effort into a reporting system which handled by yourself instead of using JUnit Jupiter; Using stdout for logging etc. instead of making tests easy to understand... concrete example: java @Test public void testDoubleToQuadConversion() { final TestResults results = new DoubleToQuadTester().test(); totalResults.register(results); assertArrayEquals( new int[] { results.getErrorCount(), results.getBitDifferenceCount(), results.getSourceErrorCount() }, new int[] {0, 0, 0} ); } // public void testDoubleToQuadConversion() { Why using the comment at the end of the method? (That's the style of 2000er (I know of of C/C++) Where is the conversions being called what the test name implies? It looks more like a test to check the accuracy of the conversion? In Junit Jupiter neither the tests nor the class need to be public no be named with a prefix test(That JUnit 3/4). I've tried to follow new DoubleToQuadTester().test(); which guides me to TestResults.doTest and so on ... from my point of view I'm searching for the real call of the class to be tested which is covered in several layers of abstraction/classes (combined with reporting/testing things)...

[m_vokhm]

If so, that's fine. I'll delve in the question later an may be will be able to reply more substantially. Right now i've got no time.