Re: memory reading and writing
From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/17/04
- Previous message: Kleidemos: "Re: Cmp"
- In reply to: Gyps: "Re: memory reading and writing"
- Next in thread: f0dder: "Re: memory reading and writing"
- Reply: f0dder: "Re: memory reading and writing"
- Reply: Gyps: "Re: memory reading and writing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 17 Jul 2004 19:44:07 GMT
Gyps wrote:
> Yes, well, I tried the test too, using the BIOS configuration
> menu to disable both the cache levels and tried booting
WindowsXP...
[ snip ]
> In terms of code execution speed...caches work nothing short
of
> a miracle...BTW, my system is 850Mhz Celeron with 133Mhz
SDRAM...
..._with_ caches, your system is a 850MHz Celeron...with them
disabled, it effectively might as well be a 133Mhz Celeron
(well, maybe more like 150Mhz or something...as, of course, not
all instructions access memory and those will return to
operating at 850MHz...quite a "st-st-st-stutter" the machine's
got there without the caches, eh? ;)...
But, yes, considering how simple the idea is - just to buffer
things up in the caches where possible - it has a dramatic
impact...because it allows the CPU to operate at its "proper"
speed and the difference between the two is often quite
pronounced...
Consider something like a 3GHz machine with only a 200Mhz bus or
whatever...makes quite a bit of difference...which is why we
notice that there's a kind of "trend" towards taking things away
from the CPU and distributing the processing around...AGP cards
being linked up to a special higher-speed bus between CPU, RAM
and the video card...and, in the current context, the point of
interest is the video memory that the video card carries...it's
usually far more than it strictly needs for only the framebuffer
even for the higher resolutions because the memory also acts as
a "cache" for "texture bitmaps" and such that it can get much
the same benefits as the CPU does in having a bit of extra
memory on-chip for "caching" things...and, indeed, the typical
speed difference between a "video RAM to video RAM" blit and
"system RAM to video RAM" blit is just as pronounced as with the
CPU and its caches...
It's really the "Achilles Heel" of modern PCs that, between
components, there's such a "bottleneck"...of course, as we're
seeing here, there's all manner of "tricks" used to get around
it...but this is a central issue to do with performance that
both hardware and software developers need to consider...after
all, something like developing a 5GHz CPU sounds impressive but
can anything else in the system keep up with it? Currently,
no...not even close usually...rather the CPU tends to do a whole
bunch of stuff in "batch" (with the L1 cache), so to speak, and
then it gets "flushed" to the rest of the system at a more
reasonable pace for the rest of the system to deal with...
And, as I say, much the same is actually increasingly true with
the video cards too...that's why they carry such large video RAM
memory buffers on them and then they are "loaded up" with
textures and vertices and so forth, in order that the video card
itself deals with things "locally" too...it's really much the
same "trick" that the CPU pioneered with the "caches" but the
video capabilities of PCs has now pushed so far forward that
it's clearly exceeding the problematic "bus bandwidth"
problems...remember, it's doing these tricks _in addition_ to
being typically hooked up to the special higher-speed AGP buses
(x2, x4, x8, etc. ;) which were introduced specifically for
video cards because of the bandwidth problems they were
beginning to encounter...
Soundcards also used to have such problems and had on-board
memory buffers for exactly the same reasons that you couldn't
simply "stream" it straight out of RAM, as the bus couldn't take
it...with PCI buses turning up, though, this was eased a little
and you could begin to actually stream sounds via the
bus...audio has more modest data transfer rates that the bus
speeds have caught up...but, then, saying that, if everyone
plays games with thousands of simultaneous sound effects and
speech and music - all with "3D" and doppler effects applied -
through their 7.1 speakers...indeed, there are "known issues"
with Creative soundcards with some motherboards and flakey XP
drivers where the "latency" gets too much and the sound comes
out garbled (yes, who says that you can't get horrible fuzzy
crackling "static" sounds with digital equipment anymore?
;)...it, indeed, "sits on the edge of the possible" with some
hardware combinations already...
The one thing I don't particularly like about this kind of thing
is that, until recently, all the stuff that was moved off the
CPU onto the hardware wasn't quite as programmable as it should
be...the new "shader" stuff on video cards is trying to rectify
it a little, where you actually send it a kind of set of
"assembly language" instructions...but, well, if this stuff is
going to be necessarily moved "off-CPU" then it would still be
nice if it was all still perfectly programmable...
Indeed, perhaps the perspective to be taken is to realise that
we're really talking about a multi-processor system, in effect
(just that the GPU(s) are "dedicated" CPU for graphics
processing and, though no-one seems to have coined such a term
for them yet, the "APU" (audio processing unit) on modern
soundcards that automatically applies 3D effects and such
:)...and that people are increasingly looking at dual-processor
systems and so forth...perhaps - blasphemy to some, mind you -
it's time to leave go of the "C" in CPU altogether and accept
that a _de-centalised_ system has more potential. if dealt with
properly...
To take the programmable idea to the extreme that these really
are just "co-processors" that you can load up with assembly
code, much like the CPU, and it's a multi-processor system, that
just has different "dedicated" CPUs - GPUs, APUs, etc. - for
different tasks...
[ snip ]
> Anyway, just one question though:
> If the bus speeds between main RAM and the CPU is, relatively
> speaking, quite slow, (as my 'trial boot' above clearly
showed),
> then copying a 'chunk' of data from main RAM to the L2 and
then
> the L1 cache should, mathematically speaking atleast, take the
> same amount of time it would have taken if the CPU had to
access
> the main RAM for each of those data items, one after the
other...??
Yes, quite right; That's why a "cache miss" actually carries a
rather heavy penalty...it does, in that instance, drop down to
being the speed it would have been without the caches (makes
some sense: if the caches don't have the memory then they aren't
used and it does "fall through" to main RAM)...what makes the
difference is that once this happens, the caches then _DO_ have
this memory (and its surrounding "neighbours")...so the next
time you access it, the caches _do_ have it and we don't get the
penalty of going to main RAM...
Hence, it's working in "bursts", so to speak...you jump to a
procedure and that _does_, for argument, get a "cache miss" and,
yup, it goes the main RAM at the relatively slow speed...BUT
once in the cache then any subsequent jumps to the same place
won't carry the penalty...and the cache doesn't only load up the
destination of the jump but grabs, as I say, a "chunk" (by the
way, this is not a technical term...I just like calling it a
"chunk" to get the basic idea of it being a whole section of
memory and not just only the DWORD or whatever you're trying to
access alone...without going into how "cache lines" work which
is actually the unit it works in...just being "abstract" there
:)...so, it grabs the subsequent instruction bytes into the
cache for that first "cache miss"...and, therefore, it can run
up to the end of that "chunk" without any penalty...then it
might get a "cache miss" again and have to go to main RAM
again...but it can then run this "burst" without delays up until
the next "cache miss"...
Seems a bit of an unsatisfactory way to go about things? Yeah,
maybe...but what's the alternative when the bus can't go that
fast? As I say, it's the main system "bottleneck" in PC
designs...and you probably wouldn't like the price of your PC if
it had a 1GHz bus installed to avoid the problem (you'll
probably need to contact a supercomputer manufacturer to "custom
build" such a thing for you, you see...they might also have to
reposition components to be closer together...and, if you've got
the money to afford it, they could install superconductors
rather than semi-conductors to eradicate all
resistance...unfortunately, there aren't any "room temperature
superconductors" yet - one of the mythical goals like "Cold
Fusion" that scientists chase after - so you'll have to put the
PC into some kind of refrigerator or something...run some liquid
nitrogen next to the system to keep it constantly well below
zero...need to avoid moisture in the air forming ice and
accidentally short-circuiting things, though...umm, perhaps you
could also put it in a vaccuum or something, maybe...can you see
all those $$$ dollar signs $$$ racking up in costs as I speak?
Exactly...but if we wait around, the scientists and hardware
people do eventually work out ways to speed things up and
introduce it gradually to the "mass-market" that mass-produces
and eradicates the costs ;)...
After all, if you tried to create the machine you have now back
in the '60s or '70s or whenever, then it would have been the
"supercomputer of all supercomputers" by quite a large
margin...and, if it was even possible at all
technologically-speaking, it would have cost billions upon
billions...I've a feeling, though, that the price you did pay
wasn't quite in that price range, yes? ;)...
Hey, NASA went to the Moon with only 32KB, apparently...and,
with Kennedy's promise, they were almost being handed blank
cheques (US: checks)...I mean, they're building space rockets,
after all...not a cheap "hobby" to have...
Mass production does produce miracles, indeed...I mean, how
prized was the "16KB expansion pack" to take 32KB up to 48KB or
whatever? These days, there are those "memory sticks" which have
MBs in something flat and that's probably smaller than your
keyring...which already makes 3.5 inch floppies with only 1.44MB
look a touch "prehistoric" that, indeed, people are considering:
"Do we actually need to have these increasingly useless things
stuck on the front of every PC anymore?"...and it really wasn't
all that long ago when a "double-sided disk drive" seemed so
impressive because it was _twice_ the 512KB of the machine's
system RAM...
It's actually interesting to see how the technology effects
things...
With the old Commodore 64 machines, the memory was actually just
as quick as the registers on the CPU...yup, they neatly ran at
the same speed (1MHz CPU only here, by the way :) that there was
only a few registers and, basically, everything was in the
system RAM because there was no point for not to be: Equally
fast to go to memory as to a register...with things typically on
cassette, you spent a few minutes loading the program and then
it was all in RAM from then on (well, except for things like the
"Summer / Winter Games" range of computer games...which loaded
each "Olympic event" from the cassette one at a time...but was
awkward because you had to reset the "counter" to mark where to
rewind back, if you wanted to play through all the events
again...hmmm, I was thinking the other day about why they don't
resurrect those games - to tie in with the actual Olympics, as
they did before - because they were really rather fun...and
often funny when one of the players (it was "multiplayer" in the
sense that - but this, of course, fully links into the whole
"Olympic" theme very well - one player had a turn then the next
player and then the next player, one at a time...so, it was also
a "spectator" thing at the same time when everyone else would
sit around laughing at how badly the other player was doing,
throwing the discus in the total wrong direciton...they actually
made very good "family games" but we don't see much of this
thing anymore with "first person shooters" everywhere ;) pressed
the wrong button and their little "pole vaulter" on the screen
pole vaulted too early and completely missed the mat, landing on
the track itself...you got a game and a kind of "sporting
outtakes" show at the same time...the "communal" game playing
stuff doesn't really happen anymore...even the consoles are
giving it all up for "on-line play" and stuff...maybe this
stuff'll make a come-back one day when people "rediscover" that
it could be rather fun :)...
Then with Atari ST and Amiga machines, they typically came with
512KB in their basic "home user" models and the disk drives were
the same kind of 3.5 inch floppies, having more disk capacity
than there was RAM...so, the floppy disk was kind of used a bit
like a "hard drive"...and software - especially games - would
commonly be written in "chunks" (say, loading each level one at
a time from the disk when you completed each level :)...
Then PCs had hard drives as standard and we know the kind of
design that inspired...but, increasingly, as "broadband" and the
internet increase, there's now almost an "obligation" on
software to be "on-line" in some way...and the palmtops (and
"gameboys", as the kind of "console" equivalent, dedicated for
games only :) are actually now just as good (better in some
regards) than full blown machines of the past but you can carry
these around with you...and these "memory sticks" and
"bluetooth" and that kind of thing are approaching the "sci-fi"
of the past...
Which is actually another argument against some of the "fixed
thinking" that often emerges because a technological change can
often completely redefine what's "normal" that things change all
around again...because, for instance, the software now typically
on mobile phones and palmtops are the old style of software that
could be feasibly written by lone developers as a "hobby"
(indeed, lots of the software for these things are quite
literally "ports" of old games and things that used to be on the
older "home micro" machines :) and not actually require "teams"
and big "projects" and Hollywood budgets to develop them...the
resurrection of the "bedroom / garage programmer" (which is what
Bill Gates started out as ;), who'd been declared "obselete" at
one point...they also have limitations on speed and size where
assembly language coding can make an important impact...
So, you have to take things with a pinch of salt...because,
indeed, these programmable parts on the new video cards actually
use a kind of "assembly language"...and as they are "graphics
dedicated" then the _general-purpose_ HLLs don't make sense for
this type of application...so assembly language has reclaimed a
little ground there again (until they develop special dedicated
graphics HLLs for the video card GPUs only and the cycle starts
all over again ;)...
One thing I have found interesting over the years is that the
"ubiquitous computing" idea is really having trouble getting
ground...it's the old "sci-fi" idea of technology that's so
"integrated" into things that you're not really noticing
them...there's been many attempts but it never quite "clicks"
with people...I'm beginning to wonder if this one of those
psychological things...like the idea of eating pills for food -
even if made technological possible - probably wouldn't actually
fly in practice because, well, people often _ENJOY_ cooking and
eating...people actually like their computers to have a "face"
and a "place" (a "computer room" :)...indeed, I can see there
being a potential "Clippy the paperclip" problem coming from
having a computer switch on the lights and microwave oven and
that kind of thing...no, not a problem of technology...but of
_psychology_...and, for sure, the "gimmick" won't last very long
that - wow! - you can "talk" to your house...that'll vanish to
be replaced by "stupid bloody house! I told it I wanted the food
microwaved by six but does it do it? Noooo!" / "Ummm, machines
don't forget...you forget to tell the computer, didn't you?" /
"No, I didn't! It must be a 'bug'!" *skulks in a corner
realising that this actually must be true and it must have been
them at fault*...expect deep resentment to happen, followed by
"house rage"...which is a bit like "road rage" but people start
attacking their own house because the "stupid computer!" is
getting on their nerves something terrible...
Why do the "dreamers" never consider these things when they are
dreaming their "sci-fi" dreams of flying cars and robots doing
the housework? I actually think it's all quite amusing...quite
nice to know that even these "Utopias" are actually very flawed
and completely human...hey, we _wouldn't_ want it to be
otherwise, really, would we? It'd be far, far too boring ;)...
I mean, come on, if you really had a "robot" rushing around your
house vacuuming things - "one of the family" - then it'll
inevitably get dragged into the family fights...yeah, even if it
doesn't have the slightest clue what's going on and just stares
blankly at the wall while the rest of the family are shouting
and throwing accusations at it...in fact, that's _BETTER_...you
can nag and insult the thing all day long and it never gets
upset with you...excellent! ;)...
Oh, indeed, I reckon maybe someone should write the more
realistic version of "robots" in a sci-fi book or movie, where
all manner of tensions and problems result from things like
telling the robot: "please tidy the garage" and then - oops - it
goes and throw outs your precious collection of Elvis records
that was stored in the corner of the garage because its
"subroutines" didn't quite realise the importance...oh, boy, is
that robot in BIIIIG trouble when you get home (heck, humans do
this kind of thing all the time and we have proper
intelligence - supposedly, anyway - that the robot with its more
basic "artificial intelligence" is going to mess things up all
the time when we have non-programmers with not particularly
logical thinking barking orders at them: "Huh, look at him
sitting there watching the football on TV all day
long...miserable lazy git...I ought to throw his lazy *** out
and get myself a better model, you know, Mr.Robot...wait, what
are you doing now, Mr.Robot? Noooo! Stop, I wasn't being
serious...could you please pull him back out of the trash can?
Thanks" ;)...
Beth :)
- Previous message: Kleidemos: "Re: Cmp"
- In reply to: Gyps: "Re: memory reading and writing"
- Next in thread: f0dder: "Re: memory reading and writing"
- Reply: f0dder: "Re: memory reading and writing"
- Reply: Gyps: "Re: memory reading and writing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]