That phrase often perplexed me as well and I am an American. One other reference also confuses me about TV programs, when the actors mention Sushi is raw fish. Yes that can be one of the components of Sushi but I often wonder if they mean to be referring to Sashimi instead? Then again, coloUr also makes me scratch my head along with Leicester pronounced as Lester.
UT 2003 GPU Shootout Part II at Anandtech
- Thread starter Bjorn
- Start date
some people have problems with phenomenon and words like electricity.. and dont even try to get someone who is just learning englsih to say spaghetti....
spaghetti.. such an evil word ... most peeps, (thats not a word man! - yes it is - dude), try and say sub-ghetti...
but then i dont even know the correct pronounciation of the word cache.. always thought it was 'cash' but heard some many variants like 'cay-sh' and cash-e
hmm i have forgotten what this thread was about now.
spaghetti.. such an evil word ... most peeps, (thats not a word man! - yes it is - dude), try and say sub-ghetti...
but then i dont even know the correct pronounciation of the word cache.. always thought it was 'cash' but heard some many variants like 'cay-sh' and cash-e
hmm i have forgotten what this thread was about now.
Colour is no worse than color. The end of colour isn't pronounced 'or' but in between that and 'er' and a bit tricky to describe actually, interestingly though nothing like the word our.
The one that irritates me is sulFate which has somehow managed to get itself to be the official spelling and is used in British textbooks etc. Dunno why but sulfate looks stupid to me, we might as well start writing foto and fosforus
Cache is pronounced as cash.
Anyway we're quite capable of destroying are own language. We don't need someone else to do it for us.
The one that irritates me is sulFate which has somehow managed to get itself to be the official spelling and is used in British textbooks etc. Dunno why but sulfate looks stupid to me
, we might as well start writing foto and fosforus Cache is pronounced as cash.
Anyway we're quite capable of destroying are own language. We don't need someone else to do it for us.
Staying OT...
If you are interested in the peculiarities of the English language, I can recommend a book by Bill Bryson called "Mother Tongue". It's a very interesting, humourous and entertaining read.
I don't know why anyone should complain about the pronunciation of some English towns. Try going to Wales! I've been to the village whose name is:
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
Unsurprisingly, most people shorten the name to Llanfairpwll!
If you are interested in the peculiarities of the English language, I can recommend a book by Bill Bryson called "Mother Tongue". It's a very interesting, humourous and entertaining read.
I don't know why anyone should complain about the pronunciation of some English towns. Try going to Wales! I've been to the village whose name is:
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
Unsurprisingly, most people shorten the name to Llanfairpwll!
It's time the english language was rationalized... but we need to keep the U in Colour ok!
-Colourless
-Colourless
you cannot rationalise language (english or otherwise)
you can try to standardise it but it is ever evolving..
one example the changing of the use of the word 'gay' from happy to someone who is inclined otherwise.
cfc too .... before the ozone layer scare no one hard heard of it... etc etc etc.
anywayz the queens' english, roolz a$$ - your bases r owned by me (er?!)
o dear
you can try to standardise it but it is ever evolving..
one example the changing of the use of the word 'gay' from happy to someone who is inclined otherwise.
cfc too .... before the ozone layer scare no one hard heard of it... etc etc etc.
anywayz the queens' english, roolz a$$ - your bases r owned by me (er?!)
o dear
You don't get the joke?
Anyway it is possible to rationalize (or change to make more sense) a language, especially English. Too many incositancies, conflicting rules, exception to rules, homonyms, and words that just have unbelievably illogical spellings or pronunciations.
Example: "Draught"
-Colourless
Anyway it is possible to rationalize (or change to make more sense) a language, especially English. Too many incositancies, conflicting rules, exception to rules, homonyms, and words that just have unbelievably illogical spellings or pronunciations.
Example: "Draught"
-Colourless
Pascal:
I was hoping someone else would pick up the thread so I didn't need to.
This is one of the reasons why *I* read a lot more than I post. I like to be fairly exact and complete in what I say. And don't like when threads aren't neatly tied together in the end. (It doesn't need to be by me.) But it can be to messy and time consuming to give the full deal. So sometimes to avoid having things hanging in the air because it takes to long time, I just don't get into the discussion.
But I'll do something "in between" here, and give a short description.
The simple reason for Amdahl's law not working at low resolution is that (as I said before) CPU and GPU are working in parallel. The "critical path" in the work resides partly in the CPU (dependant on CPU frequency), and partly in GPU (dependant on resolution). There should also be some parts that doesn't depend on either of those factors, but instead of FSB speed, AGP speed, and maybe VS speed. (But those parts seems suprisingly small in this example.)
Amdahl's law will work since the critical path looks like that, but only as long as the critial path contain the same work. There's still a lot of work done outside of the critical path, but that's hidden by parallelism. This example has a surprisingly large area were the critical path is constant, but as you saw at 640x480 there are exceptions.
The thing that happens at that low resolution, is that the rasterisation time becomes shorter than the CPU time that is hidden from the critical path, and suddenly it switch to be a lot more CPU limited (which isn't covered by Amdahl's law).
Then, I think you've been a little careless in accuracy at some points. I made the same calculations as you, but trying to get as accurate inputs as possible, and not rounding any intermediate values. This resulted in a 12% error at 1600x1200 1733MHz.
Plot 1/framerate as a function of 1/(CPU frequency), this shold be a straight line if Amdahl's law works in this area. You'll notice a "knee" in the curve around 1333MHz, indicating a small shift in the critical path. Use the 1333MHZ and 1733MHz values in Amdahl's law, and you'll get a lot closer at the 1600x1200@1733MHz estimation. (It was this that made me say that "other factors" are surprisingly small.)
Another thing.
Have you tried this analysis on the medium detail numbers?
You'll notice that the CPU scaling follows Amdahl's law perfectly, but resolution scaling is still completely off.
Hope that was complete enough.
If anybody want to see some calculations I can send an excel sheet.
I was hoping someone else would pick up the thread so I didn't need to.
This is one of the reasons why *I* read a lot more than I post. I like to be fairly exact and complete in what I say. And don't like when threads aren't neatly tied together in the end. (It doesn't need to be by me.) But it can be to messy and time consuming to give the full deal. So sometimes to avoid having things hanging in the air because it takes to long time, I just don't get into the discussion.
But I'll do something "in between" here, and give a short description.
The simple reason for Amdahl's law not working at low resolution is that (as I said before) CPU and GPU are working in parallel. The "critical path" in the work resides partly in the CPU (dependant on CPU frequency), and partly in GPU (dependant on resolution). There should also be some parts that doesn't depend on either of those factors, but instead of FSB speed, AGP speed, and maybe VS speed. (But those parts seems suprisingly small in this example.)
Amdahl's law will work since the critical path looks like that, but only as long as the critial path contain the same work. There's still a lot of work done outside of the critical path, but that's hidden by parallelism. This example has a surprisingly large area were the critical path is constant, but as you saw at 640x480 there are exceptions.
The thing that happens at that low resolution, is that the rasterisation time becomes shorter than the CPU time that is hidden from the critical path, and suddenly it switch to be a lot more CPU limited (which isn't covered by Amdahl's law).
Then, I think you've been a little careless in accuracy at some points. I made the same calculations as you, but trying to get as accurate inputs as possible, and not rounding any intermediate values. This resulted in a 12% error at 1600x1200 1733MHz.
Plot 1/framerate as a function of 1/(CPU frequency), this shold be a straight line if Amdahl's law works in this area. You'll notice a "knee" in the curve around 1333MHz, indicating a small shift in the critical path. Use the 1333MHZ and 1733MHz values in Amdahl's law, and you'll get a lot closer at the 1600x1200@1733MHz estimation. (It was this that made me say that "other factors" are surprisingly small.)
Another thing.
Have you tried this analysis on the medium detail numbers?
You'll notice that the CPU scaling follows Amdahl's law perfectly, but resolution scaling is still completely off.
Hope that was complete enough.
If anybody want to see some calculations I can send an excel sheet.
Hi Basic
My guess it is a FSB/AGP/Memory bottleneck because the CPU-core was at much higher frequency and at this high framerate the data flow is intensive.
Another possibility is the rasterization faster than the HW T&L but the problem happened with all GPUs.
some time ago then I will do it again. Well let me do it again.
From the scalling analysis (second article) with 800x600 high detail (+-145fps) GF4Ti4200/Athlon 800Mhz: CPU 50% and GPU 50% (some data was obtained visually from the plot).
I will use some shortcuts/normalizations with Amdhal´s law.
-CPU at 1.73GHz: 50% / (1.73GHz/.8GHz ) = 23%
-GPU at 1024x768: 50% / ((800x600)/(1024x768)) = 81%
-Framerate (from first article) at 800x600 high detail GF4Ti4200/Athlon1.73GHz (measured) = 196fps (will be the reference point)
Lets manually plot it:
resolution------measured-----calculated-----error----CPU-----GPU
640x480---------237.2fps--------260fps------9.7%----23%-----32%
800x600---------196fps--------reference---------------23%-----50%
1024x768--------133.3fps---------137.5fps---3.2%----23%-----81%
1280x1024-------83.9fps---------89.5fps----- 6.7%----23%----136%
1600x1200-------58.6fps---------64.2fps------9.6%----23%----200%
Interesting the error grows when we get away from the reference point then probably it is not 50% CPU and 50%GPU in the begining. Probably a little more CPU (maybe 53%). But anyway it is mainly Amdhal, not so bad for a gamer´s guestimate
I will try it later using only the article 1 with its more precise data.
We usually dont have time for a full discussion with the many details, but we have to keep moving.
Some possible reasons: bottleneck and overlap (paralelism between frames or inside frames). Critical path is a consequence of the overlap. My guess it is bottleneck because at other situations (like slow 800MHz CPU when the percentage of CPU was 50%) the overlap was not apperent/prevalent.
My guess it is a FSB/AGP/Memory bottleneck because the CPU-core was at much higher frequency and at this high framerate the data flow is intensive.
Another possibility is the rasterization faster than the HW T&L but the problem happened with all GPUs.
I use paper, pen and the windows calculator. The paper went to the trash
some time ago then I will do it again. Well let me do it again. From the scalling analysis (second article) with 800x600 high detail (+-145fps) GF4Ti4200/Athlon 800Mhz: CPU 50% and GPU 50% (some data was obtained visually from the plot).
I will use some shortcuts/normalizations with Amdhal´s law.
-CPU at 1.73GHz: 50% / (1.73GHz/.8GHz ) = 23%
-GPU at 1024x768: 50% / ((800x600)/(1024x768)) = 81%
-Framerate (from first article) at 800x600 high detail GF4Ti4200/Athlon1.73GHz (measured) = 196fps (will be the reference point)
Lets manually plot it:
resolution------measured-----calculated-----error----CPU-----GPU
640x480---------237.2fps--------260fps------9.7%----23%-----32%
800x600---------196fps--------reference---------------23%-----50%
1024x768--------133.3fps---------137.5fps---3.2%----23%-----81%
1280x1024-------83.9fps---------89.5fps----- 6.7%----23%----136%
1600x1200-------58.6fps---------64.2fps------9.6%----23%----200%
Interesting the error grows when we get away from the reference point then probably it is not 50% CPU and 50%GPU in the begining. Probably a little more CPU (maybe 53%). But anyway it is mainly Amdhal, not so bad for a gamer´s guestimate
I will try it later using only the article 1 with its more precise data.
No I didnt because I was interested in the high details. With very fast rendering (low details) maybe the internals of the GPU (HW T&L) start to influence.
Good work Basic
