But that, in a nutshell, is why I think no-one has replied yet. Not even Azeem...

Cas

I see no use for structs in an OO based langauge. Structs are data with no behavior. Where do you put the behavior? How do you control the state?

I think what you are really asking for is the ability to use the shape of an object to define structure with-in a buffer or mmap'ed area of memory. This does not require a change in Java to achieve.

I am currently activily arguing against ANY changes to the Java language specification BEFORE we fully understand the implications of the change. I'm not interested in a pro/anti generics descission as this is not the forum for it but.... I will use it as an example where the JCP jumped the gun in dropping in a flawed version of a change to the language and now that we have it, it is practically impossible to go back. I would suggest that changing a language is not something that the average programmer has enough knowledge to offer an expert opinion on how to extend a language. I, myself, do not claim to have enough knowledge to offer an expert opinion on how to extend any language. That said, what I do know is that more language features = more choice = more complexity = more problems. The thing that is wonderful about Java is that it does offer a syntax that approaches Smalltalk in simplicity but offers syntax and concepts that make is less foreign to those that need functional structures in order to work.

I wish I hadn't called them Structs now, because they are so not like C-structs at all.

Quote

I see no use for structs in an OO based langauge. Structs are data with no behavior. Where do you put the behavior? How do you control the state?

A struct in C++ is just a class like any other with every member declared public. That's not what I'm after, of course.

Quote

I think what you are really asking for is the ability to use the shape of an object to define structure with-in a buffer or mmap'ed area of memory. This does not require a change in Java to achieve.

That's dead right, but I am unable to tweak the RFE. What I want is a VM semantic. It can be implemented in pure bytecode by altering the system classloader to generate bytecode on the fly, or the VM can intrinsify it when it spots the markers, eg. extending the abstract class java.nio.Struct.

In particular I don't want to have to use getXXX()/setXXX() to access fields in the struct if I don't want to.

Quote

KEEP JAVA SIMPLE!

When you see the hairy code we have to write to do OpenGL you'll understand. The worst bit is, even though it's hairy, it's still 50% of the speed of the C version

I wish I hadn't called them Structs now, because they are so not like C-structs at all.

Well, unless I've misunderstood what I've seen... these structs to look very C like in that there is space for shape but now for methods. As for getters/setters, I guess you could opt for public instance variables. The problem that I see is that public runs counter to encapsulation. That said, we do sometimes need to violate encapsulation for performance

Quote

When you see the hairy code we have to write to do OpenGL you'll understand. The worst bit is, even though it's hairy, it's still 50% of the speed of the C version

Well, when I think back on some of the bit twiddling that I needed to do, if was one instance were OO just didn't seem to fit or at least I couldn't seems to satisfy the demands of OO and performance. Needless to say that performance needed to win and it did and OO was tossed on that particular effort. When we tossed OO, we also opted for C and FORTRAN in favor of Smalltalk (the OO choice at the time). For some reason, I just can't see myself choosing Java over C in the same situation and I am an OO bigot

In a nutshell... not as they are currently defined. But what I would champion with you is the ability of NIO to paste objects into a buffer giving that buffer structure. This is a low level feature that does have some interesting possibilities.

After you've been doing OO for a very long time you begin to realise really what OO is all about. The big wet-fish-in-the-face surprise is that the dot operator and public keyword are actually there for a reason! Who'd have thought it? Besides, I want my members private as usual, so I can still write methods that go "return Math.sqrt(x * x + y * y);"

According to some message that I just read on the Mac java-dev mailing list basic classes like ArrayList can't have the set(), get() or add() methods inlined properly due to the way the bounds check works. (Something to do with the way the out of bounds exception is thrown.)

According to some message that I just read on the Mac java-dev mailing list basic classes like ArrayList can't have the set(), get() or add() methods inlined properly due to the way the bounds check works. (Something to do with the way the out of bounds exception is thrown.)

Man, ArrayList OWNS it's iterator... you'd think bounds checking would be unnecessary in that situation. I guess it's an either on or off check :|

How about a new "sincos" method? That is, a method that returns both sine and cosine of the same angle. Such a method is useful in many situations (for example quaternion calculation). The alternative is to call Math.sin and Math.cos, but a single method would likely optimize the calculation somehow.

While searching for a better solution to achieve this, I found a piece of code that results in a very good approximation:

How about a new "sincos" method? That is, a method that returns both sine and cosine of the same angle. Such a method is useful in many situations (for example quaternion calculation). The alternative is to call Math.sin and Math.cos, but a single method would likely optimize the calculation somehow.

Except that as a whole the sincos doesn't add anything to the libraries. Not to mention that x86 would be the only platform to gain from this (having the fsincos instrution). Its just not very practical and way too specialized to have a "sincos" method.

XCHNG instruction for swapping without using a temporally variable.This means XCHNG int intor XCHNG float, floatI think XCHNG Object, Object would work too, but let it be introduced on primitives first.

