Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[IHateOutside]

If software requirements keep up with Moore's law, this will keep going for a long time. If it doesn't, there will be a roof to it much sooner. Necessity is the mother of invention, if computers don't need to get any faster, why make them faster? That said, the hardware  would still get smaller, more energy efficient (I smell a grammar fail) and most importantly, cheaper.

[Ampersand]

Quantum. Processors.

[Corona688]

To put things in perspective, what 15 years can do:

Doom, 1993.
Crysis Warhead, 2008.

Mortal Kombat, 1992
Street Fighter 4, 2008

SimCity, 1989.
SimCity 4, 2003

Although I don't think a 15 year graphics jump from ASCII would be very impressive, it's the amount of change that matters 

  That only demonstrates graphical change.  So much effort is put into graphics these days, games with budgets like major movies is ridiculous.  Now, a game that taxes the CPU before graphics even enter the picture....   

[Ampersand]

There is, for example, the physics simulations in Crysis, and... Well, the other games aren't really that advanced outside of their graphics.

[Jay]

It is over 9000 megahertz however.

9000 Mhz is about 8.7 Ghz.  Add two powers of ten.

No, 9000 MHz is exactly 9 GHz. You're thinking of GiHz.

No, he's right.
Computers deal with powers of 2.
1024 Hz = 1 MHz
1024 MHz = 1 GHz
1024 GHz = 1 THz

[Draco18s]

It is over 9000 megahertz however.

9000 Mhz is about 8.7 Ghz.  Add two powers of ten.

No, 9000 MHz is exactly 9 GHz. You're thinking of GiHz.

No, he's right.
Computers deal with powers of 2.
1024 Hz = 1 MHz
1024 MHz = 1 GHz
1024 GHz = 1 THz

Either way my point is still valid:

Add two powers of 10.

[PsyberianHusky]

In 15 years you will be able to make a a dwarf computer capable of having your dwarfs play a game called
"Human Fortress" .... All production in the fortress will grind to a halt

[zagabar]

Moore's law has kept up surprisingly well from what I've heard, if you count multiple cores as the same raw computing power  of a single processor.

The problem is that we can't make anywhere near as optimal use of that power as we once did.  The numbers have just gotten too big, and safe - though less then optimal - coding practices are becoming more important, because we don't have the capacity to think as deeply through the computer's processes.  This is why Java's such a hit - inefficient as hell (it interprets code not directly as instructions to the machine but as instructions to a virtual machine, which is then broken down into a form that a computer can understand) but a lot more padded bits to stop people from poking themselves in the eye. 

Excuse me, but if you are implying that Java is slower than other languages then you are wrong. The old Java engines where slower yes, but these days, java have cought up. Tests has shown that java sometimes are even faster. Just check out these stuff that are made in java:

http://www.jmonkeyengine.com/movies_demos.php

[Decimator]

Moore's law is likely to stay true for quite some time to come:

http://www.electronicsweekly.com/Articles/2009/03/27/45779/mit-develops-graphene-frequency-multiplier.htm

[Corona688]

Excuse me, but if you are implying that Java is slower than other languages then you are wrong. The old Java engines where slower yes, but these days, java have cought up. Tests has shown that java sometimes are even faster. Just check out these stuff that are made in java:

http://www.jmonkeyengine.com/movies_demos.php

Java is not doing rendering here.  He's using Java to calculate a scene graph defining which bits to draw and passes the results to hardware-accelerated OpenGL.  A scene graph is a complex and useful thing, for sure, but if he was trying to write a renderer in Java he'd hit a real performance wall.

Java is inevitably slower than languages that run actual machine code as there is an extra, unavoidable translation step.  (There are such things as processors that run Java natively but your computer does not have one and likely never will.)  With the ability to use outside API's like OpenGL and such, performance is not as important an issue as it might be otherwise.  But these outside API's are not, and should not be written in Java.

[Rysith]

