Minecraft on Pandora

[WizardStan]

You sure about that? I've never seen any monitors that support higher refresh rates than 60 Hz (not saying they don't exist, just that they seem uncommon). If the monitor only refreshes 60 times a second, it's not human perception that matters; you can't see 120 FPS because the screen is really only refreshing 60 times per second, even if 120 loops are happening per second.

The cones in the eye take about 0.02 seconds to completely register changes from one colour to another. The practical limits of the human eye are in around 45-60 framers per second. If you alternately display a screen full of red and then black at 50 frames per second, you will be able to distinctly see red and black images. If you then increase the speed, flashing back and forth between black and red faster and faster, the black screen will slowly appear to look more and more red while the red screen will look more and more black until they balance out at around 100 frames per second and it looks like an unchanging dark red screen.


We did this experiment back in high school, using a coloured light that could be pulsed at some ridiculously high speed. The experiment was just to keep turning up the frequency until you could no longer perceive the light flickering.

 

[Inferno's Reaper]

Essentially, the human limit is why they generally don't bother making monitors with a refresh rate faster than 60hz(as opposed to the convenience of syncing up the refresh rate with the AC current cycle rate of the 60hz standard for alternating current electricity in the United States).


A noteworthy exception to the 60hz refresh rate standard is the 120hz monitor/tv, which are used for certain types of 3D displays.

 

[Exophase]

You sure about that? I've never seen any monitors that support higher refresh rates than 60 Hz (not saying they don't exist, just that they seem uncommon). If the monitor only refreshes 60 times a second, it's not human perception that matters; you can't see 120 FPS because the screen is really only refreshing 60 times per second, even if 120 loops are happening per second.

Maybe you're too young to remember CRTs very well (or only used bad ones), but they routinely offered refresh rates better than 60Hz. Although that was partly because their phosphors start losing luminance quick enough that if your refresh rate is too low you get visible flicker.


That doesn't mean the higher refresh rates can't help though. Without any kind of post-processing like motion blur having discretely sampled frames creates temporal aliasing.. having a higher sample rate (higher refresh rate) before the low pass filter (your eyes) helps remove this.

Regarding Java's speed, I don't get the stigma that high-level languages are slow. I'm not familiar with Java, but the impression I get is it's really fast (mostly because of a JIT compiler, AFAIK), which doesn't surprise me at all. PyPy, for example, has benchmarks showing that certain operations are faster in it than in lower level languages like C, IIRC (or maybe that was Psyco, the older Python JIT compiler project). This doesn't mean that PyPy is necessarily faster than C, but it means that it can be just as fast or, on some rare occasions, faster.

Oh yes, people love it when their toy benchmarks show their favorite language is faster than the ones everyone is always saying has the upper hand. You can find stuff like this for pretty much anything competent.


Yeah, JITs can do some stuff faster sometimes.. but not usually and it's all really an uphill battle. In theory they can do PGO for you (not that you can't do your own PGO with something like C/C++) but in practice they don't get to collect enough profiling data on stuff before it gets hot and needs to be compiled. And since the compilation happens during program execution and your typical "client" style VM is optimized to not have unacceptably long startup times or sudden long stalls their JITs don't dedicate too much time to expensive optimizations. Tragically, javac performs almost no optimizations, and the main JVM JITs are written with the assumption that they're running javac binaries, so they have to do a lot of stuff at runtime that they really shouldn't have needed to, leaving less time for more aggressive backend style optimizations.


Of course the languages themselves do have their own performance strengths and weaknesses too.. C/C++'s pointer aliasing can be a weakness, or Java's bounded arrays/null pointer checks, or anything with dynamic typing..

 