GC impovements:If I know I would call some method that would be a really object generation/throwing away intensive, it will be nice to give some hint to GC. Like GC.hint(SOR_EXPECTED, GC_FRAME, 1); //small object releaseGC.hint(BIGGOR_EXPECTED, GC_FRAME, 1); //bigg object releaseGC.hint(BIGGOR_EXPECTED, GC_NEXT_METHOD, CLEAN_INSIDE) //This means next method would create a lot of garbage and cleans before return would be much better than swapping it out.And of course the favorite:GC.clean(long) //Clean it now. If you want to do any cleaning, you'd have long nanosecond (int millisecond). Return imediately if not interested.

Releasing of memory.It would be nice if JVM release some memory after 5 minutes when it had around 60 MB free, and unused for long time. Actually when you have allocated 800MB and swapped on 2GB swap it doesn't matter too much, but I might like be able to run 3 of these programs, just for testing, and then it could (will?) create problems.

And a few questions:

Are you using MMX register as a scratchpad? I mean in a PS2 way. 4096 Bytes againts 64 Bytes is a big difference, but it's handy sometimes.

How effective is arraybound test elimination? For example if you had image[a] + image[a+1] + image [a+2];image[a - 1] + image[a] + image [a+2];How many times would it check for out of bounds access?

XCHNG instruction for swapping without using a temporally variable.This means XCHNG int intor XCHNG float, floatI think XCHNG Object, Object would work too, but let it be introduced on primitives first.

How do you know it's not already used?

Quote

GC impovements:If I know I would call some method that would be a really object generation/throwing away intensive, it will be nice to give some hint to GC. Like GC.hint(SOR_EXPECTED, GC_FRAME, 1); //small object releaseGC.hint(BIGGOR_EXPECTED, GC_FRAME, 1); //bigg object releaseGC.hint(BIGGOR_EXPECTED, GC_NEXT_METHOD, CLEAN_INSIDE) //This means next method would create a lot of garbage and cleans before return would be much better than swapping it out.And of course the favorite:GC.clean(long) //Clean it now. If you want to do any cleaning, you'd have long nanosecond (int millisecond). Return imediately if not interested.

Worthless. Telling the GC what to do will not improve performance.

Quote

Releasing of memory.It would be nice if JVM release some memory after 5 minutes when it had around 60 MB free, and unused for long time. Actually when you have allocated 800MB and swapped on 2GB swap it doesn't matter too much, but I might like be able to run 3 of these programs, just for testing, and then it could (will?) create problems.

Azeem, that's a poor reason for not implementing sincos. If sincos is an instruction supported on 90% of the world's computers then you may as well add it for those that can gain performance from it. For the remaining machines, it won't make any difference.

It may be a specialist function but when it comes to performance tuning we are exactly talking about tuning for specialists.

Likewise the clamp() function - maybe not relevant today, but one day maybe intrinsifiable.

Hehe, I didn't know an fsincos instruction exists, it just seemed logical to me that a low-level sincos implementation could be optimized. Actually, the existence of such an instruction somewhat proves its usefulness.

That's why we need an SSE class that can be intrinsified on platforms that support it natively or simply implemented in tight machine code otherwise. We had something on those lines in LWJGL in the early days but, er, as we didn't know shit from shinobi we took it out

I like the idea of an SSE library, may be someone here with strong competences could start a new project on java.net...

Unfortunately, it won't be me, as i don't feel strong enough in that domain.

I like the write once paradigm of java, but there are times where it's faster to develop a multiplatform performance library than to rely on hotspot optimizations. For application using JO/LWJ GL , which already requiere .dll and .so to be bundled with, another tiny native lib compatible with the same platform base would not be harmful...

Azeem, that's a poor reason for not implementing sincos. If sincos is an instruction supported on 90% of the world's computers then you may as well add it for those that can gain performance from it. For the remaining machines, it won't make any difference.

Except I have no control over what can go into the libraries. I could file a bug and hope somebody over there would find it interesting enough to add a Math.sincos() and then I could intrinsify it. Or alternatively I could add a very contrived match that checked for a sin and cos on the same variable right next to each other. Hmmm actually that might not be hard, but its very specialized.

Hi guys, I'm open for suggestions to other improvements that might help.

If you're still interested, email me on adam at grexengine.com.

I've been gathering complaints from C++ games devs, and whittling out the few that are dependent on fundamental ops that java lacks. Personally, I'm not sure how valid many of them are - I'm happy to discuss them with you via email, and then go request more info from the individual devs wherever you want more detail / evidence / etc.

If we are talking about new APIs in the Math area, or just certain calculations to recognise and optimize... something that converts between polar coordinates and cartesian coordinates would be useful, since the current Math.tan methods only return part of the answer, but usually have calculated more... I mean the angle and radius are known internally, but only the angle is returned, and so a duplicate square root calculation might happen. Stuff like that can help in various 2D and 3D games.There was a discussion about this on Apple's performance tuning email lists recently that I found interesting.

Re: the clamping functions...

When using software loops to blend RGB image data (with Alpha), vector instructions would offer a HUGE advantage. Is there any way the compiler could recognize those types of loops? Though, I must admit it isn't worth it at all if the graphics processor can be used to accelerate the operation entirely.. so it is probably best for the Java2D guys to take care of that at a higher level.

So I guess the general purpose API to gain access to vector operations like what Cas was saying is really more important.

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