>> I meant that it's sad that we don't have RAM that can perform as fast 
>> as the CPU itself.
>>
>> [Or rather... I guess we do, since that must be what they make the L1 
>> cache out of. But the L1 cache is tiny, so...]
> 
> And, most importantly, it is very close to the CPU.
> 
> It's a cost/benefit thing, for $X how do you make the fastest computer?  
> The answer is to have a big slab of slow RAM, and progressively smaller 
> bits of faster RAM.  Trying to do it another way will not make the 
> fastest machine for a given amount of money.

It just seems slightly crazy having a CPU that's hundreds of times 
faster than RAM, and using caching is a trick to try to hide this 
inescapable fact.

I wonder... if money was no object, *could* you actually have a 1GB L1 
cache?? Or is it actually not possible for some other reason?

Post a reply to this message

> It just seems slightly crazy having a CPU that's hundreds of times faster 
> than RAM, and using caching is a trick to try to hide this inescapable 
> fact.

It's not crazy, it's a clever idea to get more performance for less money.

> I wonder... if money was no object, *could* you actually have a 1GB L1 
> cache?? Or is it actually not possible for some other reason?

I'm no expert, but the length of the tracks from the farthest away bit of L1 
cache to the CPU might be a problem.

Post a reply to this message

scott schrieb:
> Yes, if we upset the Almight Cache, *shock* we might drop back to the 
> performance levels of the fastest RAM available.  The cache is there to 
> *speed up* stuff, I have no idea why you'd want a machine with a CPU 
> running at the same speed as the fastest RAM available, you're then 
> going to get the same levels of performance as if you upset the cache 
> continuously!

Just as a side note: Cache technically /is/ RAM.

Not "main memory" though.

(Nor is it typically DRAM, but SRAM instead: Way faster, and way more 
expensive...)

Post a reply to this message

scott schrieb:
> I'm no expert, but the length of the tracks from the farthest away bit 
> of L1 cache to the CPU might be a problem.

If money would be no issue, maybe "stacking" dice would be an option to 
keep lines short.

Then again, there's that heat transfer problem...

Post a reply to this message

> Then again, there's that heat transfer problem...

Hmm yes, given that fast RAM chips on some GPUs need heatsinks, having a 
whole GB at L1 speeds is probably going to cook itself instantly.

Post a reply to this message

Invisible schrieb:
> It just seems slightly crazy having a CPU that's hundreds of times 
> faster than RAM, and using caching is a trick to try to hide this 
> inescapable fact.

Look at it this way: /Despite/ your slow DRAM main memory, you can still 
/benefit/ from a madly fast CPU core. (Or multiple of them, for that 
matter.) Isn't that a great thing actually?

Post a reply to this message

scott schrieb:
>> Then again, there's that heat transfer problem...
> 
> Hmm yes, given that fast RAM chips on some GPUs need heatsinks, having a 
> whole GB at L1 speeds is probably going to cook itself instantly.

Then again, maybe not. SRAMs - which AFAIK are the only type of memory 
that would do that job - are freakishly huge compared to DRAMs, so for 
the same amount of memory you'd need about 30 times the die area - at 
the benefit of also having 30 times better heat transfer.

Furthermore, SRAM cells consume virtually no power as long as they are 
idle, and read access costs only the power to drive the address select 
and output lines. DRAM cells, on the other hand, need additional power 
to perform a full rewrite after each read access - and they need to be 
refreshed frequently, which costs power as well.

I'm not sure how much of a difference it makes, but I imagine SRAM to 
consume quite a good deal less power on the whole.


Still - given that caches in modern CPUs appear to occupy something like 
50% or more of the die area, and that's just something like 10 MB, you'd 
have to stack something like 50 chips on top of each other for 1 GB... I 
don't think there's any way to bring 1 GB of memory close enough to the 
CPU to access it at L1 or even L2 speed.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   The main reason is that the GPU sets the limit, not the CPU. If the CPU
> > gets fast enough, it will just sit idle while the GPU renders a frame.
> > Adding more cores is not going to help that.

> That's only part of the story.

> The other part is "AI", physics sim and stuff like that. If you've maxed 
> out the GPU and have no way to add visual incentives to buy, you can 
> start focusing on making the gameplay more complex.

  Except that you can't. Not really.

  AI and physics is not really something which you can tune up or down
depending on your CPU speed. They are not like graphics: While graphical
quality can be tuned up and down without affecting gameplay in any way,
AI and physics cannot: If you change them, you are effectively changing
the gameplay. Things won't behave in the same way anymore. It might affect
the difficulty of the game (something which might be cool, but not I don't
anyone would be happy with "you can't play this game at hard difficulty
because your CPU is too slow") or even break it completely (eg. if some
physics simulation is too poor, some puzzle might become unsolvable, or
whatever).

  When you create a game, you have to set its AI and physics quality,
and then it will be settled in stone. If the CPU is so fast that it can
calculate them easily for each frame, adding even more cores is not going
to change anything.

  In fact, even if a faster GPU would allow for a higher framerate, that
would still not affect the quality of the AI and physics. It's not like
the CPU would be instructed to calculate more if the framerate goes up
(because, as said, that would change the gameplay). The results will simply
be interpolated more frequently.

  If you were playing a computer chess game, that would be a completely
different story. However, regular computer games are not like that. They
are rather deterministic (ie. what happens doesn't depend on the speed
of your CPU).

  One thing which a faster CPU can be useful for is for calculating additional
visual effects which cannot be calculated by the GPU. In other words, if
your CPU is fast enough, you could turn on certain visual effects (which
require more CPU power to show). OTOH, nowadays more and more of the visual
tasks are submitted to the GPU, so the CPU has less and less to do per frame.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  The main reason is that the GPU sets the limit, not the CPU. If the CPU
> > gets fast enough, it will just sit idle while the GPU renders a frame.
> > Adding more cores is not going to help that.

> More realistic physics and AI!

  If you tune down the physics and AI because the CPU is not fast enough
to calculate them, you will be drastically changing gameplay. It would not
be just a cosmetic change. I have never heard of any game doing that
(except for games where AI is the whole idea, eg. computer chess, but
that's a completely different category of games).

  Thus after a certain point, when your current CPU can calculate the
physics and AI just fine, adding more cores won't change anything.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 28 Aug 2009 10:22:53 +0200, Invisible <voi### [at] devnull> wrote:
> Where in the name of God can you get 12 Mbit/sec? I thought 8 was the  
> maximum that ADSL supports...

You really need to start catching up with modern technology.  
Alternatively, you could learn to JFGI.

http://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line#ADSL_standards



-- 
FE

Post a reply to this message