[Inferno's Reaper]

Personally, I never saw a CRT with a refresh rate above 75hz, but I know they could get up there(It took some good advances in digital electronics to pull that off effectively because of how CRTs normally work). But, you'll notice that LCDs generally don't go above 60hz


Anyway. Java's best selling point isn't its mechanical advantages(which it kinda lacks in), but its ease to use to make stuff on multiple platforms. I also found it easier to program in than C++, but that's just my opinion. Mostly its the overwhelming amount of stuff they've managed to be able to put Java on that makes it good.


Java tends to suck when making something as big as Minecraft compared to using something like C++(even if you're good at it)

 

[iprice]

200 Hz tv - http://www.amazon.co.uk/Samsung-UE32D6100-Widescreen-Internet-Freeview/dp/B004TB4W7I/ref=sr_1_1?ie=UTF8&qid=1341862034&sr=8-1


And another - http://www.amazon.co.uk/Toshiba-40WL753B-Widescreen-Internet-Backlighting/dp/B003RWTJCI/ref=sr_1_4?ie=UTF8&qid=1341862034&sr=8-4


Are they merely upping the Hz for sales ("Hey Honey, this tv has 200 Hz, not jut 60!") or is there a genuine advantage to such high Hz? They claim smoother motion/action, however I presume output will only be as good as the input it receives.

 

[Exophase]

The really high refresh rate TVs supposedly do some kind of motion interpolation.. no idea if it's anything worthwhile.

 

[Inferno's Reaper]

I'm not an expert, but unless the extra Hz are being used as part something special(like it is with a 3D TV), it's not gonna make much of a difference.

 

[elwing]

Regarding Java's speed, I don't get the stigma that high-level languages are slow.

higher level language generally tend to be slower but they have lots of advantage... telling that a language suck cause it is slower is dumb. higher level language generally translate in easier to write and faster to write code, you can also achieve more complex program easier. following one of the link I found theses two pages:


raw performance:


http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php


and a more interesting graphic:


http://shootout.alioth.debian.org/u32/code-used-time-used-shapes.php


that clearly shows that lower level language are the fastest but are the less concise generally...


example: ruby seem to be the most concise languages but seems to be 30 time slower than fortran they seems to use as a reference...

 

[ZXDunny]

JITs are not really all that in terms of speed - but they're far faster than interpretation. As an example, run WinUAE on a 500MHz PC - and then compare the speed of the apps and games to a real amiga running at 50MHz. The Amiga will be far, far faster. There are some considerations such as custom chips etc, but even with that taken into account, the JIT isn't helping a great deal. Compare again to an interative emulation such as WinFellow, and you'll see what the benefits of JIT are.


Java's JIT system is efficient, but nowhere near as fast as equivalent C or well written assembly. End of.


D.

 

[elwing]

I'm not an expert, but unless the extra Hz are being used as part something special(like it is with a 3D TV), it's not gonna make much of a difference.

not the 200Hz one... for 3D TV I've seen 600Hz TV...

 

[diligentcircle]

Java's JIT system is efficient, but nowhere near as fast as equivalent C or well written assembly. End of.

It's slower, but the way some people talk, you'd think Java is like a slug dragging itself up a cliff. I'm pretty sure, compared to other high-level languages, Java is pretty fast. A lot faster than CPython, for example. I think I've even read that Jython (Python interpreter written in Java) is very close to being as fast as CPython, or maybe it was that it's a bit faster because of use of Java's JIT compiler or something like that.

We did this experiment back in high school, using a coloured light that could be pulsed at some ridiculously high speed. The experiment was just to keep turning up the frequency until you could no longer perceive the light flickering.

Sounds like a cool experiment.


Thanks for the explanations of refresh rates, guys.

 

[Letalis Sonus]

Personally, I never saw a CRT with a refresh rate above 75hz, but I know they could get up there(It took some good advances in digital electronics to pull that off effectively because of how CRTs normally work). But, you'll notice that LCDs generally don't go above 60hz

Kinda all CRTs I have been using were running with 100Hz, due to the way they refresh it's just bad for your eyes when using lower frequencies. LCDs simply update the pixels where they are, there are no side effects that need to be compensated with a higher clock.


A lot of TFTs do support at least 75Hz on their native resolution, but they don't always say so in their EDID - I used to drive both of my TFTs with 75Hz, until the older one (some very cheap VGA-only screen) wasn't able to properly recognize the borders between frames anymore, going back to 60Hz fixed it.

 

[Inferno's Reaper]

All that said, even with the refresh rates being at what humans could see at(or better), the actual frames per second of TV was a good bit less than that(apparently, 24 for PAL & 30 for NTSC). Computer monitors, of course, eventually developed into not 'just slightly modified TVs' & the differences became more apparent.


That said, oddly, we have a big difference in LCD TVs & LCD computer monitors that I don't really understand. A TV & a monitor could both be showing the same thing from the same input source & the TV will ghost pretty bad, but the monitor won't.

 

[ekianjo]

It's slower, but the way some people talk, you'd think Java is like a slug dragging itself up a cliff. I'm pretty sure, compared to other high-level languages, Java is pretty fast. A lot faster than CPython, for example. I think I've even read that Jython (Python interpreter written in Java) is very close to being as fast as CPython, or maybe it was that it's a bit faster because of use of Java's JIT compiler or something like that.

Java is NOT slow, definitely. C and C++ are clearly the fastest. Java is fast, but still far behind C (probably 10 times slower or more).


Then, other high level languages are about far from Java in terms of performance, in the following order (according to http://blog.dhananja...n-jruby-groovy/):


JRuby 1.8


Ruby 1.9


Python - about twice slower than the 2 above...


Ruby 1.8 - about twice slower than Python


PHP - about 1.5 times slower than Ruby 1.8


If you code games, C / C++ is still probably the best choice, and Java can be acceptable while you lose a lot. Anything else will severely impact performance.

 

[elwing]

I'll repost this link since people visibly don't want to click on it...


http://shootout.alioth.debian.org/u32/code-used-time-used-shapes.php


you can also find lots of interesting information, like what language use the least memory and so on... you can clearly see the tradeoff you do when choosing your languages and java is surprisingly fast, through not much more concise than plain C++, according to the test on this site the major drawback is not about speed but memory used.

 

[Inferno's Reaper]

I think no one wants to click on or acknowledge it because it has a bunch of tiny(at least on my screen) pictures/graphs that involve a lot of lines & dots for reasons lost on me. It frightens & confuses me.

 

[elwing]

lol, I guess you're right!