Java is inevitably slower than languages that run actual machine code as there is an extra, unavoidable translation step.  (There are such things as processors that run Java natively but your computer does not have one and likely never will.)  With the ability to use outside API's like OpenGL and such, performance is not as important an issue as it might be otherwise.  But these outside API's are not, and should not be written in Java.

I challenge your assertion that Java is slower, and point to the runtime and Just-In-Time compilers that Java has now that, with more information about how a program is used, are able to generate more efficient machine code than would otherwise be possible (which branch of this if should I optimize for? Let it run a few thousand times and you have your answer!). Lower level stuff (like hardware-accelerated graphics) is lower level stuff, and so of course won't be run in a higher-level language like Java. Similarly, special-purpose hardware (or special-purpose languages) will almost always be faster than software (or general-purpose languages): they surrender flexibility for speed, and get to make domain-specific optimizations that they can't otherwise make (graphics chips are horrible at any code that involves branches. Graphics rendering involves no branches. Not being good at branches lets them do matrix operations much faster. Graphics rendering involves a lot of matrix operations.)

There is no One Language to Rule Them All. They have strengths and weaknesses (readability, coding speed, execution speed, library support), and to pretend that a single language is always suited or unsuited is a mark of poor programming skill.

With Moore's law, I saw something this morning about single-molecule optical transistors that have been demonstrated as a proof-of-concept. Combined with the hundreds-of-atoms laser emitters that IBM announced a few years ago, it looks like miniaturization still has a ways to go outside of putting more cores on a chip. And, as multiple cores becomes the norm, more tools will become available for writing properly-threaded software. I don't think we are in much danger of processing power available not growing.

[G-Flex]

There is, for example, the physics simulations in Crysis, and... Well, the other games aren't really that advanced outside of their graphics.

Compare SimCity to SimCity 4 and that probably does not hold up at all. SimCity had a ton of limitations and I'm sure the simulations involved were much, much more simplistic. Even SimCity 2000 stopped actually simulating individual police stations (for example) after some relatively small number were built.

[Corona688]

I challenge your assertion that Java is slower, and point to the runtime and Just-In-Time compilers that Java has now that, with more information about how a program is used, are able to generate more efficient machine code than would otherwise be possible (which branch of this if should I optimize for? Let it run a few thousand times and you have your answer!).

Compilation is one of the slowest processes in any language.  Time spent doing Just-In-Time-Compilation is time spent not running the program, as is time spent testing branches a few thousand times instead of using the processor's own general-case branch prediction.  Being able to map code into memory and go is an incredible advantage in terms of load times, not to mention taking advantage of virtual memory in a way Java cannot.  There comes a point where the weight of complexity outstrip the utility of it, especially when reinventing things already handled competently by the OS or even the hardware itself.

My main issue with Java is that it is impossible to write a small, simple program.  Even the tiniest 'Hello World' invokes the full might of the hundred-megabyte compiler-interpreter-language-suite monster.

Besides, compilers in general have gotten more sophisticated, not just Java's.

Lower level stuff (like hardware-accelerated graphics) is lower level stuff, and so of course won't be run in a higher-level language like Java. Similarly, special-purpose hardware (or special-purpose languages) will almost always be faster than software (or general-purpose languages)

There are general-purpose languages with perfectly acceptable performance.

they surrender flexibility for speed, and get to make domain-specific optimizations that they can't otherwise make (graphics chips are horrible at any code that involves branches. Graphics rendering involves no branches. Not being good at branches lets them do matrix operations much faster. Graphics rendering involves a lot of matrix operations.)

Nonetheless, all code that runs in a PC's CPU ultimately uses the same instructions to do the same things.

There is no One Language to Rule Them All.

Of course not.  This has nothing to do with the argument, of course, since considering Java cumbersome and slow does not malign all other languages.

They have strengths and weaknesses (readability, coding speed, execution speed, library support), and to pretend that a single language is always suited or unsuited is a mark of poor programming skill.

Good thing nobody said or implied that then.

[Rysith]

