After accounting for the euro to dollar conversion (and discounting different taxes and cost of living because I'm tired) Science(*) says I should be about 90% happy!
Yay!
(*) and not any kind of Science, Princeton Science!
Maybe they deliberately used non-standard notation to see if the students could come up with a sensible interpretation of the problem.
Yes, writing "4+3+2=( )+2" when you mean "solve 4+3+2=x+2" is weird, but
interpreting "4+3+2=( )+2" as "compute 4+3+2, then add 2 to the result" (which the example of a wrong answer given in TFA)
probably means you don't understand what an equal sign is.
First, I'd like to see the science that proves that 24 fps is enough for everyone.
While I agree that insisting on 120fps when your monitor can only display 50 is silly,
I actually did a double blind test on a 120Hz monitor and I could definitely tell the difference between stable 60fps and stable 120fps.
Maybe some people can't tell the difference. Most people who can probably don't care. But I know I can tell and I do care.
Also, games and movies are different. In a movie, there's motion blur which helps a lot. 24fps in movies is okay most of the time.
But to do motion blur in a game you need to increase latency by a few frames and low latency is more important than smoothness in a fast-paced game.
Directors can (and do) shut the sound for a scene in a movie with sound, if they think that scene is better with no sound.
They can put black & white shots in the middle of a color movie.
Even for individual shots it's not binary: you can have slightly softer sound/music for this scene, slightly less saturated colors for that one, etc.
Not so with 3D. The movie is entirely 3D, or it's entirely 2D.
No 2.63D here and 2.12D there either.
Plus, for the shots where 3D doesn't add anything, it usually is a nuisance (eg. if you try to focus on blurry background) and I don't think many stories worth telling can make good use of 3D in every single shot.
I agree with your post, if some software makes your hardware overheat, it's a hardware problem. I have a minor nitpick though.
I fail to see how rendering a scene at a high framerate would be any more challenging than rendering a complex scene at a lower frame rate. Remember that the hardware either is or is not in use. The ROPs, the shaders, etc. It isn't like there is some magic thing about a simple scene that makes a card work extra hard or something.
Actually, there can be such a magic thing.
An ideal transistor will draw current only when changing state (a transistor is basically a more complex version of a capacitor, changing state is like (dis)charging).
An actual transistor leaks current even when idle, but still draws more than idle to change its state.
So, if a computation changes the states of more transistors, it will draw more current (and generate more heat).
My Computer Hardware teacher at school told us a story about some project he'd work on, where they cut by a fair amount the power consumption of a hearing aid (and thus increased the battery life) just by changing the representation of a variable from 2's complement to sign-magnitude.
The device was updating very often some value that never changed much but was always close to zero so it changed sign a lot. With 2's-complement almost all the bits change with each sign change.
With sign-magnitude, only the sign bit and the lower bits change, which means less transistors changing state thus less current drawn.
Maybe the cut-scenes in SC2 are exposing a use case the GPU engineers didn't thought of, or didn't think was realistic, when they computed the TDP, making the cards overheat in this very particular case.
But even in that case, it still isn't SC2's fault. And yeah, more probably it's just inadequate cooling/PSU/whatever.
A lot of comments here miss the point of this car.
It recovers some of the braking energy before a corner to charge the batteries, and then use the electric motors to exit the corner faster.
The point of this car is to go fast, not save fuel/money (seriously guys a $500,000 car to save money?)
The fact that you can use it as a hybrid and get good mileage in some (very rare) circumstances is no more than a funny side effect.
You definitely don't build a nuclear power reactor to gain knowledge on bombs. A nuclear reactor is very different to a bomb (and a lot simpler).
As for material, my own impression was that nuclear electricity was more expensive than it should be because the (cheaper) reactor designs that allow for weapon grade material generation were banned.
There clearly was some delay between hand movement and cursor movement on that video.
Of course, it's still research and I expect a commercial product if/when it's out to be better.
But no matter what you do to minimize latency, processing the feed from a camera to detect movement means at least one frame of latency (probably more if want to increase precision). One frame is about 30ms and that's a lot for an input device.
And then there are hardcore gamers who believe gameplay is so much more important than HD graphics.
Wait, there's another kind? (Of hardcore gamer I mean.)
To me, graphics are good when they make it straightforward to understand what's going on in the game. Graphics can be pretty or not, highly detailed or not, I don't care. I want clarity. And if the game is real-time (eg RTS or FPS), I also want smoothness and low latency.
10^27 might be seldom cited, but it is not unimaginably huge. Hell, it's less than the number of atoms in an small elephant.
If you want huge, look at Graham's number.
Or the TREE sequence (see here for a quick introduction), which increases extremely fast.
I love it because the definition is not too hard to understand, you can even easily compute the first two terms by hand
(it's 1 and 3) then BAM, TREE(3) make Graham's number look puny.
Or, shield all plants with a metal cage (one cage per plant), put an antenna in every cage and choose randomly which antennas you turn on.
That way, not only you're pretty sure you control everything but you can easily vary the amount and kind of EM radiation you submit the plants to.
templates [...] don't carry any runtime speed penalty
Unless they cause the code to spill out of the instruction cache. Or unless they cause the entire working set to spill out of a handheld device's 4 MB of RAM.
That's because different instances don't share their (compiled) code, and yes, that's a side-effect of templates.
But, if you remove the templates by hand-instantiating them, you'd still have the same issue of code duplication.
My point was that the templates themselves don't cause any slowdown (unlike, say, virtual functions), not that they always lead to the fastest code.
There's more to C++ than Object Oriented Programing.
For instance templates are great for generic programing, and they don't carry any runtime speed penalty (they can cost quite a lot at compile time though...).
You can even go faster than C in some cases (try std::sort versus libc's qsort on an array of integers, std::sort is more generic and faster because it allows the compiler to easily inline the comparison function).
And there's more to C++ than OOP and templates.
I really like C++ and it's great to see it used in more and more big open source projects, like GCC recently and now, well, Compiz.
I predict Linux will be ready for the desktop exactly one year after Linus sees the light and rewrites the kernel in C++.:-)
I've lost track of the number of well-ranked players I have completely abused while playing first person shooters with my Trackman Wheel. Maybe your problem is too much time spent exercising the wrist, and not enough time spent exercising the thumb.
I've read/heard that line countless times, but I have yet to actually see anyone who plays Quake(*) decently with anything else than a mouse.
I'll grant you that a trackball is far superior to a console pad, so if anything can be as good as (better than?) a mouse, it's a trackball but I still think it's just not good enough.
I mean, if a trackball really is that good, at least some pros should use one, right?
Not that I consider myself a "well-ranked player" but I'd very much like to have a Quake Live duel with someone who uses a trackball
(someone who knows Quake of course, otherwise they'll get destroyed simply because they don't know how to play the game.)
I seriously think that even scoring a point would be an enormous challenge for a trackball user.
But, maybe I'm wrong so, trackball users, who's up for running circles around a smug mouser by the name of chocapix?:-)
(*) I speak only for Quake, because it's the only FPS I play. I suspect most of what I say still holds for, say, CS or UT, though.
As someone who used to be hardcore into ID Software FPS titles, now that I am an adult with more responsibilities, it is harder to dedicate that much time towards finding a another freaking Intel Item, hidden obscurely in some level somewhere.
If I cannot play for 15-20 minutes and abort where I am at, without suffering huge penalties, I am not going to ever finish that game.
Try out Quake Live, then.
It's multiplayer only, so no stupid blue key to find, you just "click on people until they die"*
There's a 10 minutes time limit for Duels, 15 minutes for FFA (and someone always reach 50 frags before that) so you absolutely can complete
a game in well under 20 minutes.
I think it's perfect for the hardcore-gamer-gone-casual. The game itself is pretty hardcore, because you need a huge amount of skill to perform well
(it's basically Quake 3 arena) and
at the same time you can play a quick 10 minutes game whenever you feel like it.
Oh, and it's free.
(*) I just love that description of Quake I read somewhere:-)
[snip] irrational [snip]
You keep using that word. I do not think it means what you think it means.
Using "cat /proc/cpuinfo" as a benchmark, I can see that my quad core is several times slower with an SMP kernel compared to a non-SMP kernel.
After accounting for the euro to dollar conversion (and discounting different taxes and cost of living because I'm tired) Science(*) says I should be about 90% happy!
Yay!
(*) and not any kind of Science, Princeton Science!
In Mercia.
Maybe they deliberately used non-standard notation to see if the students could come up with a sensible interpretation of the problem.
Yes, writing "4+3+2=( )+2" when you mean "solve 4+3+2=x+2" is weird, but interpreting "4+3+2=( )+2" as "compute 4+3+2, then add 2 to the result" (which the example of a wrong answer given in TFA) probably means you don't understand what an equal sign is.
First, I'd like to see the science that proves that 24 fps is enough for everyone.
While I agree that insisting on 120fps when your monitor can only display 50 is silly, I actually did a double blind test on a 120Hz monitor and I could definitely tell the difference between stable 60fps and stable 120fps.
Maybe some people can't tell the difference. Most people who can probably don't care. But I know I can tell and I do care.
Also, games and movies are different. In a movie, there's motion blur which helps a lot. 24fps in movies is okay most of the time. But to do motion blur in a game you need to increase latency by a few frames and low latency is more important than smoothness in a fast-paced game.
Science doesn't happen overnight!
Directors can (and do) shut the sound for a scene in a movie with sound, if they think that scene is better with no sound. They can put black & white shots in the middle of a color movie. Even for individual shots it's not binary: you can have slightly softer sound/music for this scene, slightly less saturated colors for that one, etc.
Not so with 3D. The movie is entirely 3D, or it's entirely 2D. No 2.63D here and 2.12D there either.
Plus, for the shots where 3D doesn't add anything, it usually is a nuisance (eg. if you try to focus on blurry background) and I don't think many stories worth telling can make good use of 3D in every single shot.
I fail to see how rendering a scene at a high framerate would be any more challenging than rendering a complex scene at a lower frame rate. Remember that the hardware either is or is not in use. The ROPs, the shaders, etc. It isn't like there is some magic thing about a simple scene that makes a card work extra hard or something.
Actually, there can be such a magic thing.
An ideal transistor will draw current only when changing state (a transistor is basically a more complex version of a capacitor, changing state is like (dis)charging). An actual transistor leaks current even when idle, but still draws more than idle to change its state. So, if a computation changes the states of more transistors, it will draw more current (and generate more heat).
My Computer Hardware teacher at school told us a story about some project he'd work on, where they cut by a fair amount the power consumption of a hearing aid (and thus increased the battery life) just by changing the representation of a variable from 2's complement to sign-magnitude. The device was updating very often some value that never changed much but was always close to zero so it changed sign a lot. With 2's-complement almost all the bits change with each sign change. With sign-magnitude, only the sign bit and the lower bits change, which means less transistors changing state thus less current drawn.
Maybe the cut-scenes in SC2 are exposing a use case the GPU engineers didn't thought of, or didn't think was realistic, when they computed the TDP, making the cards overheat in this very particular case.
But even in that case, it still isn't SC2's fault. And yeah, more probably it's just inadequate cooling/PSU/whatever.
That's it? I didn't know the 'emacs vs. vi' friendly debate was over. Who won?
A lot of comments here miss the point of this car.
It recovers some of the braking energy before a corner to charge the batteries, and then use the electric motors to exit the corner faster. The point of this car is to go fast, not save fuel/money (seriously guys a $500,000 car to save money?)
The fact that you can use it as a hybrid and get good mileage in some (very rare) circumstances is no more than a funny side effect.
I think you mean "Oops."
You definitely don't build a nuclear power reactor to gain knowledge on bombs. A nuclear reactor is very different to a bomb (and a lot simpler).
As for material, my own impression was that nuclear electricity was more expensive than it should be because the (cheaper) reactor designs that allow for weapon grade material generation were banned.
There clearly was some delay between hand movement and cursor movement on that video.
Of course, it's still research and I expect a commercial product if/when it's out to be better. But no matter what you do to minimize latency, processing the feed from a camera to detect movement means at least one frame of latency (probably more if want to increase precision). One frame is about 30ms and that's a lot for an input device.
And then there are hardcore gamers who believe gameplay is so much more important than HD graphics.
Wait, there's another kind? (Of hardcore gamer I mean.)
To me, graphics are good when they make it straightforward to understand what's going on in the game. Graphics can be pretty or not, highly detailed or not, I don't care. I want clarity. And if the game is real-time (eg RTS or FPS), I also want smoothness and low latency.
I'm not well versed in the fighting techniques [...] of mice.
Potentially the greatest famous last words ever.
10^27 might be seldom cited, but it is not unimaginably huge. Hell, it's less than the number of atoms in an small elephant.
If you want huge, look at Graham's number. Or the TREE sequence (see here for a quick introduction), which increases extremely fast. I love it because the definition is not too hard to understand, you can even easily compute the first two terms by hand (it's 1 and 3) then BAM, TREE(3) make Graham's number look puny.
Or, shield all plants with a metal cage (one cage per plant), put an antenna in every cage and choose randomly which antennas you turn on. That way, not only you're pretty sure you control everything but you can easily vary the amount and kind of EM radiation you submit the plants to.
templates [...] don't carry any runtime speed penalty
Unless they cause the code to spill out of the instruction cache. Or unless they cause the entire working set to spill out of a handheld device's 4 MB of RAM.
That's because different instances don't share their (compiled) code, and yes, that's a side-effect of templates. But, if you remove the templates by hand-instantiating them, you'd still have the same issue of code duplication.
My point was that the templates themselves don't cause any slowdown (unlike, say, virtual functions), not that they always lead to the fastest code.
There's more to C++ than Object Oriented Programing.
For instance templates are great for generic programing, and they don't carry any runtime speed penalty (they can cost quite a lot at compile time though...). You can even go faster than C in some cases (try std::sort versus libc's qsort on an array of integers, std::sort is more generic and faster because it allows the compiler to easily inline the comparison function). And there's more to C++ than OOP and templates.
I really like C++ and it's great to see it used in more and more big open source projects, like GCC recently and now, well, Compiz.
I predict Linux will be ready for the desktop exactly one year after Linus sees the light and rewrites the kernel in C++. :-)
I've lost track of the number of well-ranked players I have completely abused while playing first person shooters with my Trackman Wheel. Maybe your problem is too much time spent exercising the wrist, and not enough time spent exercising the thumb.
I've read/heard that line countless times, but I have yet to actually see anyone who plays Quake(*) decently with anything else than a mouse. I'll grant you that a trackball is far superior to a console pad, so if anything can be as good as (better than?) a mouse, it's a trackball but I still think it's just not good enough. I mean, if a trackball really is that good, at least some pros should use one, right?
Not that I consider myself a "well-ranked player" but I'd very much like to have a Quake Live duel with someone who uses a trackball (someone who knows Quake of course, otherwise they'll get destroyed simply because they don't know how to play the game.) I seriously think that even scoring a point would be an enormous challenge for a trackball user.
But, maybe I'm wrong so, trackball users, who's up for running circles around a smug mouser by the name of chocapix? :-)
(*) I speak only for Quake, because it's the only FPS I play. I suspect most of what I say still holds for, say, CS or UT, though.
You can't charge a car fast enough to match gasoline.
But if you use Sony Batteries, you can match the burning ability of gasoline!
Hey, careful with these matches!
Plus, the energy you capture at the solar panels will be used sooner or later, at which point most of it will end up being lost in heat anyways.
As someone who used to be hardcore into ID Software FPS titles, now that I am an adult with more responsibilities, it is harder to dedicate that much time towards finding a another freaking Intel Item, hidden obscurely in some level somewhere. If I cannot play for 15-20 minutes and abort where I am at, without suffering huge penalties, I am not going to ever finish that game.
Try out Quake Live, then.
It's multiplayer only, so no stupid blue key to find, you just "click on people until they die"*
There's a 10 minutes time limit for Duels, 15 minutes for FFA (and someone always reach 50 frags before that) so you absolutely can complete a game in well under 20 minutes.
I think it's perfect for the hardcore-gamer-gone-casual. The game itself is pretty hardcore, because you need a huge amount of skill to perform well (it's basically Quake 3 arena) and at the same time you can play a quick 10 minutes game whenever you feel like it.
Oh, and it's free.
(*) I just love that description of Quake I read somewhere :-)
You should look into Tiling window managers. I personally use awesome at home, and it's awesome.