How to get nanosecond precision in java?
After searching through the forums, I realised the inaccuracy of the Thread.sleep(long millis, int nanos) method, which I used in my musical game.( Some other thread titled "try my musical game")
This could be the main reason I'm getting of tempo midi music....
Is there a workaround to it? or should I say is there a way to do it within the JDK libraries (non JNI, non Java3D, etc) or any kind of custom code that makes use of the standard libraries to be able to get nanosecond precision?
I din't really need 1 nanosec precision, but maybe in the 100 nanos.. (0.1 microsec)
thanks in advance
~Jeffrey
This question should be directed to people at sun who terribly fear the idea
of making a real compiler for java...Giving codes just what they really need and
not a lot of garbage that the JVM makes run with them.
You see, for instance, the runtime errors. The JVM, I suppose, keeps loops and addresses in your Java code to catch them, lowering the speed of your program.
If you create an extended class of "Panel" in your program, for example, the JVM will keep a lot of "hollow" calls in your "compiled" code, even if you put only a single line in a single method of your newly created class (I'm just giving an example. Suppose that one single line in one single method is enough to define your class properly).
I'm warning you guys! Take care with Microsoft and .NET cause they are taking the issue of speed very seriously.
You may not believe but I'm just trying to help...
We don't belive that you are trying to help because you didn't help.Anyway, I believe that the libraries that interface with MIDI allow you to access the MIDI heartbeat, which should be at the correct resolution for your game. Have you checked that out.
So, great guy, explain us why java programs are (anyone knows) slower!And you're right. I think I didn't help, because pride is something difficultto overcome...But I guess you know what I'm taking about. Maybe it's about your job!
Sorry.
I'm not "taking about" anyone's job. Just talking about.
And be calm. I'm not any spy of some "total quality" department.
For God's sake, I'm independent. Money is short, but independence is high.
What I said about your job, dear friend, just was: Take care with your or, in
better words: Never despise your foe...
I meant: Take care with your contender, or, in better words: Never despise yourfoe!
This question nothing to do with the speed of Java. It has to do with the precision of the System timer. Go hijack someone else's thread, this discussion has been beaten to death.
To markuskidd : I know about getting the resolutions and I read in a midi tutorial (somewhere in java.sun.com) to calculate the tick with respect to time.
Din't really find out about the heartbeat thingy you mentioned.
And actually I "created" my own syntheizer that sort of emulates the real synthesizer because of some reasons,
So this "synthesizer thread" is gong to sleep every Thread.sleep(long milli, int nanos) cycle. I have not much problems if the precision is in the millis/micros range (using XP currently) but when I hit a song with around .5 micro, it sorts of sleeps in the 1 micro range...
Perhaps you can give me a clearer idea on how to access the heartbeat?
Thanks in advance
~Jeffrey
Of course you get only results at the 1 micro time frame. That's the time
the program takes to generate one single "pulse" of your music...
So when you choose to pick up samples shorter than that, you get the same until
1 micro has passed...
But, well, it's just a matter of System timing...
Try C or C++ and you'll see if the problem remains...
use the Windows API for C and try to embed it in your Java Code.
> So, great guy, explain us why java programs are (anyone knows) slower!<sarcasm = full>Why don't you do it since you seem to know so much about it... :)</sarcasm>
First of all, I don't want to keep fighting at this forum. I just replied
some guy that said I "didn't want to help".
It seems you agree with me on Java beeing slow. That's something already.
You can see above my guessing about the reason why Java is so slow. It's slow because
the "compiled" Java Code is much bigger than an equivalent C or C++ code would be...
Java programs run into the JVM, not exactly an example of independence and code optimization. JVM procedures probably are too much for a lot of programs, and therefore just spend memory space and computing time. Maybe, as one of the participants of this forum pointed out, the "Stack Machine" orientation of Java is also a problem when people can't adapt their standard java code (which, after all, is just machine code that we call "Java") to their hardware.
If we had at least a cross compiler, we could optimize the resulting C or C++ code with one of the many optimizers available, like Intel's.
Do you disagree? Why?
P.S:
The value of Java is not based on its "Virtual O.S." approach (the JVM).
It's based on the many classes available through the use of this language, which
makes pre-compiled code much smaller and allows an easier and faster exchange of programs. And it's also based on the fact that there are Java versions for multiple OSs, which is the real factor for portability. I suppose it will never happen to the .NET plataform.
I just want a better Java. That's all.
Guess you didn't get the importance of the whole thing...
Take a look at the sleep-based timer hack:
http://www.javagaming.org/cgi-bin/JGOForums/YaBB.cgi?board=share;action=display;num=1035418761
Also, J3D has access to the high resolution timer somewhere. I would suggest you ask this question at javagaming.org, simply because there is a lot higher signal-to-noise than here.
Thanks for the link,
After doing some testing with the System.currentTimeMillis(), I realised XP's granularity is also 10 millis (ms)....
thread.sleep(1) results in 10ms or more.
and even a simple
for (int i = 0; i < 1000; i ++)// do it 1000 times
Thread.sleep(0,1); // sleep for 1 nanosecond...
results in 1041 ms !! thats so way off the mark....
I will be trying out the sleep based timer hack.
~Jeffrey
I wish I could help you more, but all of my coding so far has been able to work within System.currentTimeMillis(). For our game at josrts.org, I think that we're probably going to end up with access to the high-resolution timer through JNI. I don't whether this is important enough to you that you would consider dealing with native libraries, but the Lightweight Java Gaming Library at http://java-game-lib.sourceforge.net/ has a precision timer. They only have distrobutions for Windows and Linux at the moment though.
> It seems you agree with me on Java beeing slow. That's
> something already.
I don't agree with anything you say.
> Do you disagree? Why?
Because you think you know more than you do and give out your opinions like you're some sort of expert. Be humble my friend.
I see who really knows nothing about this subject...
Ok, guy! Go on and say whatever s... you wanna say cause I don't have
so much time to spend with you.
If you can't explain why I'm wrong (and I'm not saying I'm an expert, You're
trying to make people say YOU ARE one!) logically and directly, how can you
appraise my knowledge? I'm humble, and I'm not really an expert, but I've been programming Java for some time...
If I'm saying something wrong just tell what it is! Directly and logically.Guys like you criticise other people forgetting that first they should look themselves at the mirror. Wake up!
P.S: So JAVA programs today are as speedy as the ones written in C or C++? Well, If you wanna say that... Just go on, Mr. Computer Science expert!
I don't even bother to start this discussion. I'm so proud of you that you've programmed Java for some time. I've programmed Java for some time too, but you don't see me posting opinions as facts.
I didn't claim I was a "Computer Science expert" as you put it, but judging by the posts you've been making, you really don't have much of a clue about Java, C, C++ and how they relate to each other in speed and other aspects.
Oh my goodness, you obviously don't know who Kayaman is....
Viruma at 2007-7-18 19:06:29 >
Yes, one of the games that used to be (I don't knoiw if it still is) is 95% java. Its called something lieke IL-95 Storm. Its a combat flight sim.
Anyway, pros coding Java can make it AS FAST AS OR EVEN FASTER than some C++ programs. I could make a C++ program really slow (slower than Java) through bad coding. Same applies to Java. Since Java is easier to learn, there are mor newbies coding it making slow programs. On the sun site there is this one fullscreen 3D flight sim where you just fly around, but its performance wasn't a bit choppy, even though the computer running it must have been at least 2 years old.
Viruma at 2007-7-18 19:06:29 >
> Thanks for the link,
> After doing some testing with the
> System.currentTimeMillis(), I realised XP's
> granularity is also 10 millis (ms)....
>
> thread.sleep(1) results in 10ms or more.
> and even a simple
>
> for (int i = 0; i < 1000; i ++)// do it 1000 times
> Thread.sleep(0,1); // sleep for 1 nanosecond...
>
> results in 1041 ms !! thats so way off the mark....
>
> I will be trying out the sleep based timer hack.
>
> ~Jeffrey
yup, you've noticed quite a little gem that Sun have implemented there...
here is the source for that method
public static void sleep(long millis, int nanos) throws InterruptedException
{
if (millis < 0) {
throw new IllegalArgumentException("timeout value is negative");
}
if (nanos < 0 || nanos > 999999) {
throw new IllegalArgumentException(
"nanosecond timeout value out of range");
}
if (nanos >= 500000 || (nanos != 0 && millis == 0)) {
millis++;
}
sleep(millis);
}
so, in short, never call Thread.sleep(long millis, int nanos) :p
Abusea at 2007-7-18 19:06:29 >
Man, I do hope they'll sort of implement that method correctly instead of just making a call to sleep(millis)....
Learnt something new today...
Is there any way to implement the sleep method ourselves?
How does Thread.sleep() work anyway?
Is there a way of asking the JVM to wake me(a thread) up upon some ticks instead of millis ? or the JVM's ticks are actually the precision of the System.currentTimeMillis()?
~Jeffrey
to virum: I think I know the game You're speaking about...
Isn't it Ilyushim (something like that) 95 Sturmovik?
I have it. It's a russian game. Is it programmed with Java?
I would like to know (I'm serious, not sarcastic)whether it runs through
a JVM or it is directly compiled to native code (machine code).
Honestly I think it's very slow. Although I have only a 500Mhz machine, the flight
simulator from Microsoft seems to work much better. I have MFS2(Pacific Theather) and
it runs fine.
To Kayaman:
I may be wrong about the reasons why Java is slow. Maybe.
But I would invite you to write the same game in Java and C++.
I wrote: THE SAME GAME. One version of it written in C++,
the other written in Java and run through a JVM, not compiled
to machine code.
It could be something simple, and it would be easy for you, as I suppose
you know a lot more than I do about the subject...Maybe you already have a sample
of it.
Give me both codes. If you prove me that I am wrong, I will stop annoying.....
And, of course, the C++ code has to be optimized....
It's obvious, for if you want to make things slower, that's the easiest
thing to do! You just have to spend 10Mb where you just had to use 1Kb, for instance, use a lot of useless pointers and functions, and so on...
As we say here: Every saint helps you when you just want to go down...
You may be as clever as Einstein was. But I'm sure that if he criticized somebody's knowledge it was because he knew exactly what that someone was wrong on...
I don't fear authority. I only respect logic.
to Virum: Actually the game is IL-2 Stormovik, and was written mostly inJava using OpenGL...
I've never claimed that you can substitute c++ with Java when making games. C++ is slow compared to straight assembly. One reason I don't code asm anymore is because it would take a year to do the simplest things. Sure, they'd be fast as hell and I could take on anyone in a speed contest but I don't have the time.
Programming a 3D game in C++ and Java will result in the C++ game running smoothly (assumedly it was coded properly) and a Java game running at a variable speed, depending on which technologies were used, how extensive the game is etc. etc. etc.
Java was not created to make videogames. Java was not created to run nuclear plants. So obiviously it doesn't make much sense to use it for something it wasn't designed for.
I assume you're whining because Java is slower than C++?
Yes, it's true. You can always compile to native to win some speed, use the best technologies and write the fastest code, but it will not change the fact that Java is not C++. It was not designed for games.
Still, it's changing. You now have full screen support, BufferStrategy and so on, so now you have the chance to make at least some kind of games and the result still depends mostly on your skills as a coder.
This thread really seems to be two threads. ddanielvalladao, please start your own thread next time, so Jeffrey_Chee doesn't have to bore himself with ramblings about Java while he's looking for helpful postings.
There is a similar discussion about whether Java should be ignored by programmers here :
http://www.javagaming.org/cgi-bin/JGOForums/YaBB.cgi?board=News;action=display;num=1036934338
My favorite comment from that discussion is "The gaming industry once said the same things about C, then C++ as programming languages". Programming languages evolve. C and C++ have been around for a long time. The compilers are mature and there's lots of libraries available for them today. Imagine 3D programming without SDL or similar libraries... Java is slowly gathering libraries, they are slowly becoming user friendly, and we'll definitely be seing 3D games in Java before long. With OpenGL support, the speed of the programming language used doesn't matter as much for games.
One of the things you've mentioned are the runtime error messages. Yes, they slow Java down. Solution : Tell the Java compiler not to include debug info with the compiled code.
Another thing you've mentioned is that Java programs are slower than C programs. That's definitely true, if you take identical programs. I've stopped using C because ( to me ) Java is far more readable. From my experience writing a Java program takes less time. So, if I use the time the C programmer spends on his program to optimize my code, I may even beat him for speed, memory usage, whatever is important. Here's a nice example to support my oppinion :
There's 3 adaptions of a game called Color Expansion at sourceforge.net. Mine is written in Java, the other working program is written in C++ and the third (which used to work but doesn't any more) is written in C#. The Java version is currently leading the competition. It plays 2.5 times as fast as the C++ version, even though it has by far the most complex, time consuming evaluation algorithm. It nearly always beats the C++ program. My program did not win, because I can calculate more steps ahead, but because it's far easier to replace parts of my program than it is with the other programs. Oh, I forgot the link (you can download a match protocol with comments from the Java Color Expansion project page) :
http://jcolorexpansion.sourceforge.net/index.html
According to you, "The value of Java is not based on its "Virtual O.S." approach (the JVM).", but it's portability. Am I missing something here? The JVM is basically an emulator that runs "compiled" Java programs. The whole portability stems from this emulator approach, doesn't it? Because Java programs are not really assembly and do not really access OS specific resources but let the JVM do all the non-portable stuff?
I also like this one : According to you, "The value of Java [...] is based on the many classes available through the use of this language, which makes pre-compiled code much smaller and allows an easier and faster exchange of programs", but "JVM procedures probably are too much for a lot of programs, and therefore just spend memory space and computing time". Perhaps I get this wrong, but the advantage of Java seems to be the large number of useful classes, which take a lot of effort out of writing a program, but the downside is the large number of methods in those classes. Call me stupid but I say without those methods Java would not be the comfortable language it is. If you wanted to turn it into something where you only have the methods a program actually uses, you'd have to create a procedural language. I don't want 10000 different classes representing a window just because there are 10000 combinations of methods which all meet the exact requirements in some context. Also, if memory consumption and computing time is critical, I assume there'll be a lot of data objects involved. There's usually no need to extend the "overloaded" Java classes and instantiate them as data objects. I cannot imagine anyone who's contributed to this discussion to make a mistake like that.
Kayaman writes "I've never claimed that you can substitute c++ with Java when making games." Well, I do claim you can, but not with every type of game. You can with turn based games like Civilization for example. I think there's a Java version of FreeCiv. I haven't tried it but if it works it'd be a good example of a full blown game where Java works just as good as C++ does. Let's wait until there's some good OpenGL libraries for Java around and someone has used them for a game and then we can talk about 3D games too. I say until then honest comparisons have to be between Java programs and C++ programs which don't use hardware acceleration for their graphics.
P.S.: Did I mention I have too much time on my hands ? :o)
