Profiling Xith memory usage

Engines, Libraries and Tools Xith3D Forums
#5

@Jani: Yes, I always use tempory Transfrom3D() objects which aren’t being destroyed and re-created when a model is being translated/rotated.

@Abies: Ah, so you suggest to use Kenji Hiranabe’s Vecmath. Good hint, I’ll try that.

In a thread here in the forum you quoted an URL to a slightly modified version of this improved Japanese Vecmath. (Inside the Zip there’s a Readme file but the URL to the original Japanese Web site doesn’t work anymore…)

Since you and Yuri say that the slightly modified Japanese Vecmath is good to use with Xith3d: maybe William should replace the Java3d Vecmath on the Xith3d download site with the improved one?

#6

In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I’ll try to prepare version with just bugfixes/missing Tex4f.

#7

[quote]In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I’ll try to prepare version with just bugfixes/missing Tex4f.
[/quote]
Thanks a lot! :slight_smile:

With your current Vecmath version the full GC does occur a little rarer on my example jnlp with 100 rotated objects (mentioned in my first post). However a full GC still occurs every ~7 seconds when all 100 objects are visible.
Well, that’s an improvement compared to the full GC occuring every ~3 seconds with the original J3d Vecmath.

{Edit}: Inspired by the thread named “RFE: SERVER jvm into JRE” I’ve run the same test program with 100 rotating objects with the -server VM switch on Windoze, and voila: when the program runs for 2-3 seconds and is “warm”, the full GC just occurs every ~3 minutes or so, which is a lot better. So it’s not a real problem for my test program anymore. (I’m using Abies’ japanese Vecmath.)

#8

Is there any way that floats could be used instead of doubles, or is Xith intended to be a general purpose scenegraph rather than a games scenegraph?

Cas :slight_smile:

#9

[quote]Is there any way that floats could be used instead of doubles, or is Xith intended to be a general purpose scenegraph rather than a games scenegraph?
[/quote]
From a user’s point of view Xith uses just floats. Internally mostly, too.

{Edit} Xith FAQ #8

[quote]9. Why do none of the methods accept doubles like Java3D did?
Since the underlying graphics hardware only supports floats - a design decision was made to only use floats for all method calls in Xith3D.
[/quote]
PS: However there’s some talk in the forums that today on modern machines the difference between using doubles and floats (all done on the co-processor) doesn’t mean a big performance problem anymore… isn’t it?

#10

There is a noticeable difference if you start to think about more complicated operations - especially square root. Not that java has float sqrt anyway…

BTW, have you noticed that there is sqrt(x^2+y^2) operation hardcoded in 1.5 Math class ? This can probably map directly to some SSE/etc opcodes…

#11

It is available at
http://nwn-j3d.sourceforge.net/xith3d/vecmath.zip

It turned out that after removing my row/column major changes, only difference is one small optimalization in GMatrix and added Tex4x classes.

#12

[quote]It is available at
http://nwn-j3d.sourceforge.net/xith3d/vecmath.zip

It turned out that after removing my row/column major changes, only difference is one small optimalization in GMatrix and added Tex4x classes.
[/quote]
Thanks.

One small problem still: the alternative Vecmath reports an an error message when you try to use the clone() method. It says:
clone() has protected access in java.lang.Object

So when you have got a Point3f object namend thepoint and used
Point3f new = (Point3f) thepoint.clone();
this doesn’t work anymore.

OK, you could use
Point3f new =new Point3f(thepoint);
… but for the sake of full portability I think it would be nice to have the clone method working with the new Vecmath, too. What do you think?

#13

I think it is just a problem of adding Cloneable interface to TupleXY. I’ll do it tonight.

#14

[quote]I think it is just a problem of adding Cloneable interface to TupleXY. I’ll do it tonight.
[/quote]
Yes. Additionally we would have to overwrite the protected clone() method with a public one I think. For example something like this seems to work…:


public abstract class Tuple3f implements Serializable, Cloneable
{
  ...

  /**
   * @return  Binary copy of object
   */
  public Object clone()
  {
    try {
      Object copy = super.clone();
      return copy;
    }
    catch (CloneNotSupportedException ex) {
      System.err.println(ex);
      throw new RuntimeException(ex);
    }
  }
}
#15

Considering the coming Java gaming contest, I’d like to ask again about the state of Xith memory usage.

