clippen05 said:
Can anyone even explain to me what they think optimization even means? And something can be as "Optimized" as you like, but that's not going to magically get hardware to perform better.
Actually, you're wrong. Optimisation does work and it works similar to how you described it. Heck, code gets optimised all the time, there are some crazy inefficient stuff you can do, here is some java
Code:
String letsMakeThisLong = new String();
while (letsMakeThisBig.length() < 1024)
{
letsMakeThisBig = letsMakeThisBig + "a";
}
Now, this is pretty simple, it would just make a string that has a thousand
a in it. Here is a better way to do it
Code:
String letsMakeThisLong = new String();
StringBuilder tempHolder = new StringBuilder ();
while (tempHolder.length() < 1024)
{
tempHolder.append("a");
}
letsMakeThisLong = tempHolder.toString();
OK, the latter is a little verbous but wanted to point out the differences more clearly. Anyway, these two pieces of code have the exact same result, yet, they'll run for different times on the same hardware. The reason is that String concatenation in Java is actually pretty slow due to how Java manages it. Here is a diagram, in fact
That's exponential growth in time it takes to complete the operation. For the record, the other two methods
are shown on that diagram, only due to the scale, they cover the x axis.
So there you go - a 1.6Ghz (or whatever) processor running faster.
Now, of course, games aren't dealing with strings or even Java, for that matter, they use more efficient languages in order to squeeze even more out of the hardware. Java is nice, but awfully sluggish if you consider the overhead of the JVM and the translation you have to do to access the platform. On the other hand, it runs on...well, anything - if it runs the JVM it will run your code, roughly speaking, nothing platform specific is needed. Anyway, just wanted to give an example of optimisation here, and the Java string concatenation was the one that immediately leapt to mind.
C/C++. which are a lot more used for games and are lower level languages so they aren't as platform agnostic as Java. True, you can write portable code and that's a huge deal, actually, however, you can be "naughty" and NOT write portable code. So you can trade in flexibility for power, as you dip into platform specific implementations of stuff that are more efficient but you probably won't be able to run that code on a different platform.
And even then, there are different ways of of handling data. For example, video cards have a whole different paradigm how they handle things and learning to harness the most out of it will give you a tremendous productivity boost. Problem being, than on a PC you can have any kind of video card and they aren't all the same, forget just raw productivity, the architecture also differs, while on a closed platform you KNOW what you have so you KNOW what you can do with it. Here is an example of how you'd accomplish a task using a video card - the loop above is pretty simple, it just executes the same thing 1024 times in succession, while video cards don't do that, that'd be snails pace in their world - you've got clusters of processing units, say 128, so instead of looping the same code 1024 times, you can loop it 8 times and each time it would be executed 128 times in parallel. So, again - same hardware, different execution speeds.
And I can even throw in the fact that PS4 would actually be even
faster due to the shared DDR5 memory - normally, if you want to give something to the video card, the computer copies the information from the memory to the VRAM, thus adding extra overhead. And the VRAM is usually faster than the RAM (hence why it copies it across. Though speed can also be dependant on bus size, etc, but it's overall faster) so the read speed of the DDR < 5 is an additional overhead. However, with shared DDR5 RAM, you first get the benefit of memory being twice as fast and second, you get the benefit of not having to wait for data to be transferred from the "main RAM" to "VRAM".
TL;DR you're wrong and you don't know what you're talking about.
