Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5] 6 7 ... 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 39513 times)
0 Members and 1 Guest are viewing this topic.
Offline kaffiene
« Reply #120 - Posted 2012-09-06 11:25:14 »

I've never looked at JNA...if it's just a wrapper for JNI, then it doesn't address the real problem.  Don't get me wrong, cleaner is good...but the cost of going across the boundary is the problem.

It may not work for you, but the GNU java compiler had fast c/c++ interface 'cause it treated Java like any other compiler source.  Trouble is that they didn't implement much of the Java common libraries.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #121 - Posted 2012-09-06 12:08:52 »

The problem with JNI is not java strict definitions of types, but rather C very sloppy definition of everything. Marshling types between langs is never as easy as it looks.

However i though that direct byte buffers fix a lot of this? I don't see and performance issues with calls in my opengl, i am always fill/vertex limited long before call overhead is an issue.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline nsigma
« Reply #122 - Posted 2012-09-06 13:22:55 »

Going around in circles here - I think I mentioned JNA on page 2!  Wink

@princec - this kind of syntax is pretty much what JNA gives you, along with the ability not to have to cross-compile stubs for different platforms.  It's a better JNI on the user side by far, but it's still a wrapper to JNI so doesn't get over the issues of how heavyweight that may or may not be.

@Roquen - meant to ask this back on page 2 when you or someone else mentioned it - any links to discussions on JNI replacements for Java core?  Faster JNI then everyone wins, including all those nice syntax wrappers like JNA.

@Oskuro - got an example of what you were trying to do?  There shouldn't be much if anything that JNI gives you that JNA can't.

i am always fill/vertex limited long before call overhead is an issue.

+1  I doubt that any Java -> native boundary cross is going to have zero overhead, so I would suggest that 99% of the time if JNI is the bottleneck you're crossing the boundary too much.  persecutioncomplex

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #123 - Posted 2012-09-06 13:25:38 »

No I have no real information.  It's just be talked about in a hand-waving manner in some of the recent "future directions" presentations...you know all PR no content kind-of-thing.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #124 - Posted 2012-09-06 13:31:46 »

I timed it once, years ago on a Celeron 300 I think - the overhead of a basic Java->JNI call jump is in the order of hundreds of nanoseconds. This means you have to do an awful lot of them before you actually notice the overhead.

Cas Smiley

Offline Roquen
« Reply #125 - Posted 2012-09-06 13:35:58 »

(To be honest I haven't timed the boundary since probably JDK5...so I might be full of poop.)
Offline sproingie

JGO Kernel


Medals: 202



« Reply #126 - Posted 2012-09-06 14:34:12 »

JNA is not a wrapper around JNI.  It's a wrapper around libffi, or at least its moral equivalent.  It might use JNI to interface to that, but after that, JNI is not involved.  Since it's always using dynamic libraries with dlopen/LoadLibrary, it's always going to be a bit slower than JNI.

The overhead of JNI isn't so much the call overhead as the defensive copying or locking it has to do.
Offline Spasi
« Reply #127 - Posted 2012-09-06 15:30:20 »

I wrote a benchmark to measure JNI overhead last year, here are the results on jre7u7, Sandy Bridge 3.1GHz, Win7:

1  
2  
3  
glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS, buffer); // 23ns server, 27ns client
glColor4f(1.0f, 1.0f, 1.0f, 0.0f); // 16ns server, 17ns client
glDepthMask(true); // 11ns server, 13ns client


