Yes, and then they go and say that previous builds ran find on a 9600 but this one doesn't. Only a hack gets it to work on a 9600 to start off with, so why bother mentioning it?
That piques my curiousity as to why they mentioned that too. Maybe they had OS X.1 on it and just tryed it out, as they might of thought that since OS X is now faster acrossed the board, maybe they added pre-G3 support. (?!?)
I think what he means by 'debug code' is code that's sitting there doing nothing. Granted exception handling SHOULD ever throw any errors, but I'm not talking about that.
Ways of optimizing code:
1. making code not stink...do this by using design patterns* like a bad habit.
2. take out code that's not doing anything; this is code that was going to do something, but now is not only because you suddenly had an epiphany while taking a dump.
3. try to get the most use out of objects.
*linda rising has a doctorate in computer science, of which she has then produced/written books talking about design patterns, such as "Design Patterns in Communcations Software." I've met her in person, and she knows what she is talking about...(and she looks nothing like the picture, I don't know who the photographer is but she looks about 30 years older in that photo than she does in real life. Maybe it's all the biking she's been doing.)
Anyways, it's looking like that is maybe what they are working on for the next OS X.
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
OK. The purpose of cache is to, well, cache data from main memory due to a relatively slow memory bus. If your memory was as fast as your processor, even L2 cache wouldn't be needed. On the G4s, the slow system bus makes for a third level of cache - the L3 cache on QuickSilvers, MDDs, and PBG4s.
Out past the RAM is the hard disk, and data from the hard disk is already cached in ram (it's called a disk cache). Hard drives are SLOW (rotational speed being the bottleneck, not burst speed) and so programs only write to them or read from them when necessary.
The folllowing diagram shows the sizes, relationships, and transfer speeds of the various storage mechanisms in a G4 sytem:
Code:
----------- -----------
| L1 Data | | L1 Code |
| 32-64 KB | | 32-64 KB |
----------- -----------
^^ Really ^^
|| Fast ||
--------------------------
| L2 Cache |
| 256 KB |
--------------------------
^^ 2x133/167
|| MHz for G4e
--------------------------
| L3 Cache |
| 1-2 MB |
--------------------------
^^ 133/167
|| System bus
--------------------------
| RAM |
| 256MB - 2GB |
--------------------------
^^ Slow media
|| 5400-10k RPM
|| Fast bus
--------------------------
| HDD / Persistent Storage |
| Unboundedly Large |
--------------------------
So - there's not too much room for a L4 cache in a system like this. In fact, the only system where an L4 cache is ever possibly needed would be in a huge NUMA system.
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
The Mac OS X memory system already does this, which is why adding more memory on Mac OS X systems typically improves performance. The VM system always caches recently used code in main memory, and more memory in the system means it's able to cache more of that code.
There are many things that Apple can do to further optimize Mac OS X for performance and useability (which is a part of making something faster). You're number 1 is the primary one. Good code design takes a long time with several rewrites. To my knowledge, the Carbon API is not yet a preemptive multithreaded API, but a cooperative multithreaded one. Sooner a later, Apple will have to make it preemptive. PPC compiler maturity is still not very good, and the more time Apple can work on it, the better it'll get.
And this is par for the course for NeXT (Avi Tevanian) style system releases. 1st release is to get working. 2nd release is to fix the bugs. 3rd release is to get it working faster, perhaps add features. Further on, optimize more and add features until a new rewrite warrants a new system version.
So - there's not too much room for a L4 cache in a system like this.
If you have L1, L2, and L3 in their std locations (where the L3 is directly connected to the CPU but not manufactured on the same piece of silicon) then you do have a spot for 'L4'.
There's a memory controller/Northbridge chip between the CPU and main RAM. A bank of memory _in_ that memory controller would then be L4.
This is the same thing that is flying around in one of the other threads, but it is being called "L3" there because those systems don't have a cache external-to-but-attached-to the CPU (which is the L3 in the _current_ systems).
Ok, I reread all that, and it's still baffling I try out my sub-par ASCII drawing skills.
Current G4-with-L3 setup:
Code:
L3
|
CPU(includes L1 & L2)
|
Northbridge-RAM
|
Othercrapola.
970-with-no-L3-off-CPU:
(Because the die for the 970 doesn't have any tags/arrangements to connect to an L3 from what was released at last October's announcement. This doesn't mean we won't see a 970+ instead or something)
Code:
CPU(includes L1 & L2)
|
Northbridge-RAM
|
Othercrapola.
970 _with_ L3 - but on the northbridge:
Code:
CPU(includes L1 & L2)
|
Northbridge(includesL3)-RAM
|
Othercrapola.
All I was trying to say was that _if_ you had cache both in the position on some G4's, _and_ you have cache inside the northbridge chip -> you have four caches, and it would make sense to call the northbridge-cache "L4".
Hypothetical-non-existant-setup
Code:
L3
|
CPU(includes L1 & L2)
|
Northbridge(includesL4)-RAM
|
Othercrapola.
But for this to make any sense, L1<<L2<<L3<<L4. That is, L4 would need to be _large_. 32MB as a minimum, and pricing would start at "ouch".
This means we'll have to put up with Jobs saying "boom!" a thousand times like Madden off his ritalin.
Yah, but wouldn't that be pretty funny? Kinda like the squirrel at http://www.threebrain.com/weeeeee.shtml but instead of saying... blah, bleh, blah, weeeeeeeeeeee:
He would say.. (really fast) wedothephotoshopjiggyandthenpushafewbuttons and booooooooooooooom. and then booom, and BOOOOOOOOOOOOOM. Wham, it's done.
Anonymous Karma - your idea with the L4 would be sweet,especially coupled with a high-speed bus.
AirSluf - Are you saying commonly used hard drive code, when cached in RAM would not and should not be called L4 cache?
>>>I was wondering if speed would still be faster if a standard stick of RAM could be used as the L4 cache with in the North Bridge. Granted, the RAM would be off die, but hey it's an idea at least. (You were thinking on die 32MB cache weren't you?)
dobby - could we call swap space level 80 cache, because it sucks for speed. (hey but it does help on systems where RAM isn't readily available.)
its not actually the OS that is making the speeds greater, but the fact apple has decided to add a turbo light to their new macs
Actually, there's a nice little shortcut to do this for you: just hold down the command-key and 'quick'... speed your other applications right up it will
Yes and no. The code that is resident in physical RAM is just that, resident in RAM. Calling RAM a L4 cache in that context (like I have seen in several descriptions of Mach, not just from here) confuses the issue with what cache is normally referred to as -- a low capacity but extremely low latency physical memory between the CPU logic core and main RAM.
Main RAM does exhibit those same characteristics compared to a hard drive, but it already has an industry standard description RAM! I would just like to hold the line someplace before we get the equivalent of calling the trash truck collector a Sanitary Engineer.
Just don't get me started on calling programmers "Software Engineers" as a blanket policy. Doh! Grrrrrrr. Don't let ACM know I said that...
Heh, I see the whole terminology thing. Do you understand what I mean for this idea:
RAM is used just as normal RAM, but instead, in the parts of RAM that are not being used the CPU woud cache data from the HD, or whatever falls out of the other caches, so as to use up all RAM at any given moment so that speed is less of an issue?
I do understand that RAM, in it's inherent form is L4 cache, as it stores data coming from the HD, and feeds the processor, caches. I'm looking at the 'free space' in RAM. L4 was the best term I could think of at the time.
I had originally heard about this idea about a year ago. It's a pretty cool idea, I thought then. When people were talking about it they said it was going to be for the next major release of OS X, I assumed they meant OS X.3.
Already you can notice a speed difference in going from OS X.1 to X.2, I'm very curious as to what panther will bring in it's final version.
Quote:
Originally posted by AirSluf
The VM manager in 10.2 actually gets a lot closer to this style of operation than the pre-10.2 versions did. By definition anything that has is in a L1/2/3 cache will also be in main RAM. Because of 10.2's use of main memory working sets, more recently accessed information will have priority when page-outs are forced. The working sets will also pull in more from the HD than just the requested bytes in a single memory access.
The whole working set for a application will normally be loaded, which essentially does what you have described but in a customized to machine usage manner. Of course it doesn't predict perfectly, but has made a significant difference in speed by avoiding a lot of previously required VM swapping.
SGI is a pretty awesome company for graphics, I went to our CBS studio and they were using those boxes for the on screen graphics used for displaying charts live during news casts.
The boxes incorporate transparency really well, one thing I noticed.
Supposedly OS X panther will go the route of tons of optimizations, at least that's what I'm hearing and hopefully will become a faster O.S. than 9 is in the way of GUI Operations, as well as individual program startup times [IPST].
Everytime I read about someone even mentioning OS X on a pre-G3 machine I want to kick them in the face.
NO ONE CARES
Yeah really if you are using a computer that is that old well then I'm sorry. What software made today can one exactly run? I imagine IE must take a LOOONG time just to load in. Upgrade.
Yeah really if you are using a computer that is that old well then I'm sorry. What software made today can one exactly run? I imagine IE must take a LOOONG time just to load in. Upgrade.
See and that's really too bad, but that's kinda where the economy goes, except everyone doesn't push upgrading as hard as other companies (micro$oft being one of the top five) so we see upgrading maybe every 3-4years as marginally adequate. Gamers probably do it once every year to 6 months (mac or wintel). Video editors, the same.
On a side note, does anyone 'know anyone with pictures of the new towers/hardware coming out?"
I'm kinda weary about what will happen on June 23rd. I think at this point it will just be OS X Panther, and then an announcement of the PPC970 only if they can make that date with decent prototypes.
I could really see the September deadline as viable for such towers. I really wish they would be updated/available sooner, though.
I'm kinda weary about what will happen on June 23rd. I think at this point it will just be OS X Panther, and then an announcement of the PPC970 only if they can make that date with decent prototypes.
I could really see the September deadline as viable for such towers. I really wish they would be updated/available sooner, though.
Now Slashdot is saying that there will be G5's at WWDC, based on rumors from this site.
Yah, it would seem probable as there are supposed shipments being thrown out by IBM, and orders over seas to begin building the new models.
Prototypes have existed for a long time, the stuff I wrote before, just ignore it. I was in a hurry to get some where and threw words out.
Comments
Originally posted by Clive
Yes, and then they go and say that previous builds ran find on a 9600 but this one doesn't. Only a hack gets it to work on a 9600 to start off with, so why bother mentioning it?
That piques my curiousity as to why they mentioned that too. Maybe they had OS X.1 on it and just tryed it out, as they might of thought that since OS X is now faster acrossed the board, maybe they added pre-G3 support. (?!?)
I think what he means by 'debug code' is code that's sitting there doing nothing. Granted exception handling SHOULD ever throw any errors, but I'm not talking about that.
Ways of optimizing code:
1. making code not stink...do this by using design patterns* like a bad habit.
2. take out code that's not doing anything; this is code that was going to do something, but now is not only because you suddenly had an epiphany while taking a dump.
3. try to get the most use out of objects.
*linda rising has a doctorate in computer science, of which she has then produced/written books talking about design patterns, such as "Design Patterns in Communcations Software." I've met her in person, and she knows what she is talking about...(and she looks nothing like the picture, I don't know who the photographer is but she looks about 30 years older in that photo than she does in real life. Maybe it's all the biking she's been doing.)
Anyways, it's looking like that is maybe what they are working on for the next OS X.
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
Originally posted by willywalloo
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
OK. The purpose of cache is to, well, cache data from main memory due to a relatively slow memory bus. If your memory was as fast as your processor, even L2 cache wouldn't be needed. On the G4s, the slow system bus makes for a third level of cache - the L3 cache on QuickSilvers, MDDs, and PBG4s.
Out past the RAM is the hard disk, and data from the hard disk is already cached in ram (it's called a disk cache). Hard drives are SLOW (rotational speed being the bottleneck, not burst speed) and so programs only write to them or read from them when necessary.
The folllowing diagram shows the sizes, relationships, and transfer speeds of the various storage mechanisms in a G4 sytem:
----------- -----------
| L1 Data | | L1 Code |
| 32-64 KB | | 32-64 KB |
----------- -----------
^^ Really ^^
|| Fast ||
--------------------------
| L2 Cache |
| 256 KB |
--------------------------
^^ 2x133/167
|| MHz for G4e
--------------------------
| L3 Cache |
| 1-2 MB |
--------------------------
^^ 133/167
|| System bus
--------------------------
| RAM |
| 256MB - 2GB |
--------------------------
^^ Slow media
|| 5400-10k RPM
|| Fast bus
--------------------------
| HDD / Persistent Storage |
| Unboundedly Large |
--------------------------
So - there's not too much room for a L4 cache in a system like this. In fact, the only system where an L4 cache is ever possibly needed would be in a huge NUMA system.
Originally posted by willywalloo
I'm curious if a big speed increase comes from a sub software archetecture that allows extra RAM to be treated as "L4 cache" ( I saw it in a document a while back, not completely sure of it's truth, but sounds intriguing as an idea anyway. )
The Mac OS X memory system already does this, which is why adding more memory on Mac OS X systems typically improves performance. The VM system always caches recently used code in main memory, and more memory in the system means it's able to cache more of that code.
There are many things that Apple can do to further optimize Mac OS X for performance and useability (which is a part of making something faster). You're number 1 is the primary one. Good code design takes a long time with several rewrites. To my knowledge, the Carbon API is not yet a preemptive multithreaded API, but a cooperative multithreaded one. Sooner a later, Apple will have to make it preemptive. PPC compiler maturity is still not very good, and the more time Apple can work on it, the better it'll get.
And this is par for the course for NeXT (Avi Tevanian) style system releases. 1st release is to get working. 2nd release is to fix the bugs. 3rd release is to get it working faster, perhaps add features. Further on, optimize more and add features until a new rewrite warrants a new system version.
Originally posted by Anonymous Karma
So - there's not too much room for a L4 cache in a system like this.
If you have L1, L2, and L3 in their std locations (where the L3 is directly connected to the CPU but not manufactured on the same piece of silicon) then you do have a spot for 'L4'.
There's a memory controller/Northbridge chip between the CPU and main RAM. A bank of memory _in_ that memory controller would then be L4.
This is the same thing that is flying around in one of the other threads, but it is being called "L3" there because those systems don't have a cache external-to-but-attached-to the CPU (which is the L3 in the _current_ systems).
Ok, I reread all that, and it's still baffling
Current G4-with-L3 setup:
L3
|
CPU(includes L1 & L2)
|
Northbridge-RAM
|
Othercrapola.
970-with-no-L3-off-CPU:
(Because the die for the 970 doesn't have any tags/arrangements to connect to an L3 from what was released at last October's announcement. This doesn't mean we won't see a 970+ instead or something)
CPU(includes L1 & L2)
|
Northbridge-RAM
|
Othercrapola.
970 _with_ L3 - but on the northbridge:
CPU(includes L1 & L2)
|
Northbridge(includesL3)-RAM
|
Othercrapola.
All I was trying to say was that _if_ you had cache both in the position on some G4's, _and_ you have cache inside the northbridge chip -> you have four caches, and it would make sense to call the northbridge-cache "L4".
Hypothetical-non-existant-setup
L3
|
CPU(includes L1 & L2)
|
Northbridge(includesL4)-RAM
|
Othercrapola.
But for this to make any sense, L1<<L2<<L3<<L4. That is, L4 would need to be _large_. 32MB as a minimum, and pricing would start at "ouch".
Dobby.
Originally posted by strobe
Groan...
This means we'll have to put up with Jobs saying "boom!" a thousand times like Madden off his ritalin.
Yah, but wouldn't that be pretty funny? Kinda like the squirrel at http://www.threebrain.com/weeeeee.shtml but instead of saying... blah, bleh, blah, weeeeeeeeeeee:
He would say.. (really fast) wedothephotoshopjiggyandthenpushafewbuttons and booooooooooooooom. and then booom, and BOOOOOOOOOOOOOM. Wham, it's done.
Anonymous Karma - your idea with the L4 would be sweet,especially coupled with a high-speed bus.
AirSluf - Are you saying commonly used hard drive code, when cached in RAM would not and should not be called L4 cache?
Originally posted by Nevyn
Hypothetical-non-existant-setup
code:
------------------------------------------------------------------------
L3
|
CPU(includes L1 & L2)
|
Northbridge(includesL4)-RAM
|
Othercrapola.
------------------------------------------------------------------------
>>>I was wondering if speed would still be faster if a standard stick of RAM could be used as the L4 cache with in the North Bridge. Granted, the RAM would be off die, but hey it's an idea at least. (You were thinking on die 32MB cache weren't you?)
dobby - could we call swap space level 80 cache, because it sucks for speed. (hey but it does help on systems where RAM isn't readily available.)
Originally posted by ast3r3x
its not actually the OS that is making the speeds greater, but the fact apple has decided to add a turbo light to their new macs
Actually, there's a nice little shortcut to do this for you: just hold down the command-key and 'quick'... speed your other applications right up it will
Originally posted by AirSluf
Yes and no. The code that is resident in physical RAM is just that, resident in RAM. Calling RAM a L4 cache in that context (like I have seen in several descriptions of Mach, not just from here) confuses the issue with what cache is normally referred to as -- a low capacity but extremely low latency physical memory between the CPU logic core and main RAM.
Main RAM does exhibit those same characteristics compared to a hard drive, but it already has an industry standard description RAM! I would just like to hold the line someplace before we get the equivalent of calling the trash truck collector a Sanitary Engineer.
Just don't get me started on calling programmers "Software Engineers" as a blanket policy. Doh! Grrrrrrr. Don't let ACM know I said that...
Heh, I see the whole terminology thing. Do you understand what I mean for this idea:
RAM is used just as normal RAM, but instead, in the parts of RAM that are not being used the CPU woud cache data from the HD, or whatever falls out of the other caches, so as to use up all RAM at any given moment so that speed is less of an issue?
I do understand that RAM, in it's inherent form is L4 cache, as it stores data coming from the HD, and feeds the processor, caches. I'm looking at the 'free space' in RAM. L4 was the best term I could think of at the time.
Already you can notice a speed difference in going from OS X.1 to X.2, I'm very curious as to what panther will bring in it's final version.
Originally posted by AirSluf
The VM manager in 10.2 actually gets a lot closer to this style of operation than the pre-10.2 versions did. By definition anything that has is in a L1/2/3 cache will also be in main RAM. Because of 10.2's use of main memory working sets, more recently accessed information will have priority when page-outs are forced. The working sets will also pull in more from the HD than just the requested bytes in a single memory access.
The whole working set for a application will normally be loaded, which essentially does what you have described but in a customized to machine usage manner. Of course it doesn't predict perfectly, but has made a significant difference in speed by avoiding a lot of previously required VM swapping.
It is a big deal compared to OS9 but then so is SMP or even MP.
OS X is not exactly a rip snorter as far as unix kernals's go.
It does beat every other OS when it comes to graphics (cept perhaps SGI).
Dobby.
The boxes incorporate transparency really well, one thing I noticed.
Supposedly OS X panther will go the route of tons of optimizations, at least that's what I'm hearing and hopefully will become a faster O.S. than 9 is in the way of GUI Operations, as well as individual program startup times [IPST].
-walloo.
NO ONE CARES
Originally posted by cinder
Everytime I read about someone even mentioning OS X on a pre-G3 machine I want to kick them in the face.
NO ONE CARES
Yeah really if you are using a computer that is that old well then I'm sorry. What software made today can one exactly run? I imagine IE must take a LOOONG time just to load in. Upgrade.
Originally posted by ouroboros
Yeah really if you are using a computer that is that old well then I'm sorry. What software made today can one exactly run? I imagine IE must take a LOOONG time just to load in. Upgrade.
See and that's really too bad, but that's kinda where the economy goes, except everyone doesn't push upgrading as hard as other companies (micro$oft being one of the top five) so we see upgrading maybe every 3-4years as marginally adequate. Gamers probably do it once every year to 6 months (mac or wintel). Video editors, the same.
On a side note, does anyone 'know anyone with pictures of the new towers/hardware coming out?"
Originally posted by willywalloo
On a side note, does anyone 'know anyone with pictures of the new towers/hardware coming out?"
Originally posted by NETROMac
yah, you know me pretty well.
I'm kinda weary about what will happen on June 23rd. I think at this point it will just be OS X Panther, and then an announcement of the PPC970 only if they can make that date with decent prototypes.
I could really see the September deadline as viable for such towers. I really wish they would be updated/available sooner, though.
Originally posted by willywalloo
yah, you know me pretty well.
I'm kinda weary about what will happen on June 23rd. I think at this point it will just be OS X Panther, and then an announcement of the PPC970 only if they can make that date with decent prototypes.
I could really see the September deadline as viable for such towers. I really wish they would be updated/available sooner, though.
Now Slashdot is saying that there will be G5's at WWDC, based on rumors from this site.
Yah, it would seem probable as there are supposed shipments being thrown out by IBM, and orders over seas to begin building the new models.
Prototypes have existed for a long time, the stuff I wrote before, just ignore it. I was in a hurry to get some where and threw words out.
later.