Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (636)
Games in Android Showcase (178)
games submitted by our members
Games in WIP (687)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 4
1  Game Development / Performance Tuning / Re: Need help optimizing to get rid of stutterings. on: 2006-01-24 15:05:54
Dump the CompileThreshold Smiley  Plus you might want to try using -server and see if that helps...
2  Java Game APIs & Engines / Java 2D / Re: font rendering performances on: 2006-01-18 18:03:57
Thanks for the crash log.

# Problematic frame:
# j  java.lang.StrictMath.log(D)D+0

It looks like it died in the VM, not in the libraries.

Could you please try to see if you can reproduce it with -server (or with -client if
you're running with server already)?


  That's weird, a crash in client in intrinsic code when client hasn't changed much, and definitly there were no changes between update 5 and update 6.  Very, very weird...  I'm going to try to reproduce this, but I don't have access to a Windows machine  so this may take some time.  If you can reproduce this with a debug build this would help alot.  Thanks.

3  Game Development / Performance Tuning / Re: What are the Default Heap Sizes? on: 2005-11-15 19:13:52
I have always wished Java had the ability to specify multiple heaps, at runtime, with individual garbage collectors. Ah well. Maybe in Java 50 Cheesy

Cas Smiley

What would you do with multiple heaps?
4  Game Development / Performance Tuning / Re: What are the Default Heap Sizes? on: 2005-11-15 03:25:00
Its different based on hardware architecture, OS, and compiler but here are some general numbers:

MaxHeapSize= 64m
NewSize = 640k
PermSize = 12m
MaxPermSize = 64m

You can look up most of this info in the source code, its all in src/share/vm/runtime/globals.hpp and src/cpu/<arch>/vm/globals.hpp (or c1_globals_<arch>.hpp

5  Game Development / Performance Tuning / Re: New C1 in Mustang b59 on: 2005-11-14 14:53:51
Azeem ! Is the SSE2 support  for AMD64 fully complete in the compiler ? IIRC, not long ago, you said something to the effect that it wasn't (in the server compiler).

SSE2 support for AMD64 is fully supported under AMD64.  There's no SIMD/Auto vectorization support yet
6  Game Development / Performance Tuning / Re: New C1 in Mustang b59 on: 2005-11-11 21:25:06
OMG, it has SIMD support, i been waiting for that for years, java is really starting to kick ass, thats another advantage we now have over native compiled languages Smiley

It has SSE instruction support, but no SIMD support
7  Game Development / Performance Tuning / New C1 in Mustang b59 on: 2005-11-11 15:10:13
The client compiler has been updated in Mustang B59, give it a whirl!  New things include:

- Linear Scan Allocator
- SSE/SS2 support
- SSA form
8  Game Development / Performance Tuning / Re: JumpTables on: 2005-10-20 14:25:55

Thanks, I'll play with that.

Just one more question:
Why is there even a lookup switch? Isn't a JumpTable always faster?

Lookup switch is a bytecode representation of your switch statements. 
9  Game Development / Performance Tuning / Re: JumpTables on: 2005-10-19 15:28:25
But overall, I'm impressed!

Thanks!  You can play with the flags to change how large the switch statement has to be before Jumptables are used.  The flag is -XX:MinJumpTableSize=
The default is at 16, you can try smaller but I've found 16 to be about the right size.
10  Game Development / Performance Tuning / Re: JumpTables on: 2005-10-18 17:43:24
Correct, the bytecodes generated from a switch statement can either be a tableswitch or a lookupswitch (depending on size, sparseness,etc).   The previous implementation would create a binary search tree to calculate which branch of the switch statement to take.  The Jumptable implementation creates a table in the constant section of the generated code, and in most cases its just a load address of the base of the table, calculate the index and jump to the new destination.  The larger the table, the faster the implementation.
11  Game Development / Performance Tuning / JumpTables on: 2005-10-04 20:37:47
In case anyone is interested, JumpTables made it into Java6 B55 (should be available wednesday or thursday).  If you have large switch statements this should help a bit.  Give it shot and report any bugs.  Thanks.

Mustang bits at:
12  Game Development / Performance Tuning / Re: GC Bomb - CMS GC starves high priority system threads on: 2005-10-04 15:34:38
It is fixed in 1.5.0_06 Smiley
13  Game Development / Performance Tuning / Re: Compiler / GC stalls on: 2005-09-20 14:42:58
Try -XX:CompileThreshold=500

Cas Smiley

I recommend against that, all that's doing is increasing the number of compiles and probably going to increase the stuttering.  You might try -Xbatch to disable background compilation.   
14  Game Development / Performance Tuning / Re: Server and client optimalizations on: 2005-09-14 15:02:58
Could just run the compiler constantly in the background with an Idle priority thread...

Cas Smiley

Both compilers have background compilation (what you describe above).  The Server compiler has 2 threads, while the Client compiler has 1 (and for various reasons can't have more).   
15  Game Development / Performance Tuning / Re: Concrete benefits of SSE and SSE2 instructions in Java on: 2005-09-14 15:01:11
Alright so they aren't FPU registers Smiley  I think of them as that, but your right you can put anything you want in them.
16  Game Development / Performance Tuning / Re: Server and client optimalizations on: 2005-09-14 14:59:21
But there are other threads that are running in the background besides the compiler thread.  GC, user threads, interpreter, etc.  It would require a lot of effort to figure out that *nothing* is going on, and then force compiles.  One idea that I've had (it was my master's thesis actually) was to compile methods as logical units rather than discrete ones.  It required keeping track of methods that were invocated together in the interpreter, and when one of those methods was compiled, the whole logical unit was compiled.  Startup suffered, but the advantage was more things got compiled, and GUI apps improved the most (I think it was something like 10% on SwingMark). 
17  Game Development / Performance Tuning / Re: Concrete benefits of SSE and SSE2 instructions in Java on: 2005-09-08 16:18:37
Sorry but according to wikipedia SSE and SSE2 are actually SIMDs:

Right, but the VM doesn't use the SIMD portion of SSE/SSE2.  You can use SSE/SSE2 registers and instructions on single data.
18  Game Development / Performance Tuning / Re: Concrete benefits of SSE and SSE2 instructions in Java on: 2005-09-07 19:35:38
SSE and SSE2 instructions are used on single data (so no SIMD stuff here).  The biggest advantages are as follows (at least for the VM)

- More registers (albeit single and double precision fpu registers)
- Don't use the FPU stack (except for trig/transcendentals)

Those above alone are worth quite a bit on FPU heavy programs.  Easing of register pressure especially on register starved Intel CPUs is a big win.
19  Game Development / Performance Tuning / Re: Passing values to/between arrays on: 2005-06-02 20:46:37

Im pretty sure its done bounds check hoisting for quite awjhile.  Thats not a hard optimization.  But I can ask someone to make sure.

No Client does not do any bounds checking hoisting or removal...
20  Game Development / Performance Tuning / Re: problem with currentTimeMillis() on: 2005-05-23 02:32:34
Just hit this problem on jdk1.5.0, and I'm extremely disappointed.

Thread.sleep( 20 ) now consistently sleeps for 31ms on my Sempron machine. I remember seeing similar behaviour on much earlier JVM versions.

In my opinion this is quite unacceptable for a bug of this magnitude to be present in any JVM release. I fail to see how Java can provide serious competition to .NET as a desktop platform with performance like this.

Is this Windows?  Because Windows does not provide very granular sleep, try the same application under Linux and you should see 20ms sleep times.
21  Game Development / Performance Tuning / Re: future jni optimisations on: 2005-05-05 18:38:16
It's obvious he's a typical PHdr. Lots of abreviations that he believes everyone must know.
So a little education. Because here are game developers, the most common cases for these are:

PC - player character.
IR - infra red (aka IR laser, or IR matrix based homing AA missile)
CAS - that weird things in memory. You know that option from BIOS CAS before RAS, Right? (of course someone might have even Close Air support on the mind, but it's clearly not this case.)

sp - looks like it means stack pointer.

You're probably being sarcastic, but just in case:

PC = Program Counter = a hex number that a computer keeps so that it knows where in the code it is.  
IR = Internal Representation = A half way point between source and assembly.  Most Compiler optimizations are done to the IR
CAS = Compare And Swap = An atomic operation (it will happen without external interference), that' s used to grab locks/mutex/semaphore.  

22  Game Development / Performance Tuning / Re: -XX:+PrintCompilation - What's a zombie? on: 2005-04-26 03:06:51

What exactly does that mean?

Its a method that has been compiled (nmethod, or native method) that is been marked not entrant (enterable) for whatever reason.
23  Game Development / Performance Tuning / Re: -XX:+PrintCompilation - What's a zombie? on: 2005-04-25 18:07:34
Ahh ok, so here's what happened.  A Zombie method is one that is no longer entrant.  When this happens a native method can be swept by the GC and cleaned up.  The reason it's showing up now, is that the PrintCompilation code was cleaned up to show more information including the "made zombie" bit.  The actual code has always been there, but it's just being displayed as of a few builds ago.  Hope this helpes
24  Game Development / Performance Tuning / Re: -XX:+PrintCompilation - What's a zombie? on: 2005-04-24 03:20:52

So it seems the zombies are given life again and then made back into zombies.
Maybe a "zombie" is simply excluded from further consideration for a while so HotSpot can focus on other methods?  I.e. maybe the method is a little too much of a "hot spot" and is dominating the time spent by the HotSpot optimizing code with little actual gains?  Just a guess.

Nah it's nothing like that, I'm not positive what the "make zombie" is but I'll check when I get to the office Monday
25  Game Development / Performance Tuning / Re: And yet another program test on: 2005-04-05 19:39:59
Ok lets run this on a mondern SPARC instead of a 10 year old one Smiley

2xUltraSparc IIIi 1.2Ghz, 2gb Memory.

First tier of memory 761
Second tier of memory 6547
fpf finish 4066
vector calculations finish 47443
Thread allocation 21
Thread starting 229
Thread finish 506
Write file 11190
Seek in file 516
Nio write file 8625
Nio seek in file 481

Run with -Xmx1000M
26  Game Development / Performance Tuning / Re: And yet another program test on: 2005-04-04 16:08:11

Ultra 80, 4 x 450 UltraSparc II, 4gb memory, Solaris 10
First tier of memory 963
Second tier of memory 5491
fpf finish 10560
vector calculations finish 113516
Thread allocation 47
Thread starting 260
Thread finish 504
Write file 17898
Seek in file 1692
Nio write file 4427
Nio seek in file 1848

Run with JDK1.5 -server -Xmx1000M
27  Game Development / Performance Tuning / Re: Escape Analysis on: 2005-03-26 21:30:05
<--- I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?

Cas Smiley

Can you give me some numbers?  Say against Java5, how much of an improvement do you see in your apps?  
28  Game Development / Performance Tuning / Re: floating performance,  Take II on: 2005-03-23 13:49:38

Recent CPU also support SSE and perhaps SSE2 which provide float and double width computation respectively. The SSE instructions are much faster, even for scalars. The lastest JVM will use SSE and (I think) SSE2 where available.

Correct, we use SSE/SSE2 instructions where useful/available.  The biggest advantage though are those extra registers.  Intel is definitly register starved with 8 registers, and if your doing FP calculations, those extra XMM registers relive register pressure and prevent spills
29  Game Development / Performance Tuning / Re: floating performance on: 2005-03-15 03:25:00

The important bits here would be in things like software blitting loops and that sort of thing, that is native anyway (I assume).   But to be honest that is where going to assembler would make a lot of sense.  Coding software blits, stretches etc.  should be done in vectorized code... hand tuned SSE2 and the like.  

Those sorts of optimizations take a lot of time and only help a small portion of the user population.  We're more interested in general overall performance, and writting hand tuned SSE2 for anything is a lot of work.  Don't worry, we're working on some cool stuff to help out with performance issues.
30  Game Development / Performance Tuning / Re: floating performance on: 2005-03-14 14:30:48

In any case the performance of the C++ compiler used to compile a JVM is probably not as important as it is in other applications --- hopefully most of the time will be spent in code generated by the JVM (which will be the same regardless of the C++ compiler used).

Correct, the JVM spends most of its time in generated code.  We've upgraded the Solaris C++ compilers several times over the past couple of years, and we've never seen any substantial improvements in performance for the VM.  Oh and the new Sun C++ Compilers for Solaris (SS10) are better than the Intel C++ compilers for the X86 Smiley
Pages: [1] 2 3 4
Dwinin (70 views)
2015-11-07 13:29:08

Rems19 (80 views)
2015-10-31 01:36:56

Rems19 (72 views)
2015-10-31 01:32:37

williamwoles (106 views)
2015-10-23 10:42:59

williamwoles (92 views)
2015-10-23 10:42:45

Jervac_ (106 views)
2015-10-18 23:29:12

DarkCart (134 views)
2015-10-16 00:58:11

KaiHH (116 views)
2015-10-11 14:10:14

KaiHH (155 views)
2015-10-11 13:26:18

BurntPizza (169 views)
2015-10-08 03:11:46
Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48

Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11 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‑
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!