I challenge your assertion that Java is slower, and point to the runtime and Just-In-Time compilers that Java has now that, with more information about how a program is used, are able to generate more efficient machine code than would otherwise be possible (which branch of this if should I optimize for? Let it run a few thousand times and you have your answer!).

Compilation is one of the slowest processes in any language.  Time spent doing Just-In-Time-Compilation is time spent not running the program, as is time spent testing branches a few thousand times instead of using the processor's own general-case branch prediction.  Being able to map code into memory and go is an incredible advantage in terms of load times, not to mention taking advantage of virtual memory in a way Java cannot.  There comes a point where the weight of complexity outstrip the utility of it, especially when reinventing things already handled competently by the OS or even the hardware itself.

Part of the purpose of Java was that it handled those things in a way that let you run the same Java code on whatever hardware you wanted, through the Java virtual machine. No need to port from one OS to another or anything like that. Java does take longer to load than a native application, true, but for most normal things (processes running for more than a minute or so), the impact of the compiler is usually a net positive. The branch prediction isn't a replacement for hardware branch prediction, it's re-generating the bytecode to make the common case more efficient. More information (and helpful links!) on wikipedia.

My main issue with Java is that it is impossible to write a small, simple program.  Even the tiniest 'Hello World' invokes the full might of the hundred-megabyte compiler-interpreter-language-suite monster.

Besides, compilers in general have gotten more sophisticated, not just Java's.

My entire JDK is 100MB. I'm not sure what you are using that invokes hundreds of MB of java, but I assure you things have gotten smaller. With the introduction of the JIT and interpreted mode, it doesn't even bother starting to compile things unless it thinks it's going to be worth it. I'm also not sure why you care about the full might being invoked, since I still get sub-100ms startup times for my JVMs. I'm sorry if I come off as somewhat defensive and abrasive, but I get annoyed at people complaining about things that have been fixed since Java 1.4 or so.

Lower level stuff (like hardware-accelerated graphics) is lower level stuff, and so of course won't be run in a higher-level language like Java. Similarly, special-purpose hardware (or special-purpose languages) will almost always be faster than software (or general-purpose languages)

There are general-purpose languages with perfectly acceptable performance.

For graphics rendering? I think not...

they surrender flexibility for speed, and get to make domain-specific optimizations that they can't otherwise make (graphics chips are horrible at any code that involves branches. Graphics rendering involves no branches. Not being good at branches lets them do matrix operations much faster. Graphics rendering involves a lot of matrix operations.)

Nonetheless, all code that runs in a PC's CPU ultimately uses the same instructions to do the same things.

That's true, to a point, within something like "Intel Xeon x86 chips". They all support the same instructions coming in, but how they handle them internally varies quite a lot by processor family, manufacturer, etc. How much optimization you can do to the code as you compile it down can vary greatly, as well, mostly based on how much information you have about the code being executed.  In the case of the graphics example you were using, that's going to run on the graphics card, which is not an x86-supporting chip and does not have the same instruction set as the general CPU. It has a set of instructions (and by extension, a set of hardware instruction paths) that is very narrowly focused on doing graphics operations very quickly.

There is no One Language to Rule Them All.

Of course not.  This has nothing to do with the argument, of course, since considering Java cumbersome and slow does not malign all other languages.

They have strengths and weaknesses (readability, coding speed, execution speed, library support), and to pretend that a single language is always suited or unsuited is a mark of poor programming skill.

Good thing nobody said or implied that then.

I apologize for interpreting your post that way, then, since it seemed like you were maligning Java for being unable to keep up with a special-purpose rendering tool. As I mentioned above, I do somewhat take issue with claiming that Java is cumbersome and slow, but that's an entirely different argument.

[Armok]

This sound like a good place to promote Linoleum.

Cross platform, general purpose, assembler speed (and fast enough to indeed do graphics very well, including stuff like realtime raytracing), easy and intuitive to use (subjective), and completely awesome in any and every way. While there is no One Language to Rule Them All, if there was one it'd be linoleum.
[/shameless plug]