Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  JOML 1.8.0 Release  (Read 40795 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #30 - Posted 2016-10-19 18:24:27 »

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
private static void brutex()
{
  float v = .1f;
  double e = 0.f;
  double ev = v;
  do {
    double r1 = sin_theagentd_arith(v);
    double r2 = Math.sin(v);
    double d  = Math.abs(r1-r2);
   
    if (d > e) {
      e  = d;
      ev = v;
    }
   
    v = Math.nextUp(v);
  } while(v <= PI);
  System.out.println(e + " @ " + Double.toHexString(ev) + " :" + sin_theagentd_arith(ev) + " " + Math.sin(ev));
}


5.881720110956223E-9 @ 0x1.2d97c6p1 :0.7071069396761204 0.7071069455578405
5.881719777889316E-9 @ 0x1.2d97c6p1 :0.7071069396761207 0.7071069455578405
Offline Roquen

JGO Kernel


Medals: 518



« Reply #31 - Posted 2016-10-20 07:27:41 »

Since there are no comments.  Doesn't anyone notice anything "odd" about these results?
Offline CommanderKeith
« Reply #32 - Posted 2016-10-20 10:09:12 »

Is it that the error 'e' actually got smaller on the second print rather than bigger, so 5.881719777889316E-9 < 5.881720110956223E-9 ?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #33 - Posted 2016-10-20 10:48:57 »

Thinking two things really:  the actual error is more than theagentd found AND they are both at the same input value.
Offline gouessej
« Reply #34 - Posted 2016-10-20 11:38:31 »

Hi

KaiHH, I'm almost sure it won't compile with Java 1.9:
https://github.com/JOML-CI/JOML/blob/master/src/org/joml/MemUtil.java#L1907

Have you ever tried to compile JOML with an early build of Java 1.9?

Julien Gouesse | Personal blog | Website | Jogamp
Offline KaiHH

JGO Kernel


Medals: 787



« Reply #35 - Posted 2016-10-20 11:41:33 »

KaiHH, I'm almost sure it won't compile with Java 1.9
Have you ever tried to compile JOML with an early build of Java 1.9?
Yes, I did. It compiles fine on 1.9 Build 140. Java 9 will not remove sun.misc.Unsafe. Probably 10 will.
And even if it did, JOML can still for a very long time build the CI builds on JDK8, and the MemUtilUnsafe class will not be loaded at runtime if it was detected that sun.misc.Unsafe is not available. So, _running_ JOML on any Java 1.4 compatible JVM is fine, even if it does not support sun.misc.Unsafe.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #36 - Posted 2016-10-22 02:01:28 »

http://pastebin.java-gaming.org/e291e8d814b10


func   @                              : rel-error                      : ulp-dif  bits
orig   @   2.356194 (   0x1.2d97c6p1) : 5.881720e-09 (0x1.9430508p-28) : 52977825 27
horner @   2.356194 (   0x1.2d97c6p1) : 5.881720e-09 ( 0x1.94304fp-28) : 52977822 27
range  @   1.570795 (   0x1.921f9cp0) : 6.017409e-12 (    0x1.a77p-38) :    54200 37
sollya @   1.274948 (   0x1.4662fap0) : 4.440892e-16 (      0x1.0p-51) :        4 50

reduce @   0.651724 (   0x1.4daecp-1) : 3.338118e-09 ( 0x1.cac992p-29) : 30067090 28
Offline CommanderKeith
« Reply #37 - Posted 2016-10-22 15:25:41 »

Very interesting.

I made some small additions to Roquen's code to do a little micro-benchmark of the different Math.sin approximation methods referenced in this and other threads between zero and +Math.PI. Thanks to Roquen, Kai, theagentd and Riven for contributing their different fast sin methods.

Here are the micro-benchmark results:

1  
2  
3  
4  
5  
6  
7  
8  
9  
Math.sin nanos per operation: 92.64692352
original nanos per operation: 15.45626018
horner nanos per operation: 12.8026165
range nanos per operation: 9.38279252
newk nanos per operation: 9.22229814
sin_9 nanos per operation: 7.35209479
sin_theagentd_lookup nanos per operation: 9.73315193
sinHalf nanos per operation: 7.10601857
sinFull nanos per operation: 6.19737146


I have little confidence in my own benchmarking abilities, but I did notice that these results are similar to Riven's given here (http://www.java-gaming.org/topics/are-sin-cos-lookup-tables-still-relevant-today-with-regards-to-performance/29853/msg/274983/view.html#msg274983). Riven's sinHalf and sinFull methods take about 7% of the time needed for the Math.sin function in his test and in mine here.
Riven's SinHalf lookup table method is the fastest. Roquen's interesting sin_9 method is only marginally slower but I suspect it has far greater accuracy. The speed of Roquen's newk method given it's level of accuracy is pretty incredible.

I wanted to include the error table that Roquen showed and include Riven's methods too, but I did something wrong with measuring the error of Riven's look up tables since it was negative, so I won't post that error output until I have time to investigate.

Here is the code that I threw together to do these benchmarks. Apologies for the poor organisation. You may have to run it with the -Xmx6000M VM option to avoid running out of memory or else change the line "int numTestValues = 100000000;" to something smaller.


http://www.java-gaming.org/?action=pastebin&id=1489

A big thank you to Roquen, Kai, theagentd and Riven for their code.

Offline Roquen

JGO Kernel


Medals: 518



« Reply #38 - Posted 2016-10-22 15:59:12 »

I forgot to note in the pastebin code that brute force error checking isn't needed.  Say for polynomial methods you can compute where the error should be zero and verify that within a couple of ULPs of these points that the sign of the error does change.  Likewise compute where the error should be maximum and find the peaks.  Much faster and exact error measures.

EDIT: Oh and that code/output should be printing 'abs error' and not 'rel error'.
Offline CommanderKeith
« Reply #39 - Posted 2016-10-22 18:05:05 »

Is it possible to make an atan2 approximation using the sollya method you used to make this great sin approximation?

I see that atan2 is not continuous and has vertical asymptotes so would an approximation using this polynomial-fitting method be very good?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #40 - Posted 2016-10-22 18:09:01 »

Yes.  The trick is range reduction since atan doesn't converge as fast.  So there are many more choice trade-offs.
Offline theagentd
« Reply #41 - Posted 2016-10-22 18:47:44 »

I had a rather unique situation where I was using a "circular heightmap", a 1D heightmap that wraps around a circle with a certain resolution. I needed to find out what height index was closest to a certain point (= round(heightmapResolution * atan2(dy, dx) / (2*PI) + 0.5)), one of the rare cases where I actually had to work with angles instead of just vectors. This was being used for collision detection to figure out which part of the heightmap to check the object against, so performance was critical. However, any atan2() approximation I could find had too low precision, and in the case of my collision detection precision was so critical that the approximations caused missed collisions.

My point is that for any actual valid use of atan2() that you can't use vectors for instead, you need very good precision. That being said, if we could find such an approximation I would make very good use of it.

Myomyomyo.
Offline CommanderKeith
« Reply #42 - Posted 2016-10-22 18:59:28 »

Yes.  The trick is range reduction since atan doesn't converge as fast.  So there are many more choice trade-offs.

That's great news! Are these trade-offs done automatically by sollya or does it need manual tuning?


Offline Roquen

JGO Kernel


Medals: 518



« Reply #43 - Posted 2016-10-23 09:28:02 »

That's great news! Are these trade-offs done automatically by sollya or does it need manual tuning?

You have to make the choices about how to reduce the range.  The tricky bit here is that they mostly involve division and java doesn't give access to 1/x approximation operations.

I had a rather unique situation where I was using a "circular heightmap", a 1D heightmap that wraps around a circle with a certain resolution.
Does the heightmap actually model a perturbed circle?  If so there are options of doing something other than equi-angluar.  That way you can move to a cheaper mapping function.
Offline gouessej
« Reply #44 - Posted 2016-10-23 12:52:37 »

Yes, I did. It compiles fine on 1.9 Build 140. Java 9 will not remove sun.misc.Unsafe. Probably 10 will.
Sorry but it has already been moved into a module (jdk.unsupported) only accessible by using a switch:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/7b0b28ceca62/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java

And even if it did, JOML can still for a very long time build the CI builds on JDK8, and the MemUtilUnsafe class will not be loaded at runtime if it was detected that sun.misc.Unsafe is not available. So, _running_ JOML on any Java 1.4 compatible JVM is fine, even if it does not support sun.misc.Unsafe.
You're right but have you looked at a replacement for Java 1.9 even though there is no hurry?

Julien Gouesse | Personal blog | Website | Jogamp
Offline KaiHH

JGO Kernel


Medals: 787



« Reply #45 - Posted 2016-10-23 13:23:57 »

It is accessible without a switch or a module import when the runned Jar is not a Jigsaw module.
So, people can still use their application and JOML on JDK9 unchanged.
Once people actually decide to use Jigsaw to modularize their games, then we would have to modularize JOML as a Jigsaw module.

Quote
You're right but have you looked at a replacement for Java 1.9 even though there is no hurry?
I will look at it once JDK9 is released and people start using it with Jigsaw.
Offline gouessej
« Reply #46 - Posted 2016-10-24 11:56:53 »

It is accessible without a switch or a module import when the runned Jar is not a Jigsaw module.
So, people can still use their application and JOML on JDK9 unchanged.
Actually, no. You have to force this module to be exported, I had to use this even though I don't package my software as a module:
Quote
--add-exports jdk.unsupported/jdk.internal.ref=ALL-UNNAMED

Julien Gouesse | Personal blog | Website | Jogamp
Offline Spasi
« Reply #47 - Posted 2016-10-24 12:30:08 »

Actually, no. You have to force this module to be exported, I had to use this even though I don't package my software as a module:
Quote
--add-exports jdk.unsupported/jdk.internal.ref=ALL-UNNAMED

My guess is that you depend on Cleaner, which has been completely removed from sun.misc and moved to jdk.internal.ref. It has nothing to do with sun.misc.Unsafe.
Offline KaiHH

JGO Kernel


Medals: 787



« Reply #48 - Posted 2016-10-24 12:36:09 »

It is accessible without a switch or a module import when the runned Jar is not a Jigsaw module.
So, people can still use their application and JOML on JDK9 unchanged.
Actually, no. You have to force this module to be exported, I had to use this even though I don't package my software as a module:
Quote
--add-exports jdk.unsupported/jdk.internal.ref=ALL-UNNAMED
I cannot reproduce. I am using this: https://jdk9.java.net/download/. What are you using?
Using the following test case:
1  
2  
3  
4  
5  
6  
7  
import org.joml.Matrix4f;
public class Test {
  public static void main(String[] args) {
    Matrix4f m = new Matrix4f().zero().identity();
    System.out.println(m);
  }
}

and adding a sysout call to both the MemUtilNIO.identity() and the MemUtilUnsafe.identity(), show that the MemUtilUnsafe.identity() gets called and no class/module loading errors occur, when invoking java.exe like so:
> "C:\Program Files\Java\jdk-9\bin\java.exe" -cp joml-1.9.0-SNAPSHOT.jar;bin/ Test

where bin/ contains the Eclipse-compiled Test class.

If you feel that there indeed _is_ an issue, please open a GitHub issue with a reproducible test case.
Pages: 1 [2]
  ignore  |  Print  
 
 

 
Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5545 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4585 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4016 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!