These times include everything in the call (Java, JNI, driver). IIRC on Linux I had seen times below 10ns (on slower CPU, etc). I think JNI overhead is simply noise in a desktop environment. Things are much worse on ARM CPUs, though that depends on the JVM implementation (hint: you want to use Oracle's).
Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #128 - Posted 2012-09-06 16:03:53 »

[snip...]though that depends on the JVM implementation (hint: you want to use Oracle's).
Could you please explain how you wrote that benchmark? And also, is the OpenJDK slower? Did you test that? How slow is it :X (I hope it's not slow)

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Spasi
« Reply #129 - Posted 2012-09-06 16:17:24 »

Here's the code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
import org.lwjgl.BufferUtils;
import org.lwjgl.LWJGLException;
import org.lwjgl.opengl.Display;

import java.nio.IntBuffer;

import static org.lwjgl.opengl.GL11.*;
import static org.lwjgl.opengl.GL20.*;

public class JNIPerfTest {

   private JNIPerfTest() {
   }

   public static void main(String[] args) {
      try {
         Display.create();
      } catch (LWJGLException e) {
         e.printStackTrace();
      }

      final int DURATION = 1024 * 1024;
      final int WARMUP = 5 * DURATION;
      final int BENCH = 10 * DURATION;

      benchmark(WARMUP, BENCH);
   }

   private static void benchmark(final int WARMUP, final int BENCH) {
      final IntBuffer buffer = BufferUtils.createIntBuffer(16);

      innerLoop(buffer, WARMUP);

      long time = System.nanoTime();
      innerLoop(buffer, BENCH);
      time = (System.nanoTime() - time) / BENCH;

      System.out.println(time);
   }

   private static void innerLoop(final IntBuffer buffer, final int duration) {
      for ( int i = 0; i < duration; i++ ) {
         glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS, buffer);
         //glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS);
        //glDepthMask(true);
        //glColor4f(1.0f, 1.0f, 1.0f, 0.0f);
     }
   }

}


I forgot to mention that I tested with the server VM. I updated my previous post with times on the client one. I haven't tested on OpenJDK, but it should have similar performance.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #130 - Posted 2012-09-06 16:33:21 »

JNA is not a wrapper around JNI.  It's a wrapper around libffi, or at least its moral equivalent.  It might use JNI to interface to that, but after that, JNI is not involved.  Since it's always using dynamic libraries with dlopen/LoadLibrary, it's always going to be a bit slower than JNI.

Pedant!  Tongue  Yes, JNA is a JNI based wrapper to libffi (a forked version from memory).  Not exactly sure what you mean by JNI is not involved after that - JNI is involved in every call.

If you're sensible about not doing too much of the auto-magic stuff, speed of a call is 2x-3x that of direct JNI.  That's still noise!

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Spasi
« Reply #131 - Posted 2012-09-06 17:53:40 »

On topic, I highly recommend keeping an eye on Kotlin. It fixes A LOT of issues I have with Java (many mentioned in this thread), without becoming a monstrosity of a language like Scala. It also has a strong focus on performance which is ideal when developing games and you need a modern language to work with. If anyone has decompiled Scala code will know what I mean.

I've also done several tests with JDK8 and lambdas and I can honestly say that, unlike generics in 5.0, they got everything right. It's a huge improvement over how we write code now. But Java (the language) is too slow moving, any way you look at it. Many will argue that it's a good thing, but with invokedynamic I think it's only a matter of time before another language becomes the first choice for JVM development.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #132 - Posted 2012-09-06 18:11:34 »

I'll keep an eye on Kotlin, but I'll come back when it actually implements pattern matching.  Right now it's nothing but instanceof checks with no actual patterns to be found.

The documentation also seems to imply Option is nothing but typesafe null, and that makes me wonder if they'll recognize the utility of monads the way C# has.  With a for-comprehension or a LINQ select, I can use the same code to deal with failure synchronously or asynchronously, with or without error messages, with or without alternatives.  I just change the type that goes in, and my flow control logic itself is all polymorphic.

I'm all for "let a thousand languages bloom", but I have little use for ones that throw away perfectly good theory with a proven track record.
Offline Roquen
« Reply #133 - Posted 2012-09-06 19:10:38 »

I've the impression that a fair amount of resources are being devoted to "other languages" on the JVM.  This is a good call as java is moving slowly and this strategy should aid draw more users.  More users = more contributors = JVM moves faster = win.
Offline Roquen
« Reply #134 - Posted 2012-09-06 19:17:06 »

BTW: I dug up one of the hand-waving presentations.  "To Java SE 8, and Beyond!"
Offline kaffiene
« Reply #135 - Posted 2012-09-07 01:16:54 »

On topic, I highly recommend keeping an eye on Kotlin. It fixes A LOT of issues I have with Java (many mentioned in this thread), without becoming a monstrosity of a language like Scala. It also has a strong focus on performance which is ideal when developing games and you need a modern language to work with. If anyone has decompiled Scala code will know what I mean.

I've also done several tests with JDK8 and lambdas and I can honestly say that, unlike generics in 5.0, they got everything right. It's a huge improvement over how we write code now. But Java (the language) is too slow moving, any way you look at it. Many will argue that it's a good thing, but with invokedynamic I think it's only a matter of time before another language becomes the first choice for JVM development.

I like what I see in Kotlin - like Scala, it has nice features that Java doesn't.  Unlike Scala, it doesn't add a whole new area of complexity (Scala's type system)

I'm largely happy enough with Java.  By and large I don't find language features are stopping me produce code - it's usually time and motivation that are the real issues :o)  

By way of comparison, I dropped C++ when I realised I was spending too much time chasing memory leaks, circular dependencies, dangling pointers and other problems of the past which have been well and truly solved.  This is my basic issue with Java++ languages - Kotlin has some nice ideas but I doubt it's going to greatly increase my coding efficiency, whereas the C++ to Java switch really paid off in terms of time not wasted.


 
Offline i30817

Junior Member





« Reply #136 - Posted 2012-09-07 07:22:06 »

@OP I really see no problem with var args, they are convenient in some select situations.

I never said that there is a problem with the idea, just the implementation. Using the efficiency of arrays for a 1-100 arguments magnitude is just loony.
That a array introduces problems with generics, is not lazy (and this and the previous express the erasure problem and requires copies) and can be altered inside the method (uselessly by the way, since the type is constructed a runtime in both cases, and probably harmful for code clarity if you use it as a tmp) is just the cherry of crazy on top.
Not to mention that collections are infinitely more flexible when ordering matters.

The only 'advantage' i can see is that a array is very amenable to get into cpu cache, but a varargs iterable built over a array probably would too, not to mention that the varargs arguments by necessity tend to be a small amount (or a actual array).


Also i wish java had made the Collections library have full immutable type interfaces (not super of mutable ones), so that libraries don't need no steenking copies.

Rust has some ideas here (the freeze concept applied to the type system is probably a better idea than a simple type because you can thaw, add stuff and freeze as a 'protocol type' without any copies on both sides of the client-api border. Not sure how it deals with concurrency).
Offline kaffiene
« Reply #137 - Posted 2012-09-07 07:38:19 »

@OP I really see no problem with var args, they are convenient in some select situations.

I never said that there is a problem with the idea, just the implementation. Using the efficiency of arrays for a 1-100 arguments magnitude is just loony.
That a array introduces problems with generics, is not lazy (and this and the previous express the erasure problem and requires copies) and can be altered inside the method (uselessly by the way, since the type is constructed a runtime in both cases, and probably harmful for code clarity if you use it as a tmp) is just the cherry of crazy on top.

The only 'advantage' i can see is that a array is very amenable to get into cpu cache, but a varargs iterable built over a array probably would too, not to mention that the varargs arguments by necessity tend to be a small amount (or a actual array).


Also i wish java had made the Collections library have a full immutable type interfaces (not super of mutable ones), so that libraries don't need no steenking copies.

Rust has some ideas here (the freeze concept applied to the type system is probably a better idea than a simple type because you can thaw, add stuff and freeze. Not sure how it deals with concurrency but Rust is a very complex language in pointer types).

See, I don't understand someone programming in Java complaining about the lack of lazy sequences.  If you want lazy sequences, use Haskell.  Java programmers would expect a common Java idiom to be used for varargs, and an array is pretty common for Java.  Don't you think that a Lazy sequence would have been a surprising choice for most Java devs?
Offline i30817

Junior Member





« Reply #138 - Posted 2012-09-07 07:42:13 »

I'm saying that arrays not being the good choice for the type of varargs was utterly predictable in the face of generics and the well known limitations that the type erasure workaround brought to the table - especially if you needed to transform the array. This is where lazyness (not infinite sequences) is a advantage by not requiring allocation of a new array to iterate over a 'new' sequence. By specifying the runtime type of ... as a array they mandated that any transformation that is used as input to ... needs to return [].

That you're telling that i should be 'using Haskell' doesn't make it any less the wrong choice. Common idiom? Surely less than collections, which are all iterable. Make arrays iterable too by VM wizardry for all i care.

Meanwhile, every 'framework' api in java 7 and 8 is deprecating all the array methods they can get away with in favor of generic collections (swing for instance). Terrible planning, left hand doesn't know the right stuff.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #139 - Posted 2012-09-07 08:31:21 »

I don't think that using varargs for methods that perform a transformation is their intended usage, nor is it good programming practice.

Arrays should definitely implement Iterable though.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline nsigma
« Reply #140 - Posted 2012-09-07 10:10:37 »

I like varargs being arrays inside the method - my pet hate is that it shouldn't be possible to pass in an array to the call.  For a library writer it means you still have to check for null or defensively copy the array, even when 99% of the time that isn't required because the array has just been created for you!  Angry

BTW: I dug up one of the hand-waving presentations.  "To Java SE 8, and Beyond!"

My hyperbole meter just blew its mountings!  Wink

I read the "removing JNI boilerplate" (which is also a pet hate) as bringing something like JNA into core - ie. a direct binding through something like libffi / dyncall.  I may be completely wrong with that!

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #141 - Posted 2012-09-07 10:26:49 »

All these spinoffs of Java like Kotlin and Scala all share one particularly irksome trait, which is that they keep changing things for the sake of changing things. Eg. removal of semicolons to terminate statements, the use of the word "fun" to introduce a function declaration when we already have a way. Why can't someone make Java++, where all the lexical bits of Java are preserved and all the annoying unneccesary syntax that bothers us is fixed.

The things I'd off the top of my head which would make it so I had to type less crap are:
1. scoped access modifiers for fields eg. public { .... }
2. automatic casting eg. Object x = .... ; String y = x; // no need to write narrowing cast as it HAS to be a String to run
3. all the little things in Coin I've been waiting for like ?.
4. iterable arrays
5. that nifty default implementation thing for interfaces
6. structs. Haha.
7. interface methods to actually have access modifiers that work
bonus 8. pre and post conditions ("DBC beyond a simple assertion feature")

Cas Smiley

Offline nsigma
« Reply #142 - Posted 2012-09-07 10:34:36 »

@princec - Mostly totally with you there!  Don't like 2 though - recipe for disaster if you ask me.  And not sure what you want from 4?

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #143 - Posted 2012-09-07 10:45:22 »

#2 - can you concoct a real example with a disaster in it?
#4 - I just wanted the array type to implement Iterable, so I can at least pass in arrays to functions that want Iterables.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #144 - Posted 2012-09-07 10:47:32 »

Has no-one done a solution to 8 using annotations and annotation pre-processing? Sounds like the kind of thing that could be done without a core language change.

Edit: Anyone tried OVal?

1  
2  
3  
 // mailingAddress must either be the delivery address or the invoice address 
 @Assert(expr = "_value ==_this.deliveryAddress || _value == _this.invoiceAddress", lang = "groovy")
  public String mailingAddress;


I guess that means you can go crazy with annotations and have them validate at compile and runtime, then turn them off for 'release' builds?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline nsigma
« Reply #145 - Posted 2012-09-07 11:06:43 »

#2 - can you concoct a real example with a disaster in it?

It depends what the other side of that Object x = ... statement, and whether you can be certain it's always a String (and if so, why not assign it to String or just reverse the assignments?).  I like the fact that you have to be explicit about narrow casting so it's explicitly treated as different to normal assignment.  And if you're not 100% it should probably be wrapped in an instanceof check or possibly a try / catch.

#4 - I just wanted the array type to implement Iterable, so I can at least pass in arrays to functions that want Iterables.

Ah, makes sense, though it's not hard to use a wrapper if you really need it. 

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #146 - Posted 2012-09-07 11:28:36 »

It depends what the other side of that Object x = ... statement, and whether you can be certain it's always a String (and if so, why not assign it to String or just reverse the assignments?).  I like the fact that you have to be explicit about narrow casting so it's explicitly treated as different to normal assignment.  And if you're not 100% it should probably be wrapped in an instanceof check or possibly a try / catch.
It made sense in C++ where you can basically turn anything into anything else but in Java it's enforced at runtime. At compile time I'm being therefore forced to make a redundant assertion. I can't see a class of mistakes that it prevents. The compiler will still complain if you attempt a cast that is illegal eg.
1  
2  
String x = ...;
char[] y = x; // Compile error just the same as if you tried char[] y = (char[]) x;


Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #147 - Posted 2012-09-07 11:45:35 »

Note sure I agree. Casts in java are operations, while in C/C++ they are more "pretend these bytes represent this, rather than what i said it was previously". They really change things. I like compilers to catch things rather than just rely on run time errors.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #148 - Posted 2012-09-07 11:59:18 »

That's what I'm saying... compiler already catches anything actually illegal, and then you're just forced to type a cast unnecessarily beyond that. In the same manner that <> means "just use the right signature to make this generic work", I'm saying, just use the right cast to make this compile.

In the same vein as null deference analysis a decent compiler implementation could even be told to warn or error when it can infer the cast cannot possibly be made, or even if the cast is not guaranteed succesful at runtime through inference. Either way, I'm fed up of polluting the simplicity of the meaning of my code with bloody casts. At least generics have removed some of them.

Cas Smiley

Offline nsigma
« Reply #149 - Posted 2012-09-07 12:13:14 »

That's what I'm saying... compiler already catches anything actually illegal, and then you're just forced to type a cast unnecessarily beyond that. In the same manner that <> means "just use the right signature to make this generic work", I'm saying, just use the right cast to make this compile.

As delt0r said, we're talking about an operation.  A standard or widening assignment doesn't cast the object so can't throw a ClassCastException; a narrowing one can.  The semantics are different, so the syntax being different is a good thing in my opinion.  Simplifying syntax good - increasing the scope for breaking things in the process less so.


Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Pages: 1 ... 3 4 [5] 6 7 ... 10
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (21 views)
2014-09-12 09:08:26

Norakomi (55 views)
2014-09-10 13:57:51

TehJavaDev (66 views)
2014-09-10 06:39:09

Tekkerue (33 views)
2014-09-09 02:24:56

mitcheeb (54 views)
2014-09-08 06:06:29

BurntPizza (38 views)
2014-09-07 01:13:42

Longarmx (24 views)
2014-09-07 01:12:14

Longarmx (30 views)
2014-09-07 01:11:22

Longarmx (28 views)
2014-09-07 01:10:19

mitcheeb (37 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59: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!