Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Optimised direct Buffers  (Read 3866 times)
0 Members and 1 Guest are viewing this topic.
Offline chaosdeathfish

Junior Member


Projects: 1



« Posted 2005-11-09 04:29:44 »

From reading the various posts in this forum it's clear that puts and gets on some direct buffer types are converted to direct memory access instructions (at least on the server VM), and so don't suffer any JNI overhead. Apparently IntBuffer is accelerated, but ByteBuffer isn't - is that correct? And what about other types - in particular, is FloatBuffer accelerated?
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2005-11-09 11:36:43 »

Yes.


Cas Smiley

Offline chaosdeathfish

Junior Member


Projects: 1



« Reply #2 - Posted 2005-11-09 18:18:11 »

I assume you mean yes, IntBuffer and FloatBuffer are accelerated but ByteBuffer isn't? (I don't really use ByteBuffer directly much anyway, so not a problem for me).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #3 - Posted 2005-11-09 20:39:39 »

IIRC, I thought .asIntBuffer() and asFloatBuffer() operations on ByteBuffer only create a "view" of the ByteBuffer to allow you to put ints and floats in?

Thats what the javadoc says anyway  Roll Eyes

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Jeff

JGO Coder




Got any cats?


« Reply #4 - Posted 2005-11-09 22:08:20 »

FWIU Native Direct Byte Buffers should be optimised.  I believe they are the base structure for reaching native memory.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2005-11-11 03:33:26 »

All of the direct buffer classes are optimized. However ByteBuffer has both the heap-based and direct buffer subclasses loaded all the time because the core libraries use heap-based ByteBuffers. This caused calls to ByteBuffer.get() and put() to become virtual calls rather than simple machine instructions. Before Mustang HotSpot wasn't optimizing these virtual calls well, though Mustang should do better. You can generally work around this problem by downcasting your direct ByteBuffers to MappedByteBuffer outside your inner loops and operating only on MappedByteBuffer in your loops.
Offline chaosdeathfish

Junior Member


Projects: 1



« Reply #6 - Posted 2005-11-11 13:48:36 »

I'm using FloatBuffers (from ByteBuffer.asFloatBuffer), so I can't downcast to MappedByteBuffer. I'll give Mustang a go and see how fast it is. Does this mean that non-direct FloatBuffers are faster in the meantime?

Thanks
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #7 - Posted 2005-11-12 02:56:53 »

No, direct FloatBuffers should be very fast. The VertexArrayRange JOGL demo shows that you can get faster-than-C speed out of HotSpot when using direct FloatBuffers due to HotSpot's ability to generate SSE instructions at run time; most x86 executables still target the x87 FPU or have separate SSE and x87 code. Mixing direct and non-direct buffers in your application is discouraged.
Offline chaosdeathfish

Junior Member


Projects: 1



« Reply #8 - Posted 2005-11-14 20:50:09 »

No, direct FloatBuffers should be very fast.

That's what I was hoping to hear Smiley

One question though - how do these optimisations interact with debuggers/profilers when using JVMTI? I've wondered in the past if profiling my application skews the results..
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #9 - Posted 2005-11-15 01:06:11 »

Most profilers impose some amount of overhead, though if the profiler is reasonably modern it shouldn't perturb the code generated by HotSpot. The -Xprof flat profiler built in to HotSpot used to be a good low-impact profiler, but in 1.5 its implementation was changed and now it's unusably slow. I think the NetBeans profiler is currently very good. When running under the debugger, all of the code is optimized normally by HotSpot except that in which a breakpoint has been set.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Tomas

Junior Member




Agency9


« Reply #10 - Posted 2005-11-15 08:57:46 »

Mixing direct and non-direct buffers in your application is discouraged.


In general or just for JNI stuff ?

// Tomas

CTO Agency9
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #11 - Posted 2005-11-16 17:59:35 »

In general. This will become less of an issue going forward, as the server compiler can now perform efficient bimorphic call inlining and as we are heading toward a tiered system, but can currently impact performance-critical code.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2005-11-16 19:07:29 »

code generated by HotSpot. The -Xprof flat profiler built in to HotSpot used to be a good low-impact profiler, but in 1.5 its implementation was changed and now it's unusably slow.

You can say that again Sad. One reason that JGF is down so often is that I physically cannot profile it to find out where the memory leak is. Life's kind of hard with no profilers.

grumblemumblecallthisaproductionrelease?mumblegrumble

malloc will be first against the wall when the revolution comes...
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2005-11-16 23:59:21 »

On the contrary, there are plenty of commercially available CPU and memory profilers which work just fine. I've personally used JProfiler with good results, and in the past have also successfully used OptimizeIt and a couple of others. It's only HotSpot's built-in (and unspecified) profiler which has this drastic slowdown, though I agree this is a problem which needs to be fixed. For a free memory leak profiler I'd recommend the NetBeans profiler which I think works pretty well.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2005-11-17 18:55:42 »

On the contrary, there are plenty of commercially available CPU and memory profilers which work just fine. I've personally used JProfiler with good results, and in the past have also successfully used OptimizeIt and a couple of others. It's only HotSpot's built-in (and unspecified) profiler which has this drastic slowdown, though I agree this is a problem which needs to be fixed. For a free memory leak profiler I'd recommend the NetBeans profiler which I think works pretty well.


Not criticising you personally, but just to answer some of your points there, which I think are unfairly glossing over some serious issues:

1. Java ethos, platform and tools: you can get it for free. Saying "you have to pay for one of the tools you need to do java development" sits uncomfortably with that. Profiling is a fundamental platform feature: it needs to be available for free.

2. Netbeans profiling of a remote server isn't easy, whereas with -Xprof it was identical to profiling a local app. Getting a *customer* to profile with -Xprof was exceptionally easy; getting them to do it with netbeans? Ouch.

3. Replacing a core tool with an implementation that is only available in Sun's own IDE scares a lot of people. Right or wrong, most people don't use that IDE; can they expect more of the core tools to migrate to this foreign IDE in the future? Will netbeans gradually become the "only" java IDE?

malloc will be first against the wall when the revolution comes...
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #15 - Posted 2005-11-18 00:29:25 »

To the best of my knowledge, the Netbeans profiler doesn't use -Xprof, it uses dynamic bytecode instrumentation to insert probe points in subsets of the application. There is a free profiler which ships with the JDK, hprof, which works reasonably well (and better in the current version of Mustang than in previous releases).
Pages: [1]
  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.

xsi3rr4x (63 views)
2014-04-15 18:08:23

BurntPizza (61 views)
2014-04-15 03:46:01

UprightPath (73 views)
2014-04-14 17:39:50

UprightPath (56 views)
2014-04-14 17:35:47

Porlus (73 views)
2014-04-14 15:48:38

tom_mai78101 (99 views)
2014-04-10 04:04:31

BurntPizza (159 views)
2014-04-08 23:06:04

tom_mai78101 (254 views)
2014-04-05 13:34:39

trollwarrior1 (208 views)
2014-04-04 12:06:45

CJLetsGame (215 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!