Does anyone have ideas if Xith’s memory management can be fixed in a month or so? Theres plenty of classes that use the dreaded new clause quite excessively and this strains garbage collector quite a lot. It slows down the performance or causes minor jerking on bigger scenes that have hundreds of objects constantly being transformed.

Again, the “hotspot” that causes excessive object creation is TransformGroup.setTransform(Transform3D), it calls various classes and does several functions, various classes create a lot of new objects and discard old values.

I tried to help a bit by giving a summary of the classes that do excessive object creation (see first mail on this thread), perhaps I might help out some more but Xith internals are new to me.

I assume someone already fixed vecmaths excessive double creation that I stated earlier?

Well, I understand that Xith is under development, anyway this is promising technology have to say!

Cheers, Jani!

#16

With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it…

#17

[quote]Y
Interesting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these “full GC delays”. Like my recent poll indicates, the Xith3d user base is still very small… as are Java interested game programmers in general. :frowning:
[/quote]
This perhaps is the cause of the jerkiness I see in almost every one of the Xith demos on the website? About one jerk per second (nb: I don’t have much RAM, only 256 and desktop linux is an evil memory hogger). The silly thing is that apart from that its smooth, it just has a regular (very small) jerk - especially noticeable on the terrain / heightfield demo.

Seeing the simple official demos run poorly on a gefroce2 @ 1ghz is enough to give anyone serious 2nd thoughts I’d think…

#18

[quote]With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it…
[/quote]
Can you tell me the people that can affect to this issue in any way? Sure the people are watching these threads also, but I’m considering to send annoying but polite :slight_smile: query for some people and ask experts opinions about this issue (how complex is it, is there plans to fix it in the near future, time estimates).

This problem definately is not on JOGL.

#19

{Edit} Now I see what you mean: small jerks, yes, they’re visible with the demos on my Winblows box, too. Maybe it’s something with their renderloops.
In a “real” application, with timed simulation & render loop, I just see jerks when many objects (100+) with transformations are inside the view. Then every few seconds I see jerks. This is due to a full GC which occurs every few seconds in the Xith transformation code. I think Jani’s memory observation explains it.

Generally these GC related jerks can be examined by tring the following: start the demos or/and your app with:
java -verbose:gc …
However with the Xith demos I can’t get it to work right now.

The Japanese Vecmath patched by Abies improves the memory consumation slightly for me.

However using the server VM solves most of my full GC problems with Xith (the jerks appears every few minutes only). However it isn’t a solution when it comes to deployment via Webstart or similar. So, like Jani, I’m too interested in this being fixed within Xith.

#20

The new 1.5 collectors rock. The -XX:MaxGCPauseMillis=nnn will tune the garbage collector automatically for you. A bit like staring at that graphical profily thing and fiddling with the old tuning parameters in 1.4 until it doesn’t jerk.

Cas :slight_smile:

#21

OK, I’ll try sometime (I’ve only been running the JWS demos so far, and I’m too busy right now to sit down for more than about 1 minute!)

I’ll have a go with 1.5beta as well, see if the same thing happens.

#22

I sincerily believe the only right solution is to get rid of these excessive object creations. I’m sure JOGL, LWJGL or jME (scenegraph also) do not act like this.

Sure you can set your -Xms -Xmx into 1gigabyte and “buy” big timewindow before first gc bang occurs, or use -incgc and tweak your garbage collector to run all the time on the background, but the overall performance suffers from this. I haven’t done benchmarks but I believe fps takes a noticeable hit because of this. I am now talking about scenes that have hundreds of objects moving.

Again, the “guilty” part is TransformGroup.setTransform() call. It does several functions and trashes memory bigtime.

I am positive that it happens, or at least in the expense of performance. Nothing changes the facts that there’s lots of work for GC to do in any case.

Last words and reasons why I started this thread:
Ok, perhaps we should remember that Xith is heavily under development and just accept the facts, I’m sure this will be corrected before v1.0 is out, I just wanted to prioritize this issue a bit more on the development queue :slight_smile:

Cheers, Jani!

#23

OK, I will try to take a deeper look at setTransform(…) nearest week. This can be non-trivial task, because of transform shader and state management is involved… but we will see.

Yuri

#24

Hi,

Now setTransform(…) on TransformGroup should produce no garbage. Please test if your apps run OK with current CVS version.

Yuri