intel and apple (here we go again...)

[stigmata]

I'm still right about everything else though  :wink:

What, you mean on all the points you've been proven thoroughly incorrect? The ones you refuse to defend, even after having been proven to be both wrong and in incomplete possession of the facts?

[rusty]

I'm still right about everything else though  :wink:

What, you mean on all the points you've been proven thoroughly incorrect? The ones you refuse to defend, even after having been proven to be both wrong and in incomplete possession of the facts?

Good grief. Enough already. .  

You have still to prove anything.  All that you've done is to quote another persons ( completely innacurate) articles, and without actually giving any solid figures on what each test-case was doing apart from a timing in seconds.

And even then; they were system timings, not CPU performance timings. You've been acting as if they'e the same thing.  

No amount of CPU clock-speed increases, or increases to the speed of the FSB will change the fact that as far I can tell; Intel CPU's are nothing but badly-designed CPU'S which have only ever been "improved" with band-aid sollutions at the cost of ever dimishing returns.

Go read the official docs yourself if you want, all you need to do is sign up for developer access on the Intel site.  It's free and you'll have instant access.

But for whatever reasons, Apple are going with Intel.  Things are changing though, and I don't think that simply making existing CPU's multi-core will be enough to keep up.

That's it. I'm through.

[Shmi]

edit: taken out and pmed

[Knightslugger]

This is so confusing that i cant keep up (Minus the flammage, that's easy)!  Programing and Processor architectiure is so over my head...  I guess none of this is really improtant to me if i cant understand it.  

The only question i really have now is:  Is the Intel switch going to be a system improvement or is the performance negligible at best?

[rusty]

This is so confusing that i cant keep up (Minus the flammage, that's easy)!  Programing and Processor architectiure is so over my head...  I guess none of this is really improtant to me if i cant understand it.  

The only question i really have now is:  Is the Intel switch going to be a system improvement or is the performance negligible at best?

Ugh...'s late.  

Over the current generation of Power PC chips, I'd say that the faster clock and FSB speeds of Intel chips offer definite improvements in the short term.

But after that? Who's to say...without atleast some departure from the tradtional PC model of doing things or abadoning thier own support for legacy processors, I think Intel are going to have a hard time keeping up.

[Knightslugger]

This is so confusing that i cant keep up (Minus the flammage, that's easy)!  Programing and Processor architectiure is so over my head...  I guess none of this is really improtant to me if i cant understand it.  

The only question i really have now is:  Is the Intel switch going to be a system improvement or is the performance negligible at best?

Ugh...'s late.  

Over the current generation of Power PC chips, I'd say that the faster clock and FSB speeds of Intel chips offer definite improvements in the short term.

But after that? Who's to say...without atleast some departure from the tradtional PC model of doing things or abadoning thier own support for legacy processors, I think Intel are going to have a hard time keeping up.

Short term is all i'm interested in.  Since this is going to be an Apple/Intel long term venture, Intel has to be aware of what it must do.  If that means changing the way they make their processors or how they work, so be it.   anyone else?

[GiantRobot]

Instead of thinking about memory caches....think instead of "local memory".  The programmer is responsible for making sure that data is in local memory to be operated on, and on multiple CPU system this especially handy as you can then stagger access to for loads/writes ensuring that very little time is spent waiting for the bus to become free.

The N64 and PS2 do this using a very flexible (and fast) DMA controller.  One of the great features the PS2 DMA controller is that you can create DMA chains, of non-contiguous areas of memory, and lets the controller issue commands to the CPU (such as, "start processing now", "load this micro code program" etc.)

Having a cache mechanism that is responsible for moving data around RAM is horrible.  You can never be 100% sure as to when your data will be in cache, and when it will not be in cache.  

In OOP this is a big issue for languages such as C++ where a call to a single virtual function will possible cause many D$ and I$ misses before and after it is returns.

And another thing...when you think that somebody is wrong, it might be best to ask them; "please explain your reasoning" rather than "what the hell are you talking about".

I think the "what the hell are you talking about" is entirely justified because this is a post full of misconceptions. From a programming perspective you don't have to do much if any low level memory management unless you're writing entirely in assembly. Even this you're doing quite a bit of abstracted memory work.

You seem to have really misunderstood what I wrote suggesting you're not quite as familiar with the subject matter as you think you are. A processor's cache is not responsible for moving data around on a computer, it is only used to store data and instructions that are locally relevant to whatever job the processor's working on right then. Instructing the memory controller to fetch something out of system memory or route data to a device doesn't mean that information all has to filter through the processor's cache.

I don't know why you're going on about OOP programming, the assembly built from C++ source is quite a bit different in logical order than the original code. Assembly doesn't have any concept of virtual functions or templates or any other aspect of high level languages. A virtual function has no more chance of a cache miss than some random class method. Again, high level concepts in languages like Java, C++, SmallTalk, etc. have little to do with the actual object code being run during execution.

[lg_alucard]

Knightslinger, in the short term it will allow Apple to advance their systems performance since IBM isn't planning on it and most importantly they will be able to 'upgrade' their laptop line of computers.  Personally though the G4 laptop performs great for me heh ^_^

[rusty]

I think the "what the hell are you talking about" is entirely justified because this is a post full of misconceptions. From a programming perspective you don't have to do much if any low level memory management unless you're writing entirely in assembly. Even this you're doing quite a bit of abstracted memory work.

Please explain this to me?  Do you really think that having to be mindful of what the cache is doing is a low-level thing?  Man....I wonder if the Adobe guys think that?  If  so, then no wonder thier software sucks in terms of performance.

You seem to have really misunderstood what I wrote suggesting you're not quite as familiar with the subject matter as you think you are. A processor's cache is not responsible for moving data around on a computer, it is only used to store data and instructions that are locally relevant to whatever job the processor's working on right then. Instructing the memory controller to fetch something out of system memory or route data to a device doesn't mean that information all has to filter through the processor's cache.

Exactly!! I think you're the one missing the point here, or atleast not getting what I've said.  Maybe it should be the job of the DMAC to perform this task as well.  

I'm saying that the DMAC controller should be cabale of loading data into the cache/local memory and what is more; the programmer should atleast have the option of accessing the cache as addressable memory space instead of some transparent mechanism that behaves differently between certain processor revisions.

What the tradtional DMA controller does is irrelevant to this discussion. I'm talking about what the DMA controllers in well thought out hardware does.

I don't know why you're going on about OOP programming, the assembly built from C++ source is quite a bit different in logical order than the original code. Assembly doesn't have any concept of virtual functions or templates or any other aspect of high level languages. A virtual function has no more chance of a cache miss than some random class method. Again, high level concepts in languages like Java, C++, SmallTalk, etc. have little to do with the actual object code being run during execution.

Hmm..okay.  A virtual function call goes something like this

* Load the v-table pointer. The chances are, your class is already in D$
* Access the v-table entry ( a D$ miss will happen here)
* Call the method ( the usual I$ miss will happen here, reagrdless of OOP or no).  D$ miss is likely to happen here as you operate on the class data, due to the D$ being refreshed earlier whn loading the v-table pointer.
* Return from the method.

So every time you call a virtual method, you will inccur an extra miss.  There's really good Sony presentation called "Why C++ is bad for perfromance".  I'll see f I can dig it up for you to have a look at.

So...what happens if each method calls a whole chain of virtual methods?  How many extra D$ misses are going to happen that you may not usually encounter?  

What if your app is OOP heavy and uses a LOT of ploymorphism?  I can't give you the timiings on the PC, but a single D$ miss on the PS2 is equivilant to 32 vector multiplies.  On the P4 that's roughly 256 clock-cycles (give or take a few).

Caches misses are bad, and although they're less less of a performance hit on desktop processors they can still have a pretty big impact on how long your PC spends doing a certain task.

[GiantRobot]

Caches misses are bad, and although they're less less of a performance hit on desktop processors they can still have a pretty big impact on how long your PC spends doing a certain task.

Please don't think that a single Sony presentation is giving you enough insight to argue what is and isn't good microprocessor engineering. Sony's problems directly relate to how their processors interact with main memory and how their software manages memory. In a multitasking and memory protected operating system it is not possible to have any cache on the system mapped directly for software to monkey with. Modern operating systems don't expose memory as some huge chunk of definite size that the software can or should do what it pleases with. A Playstation is an entirely different beast.

Software doesn't get access to the details of the processor cache because individual implementations are non-portable, you'd have to write different code for every processor family the program was intended to run on. Sticking to the ISA's abstraction lets your code run on any chip supporting that architecture. You complain about different styles of caches working differently between different processor revisions yet want a system that would only exacerbate this problem. Cache misses are not world ending problems on modern processors. Microprocessor engineers have gone to great lenths to minimize the problems caused by cache missed with speculative, out of order processing. Even if an operation causes a cache miss and ends up needing to access main memory it can be stuck on the back burner while another operation to finishes. A Pentium 4 can have up to 126 in-flight instructions, a PowerPC 970 can have about 215.

[rusty]

Caches misses are bad, and although they're less less of a performance hit on desktop processors they can still have a pretty big impact on how long your PC spends doing a certain task.

Please don't think that a single Sony presentation is giving you enough insight to argue what is and isn't good microprocessor engineering. Sony's problems directly relate to how their processors interact with main memory and how their software manages memory.

Well...no.  I'm only giving you an example of where a parallel-processor architecture makes good use of a very small CPU controlled cache, and local memory mapped to each unit.

In a multitasking and memory protected operating system it is not possible to have any cache on the system mapped directly for software to monkey with.
 Modern operating systems don't expose memory as some huge chunk of definite size that the software can or should do what it pleases with. A Playstation is an entirely different beast.

No...because mapping and protection of memory in the case of x86 based CPU's and clones is all controlled by the processors itself.   A prime example of this is that the CPU can accress video RAM directly.

In real-mode  you always knew that video ram start at segment 0xa000.  When we moved tro protected mode, all you had to do was to create a protected mode descriptor to map that real-mode segment to protected mode memory.  The same thing goes for extended memory space in SVGA and current generation cards that went beyond the 64k limit.

So in theory....you CAN map extra resources into memory (such as processor local memory).

Software doesn't get access to the details of the processor cache because individual implementations are non-portable, you'd have to write different code for every processor family the program was intended to run on. Sticking to the ISA's abstraction lets your code run on any chip supporting that architecture. You complain about different styles of caches working differently between different processor revisions yet want a system that would only exacerbate this problem. Cache misses are not world ending problems on modern processors. Microprocessor engineers have gone to great lenths to minimize the problems caused by cache missed with speculative, out of order processing. Even if an operation causes a cache miss and ends up needing to access main memory it can be stuck on the back burner while another operation to finishes. A Pentium 4 can have up to 126 in-flight instructions, a PowerPC 970 can have about 215.

Well...yeah. You're perfectly correct, apart from wanting a sollution that makes the problem worse.  I have to be somewhere (the cinema) but if you want, I'll expand on this point later on.

[stigmata]

You have still to prove anything.  All that you've done is to quote another persons ( completely innacurate) articles, and without actually giving any solid figures on what each test-case was doing apart from a timing in seconds.

Okay, to recap.

You suggested that Intel makes nothing but crap, along with the admission (implied or explicity) that you know next to nothing about Dothan, Yonah, the Celeron or the Xeon.

From that point, you "proved" your point with evidence from your own hand, without any sort of reproducable test at all. On the basis that one highly-restricted thoery of performance is all that you need in order to argue one processor's speed over another's, you gave us reams of meaningless code in what you apparently believe to be "evidence".

Now, back to the reproducable test bit: In response, I provided a huge number of reference to repeatable, verified and accurate performance benchmarks on several websites that make a good deal of their business from assessing the performance of new hardware in an equitable manner. If you like, you could find identical results on a dozen different websites, along with a complete description on the way in which those scores were gathered (I mean, how can you possibly argue that "frames per second" is an ambiguous benchmark?). Further, and with those as evidence, I discounted your "evidence" with reference to the actual performance of that hardware.

So, you've failed to prove your own point, and then failed to even reply intelligently to the counter-arguments I put forward. For reference, a "framerate" is a standard measure of graphics performance, measured in the number of fully-rendered frames processed by the relevant graphics hardware per second, independent of monitor refresh rate.

Intel CPU's are nothing but badly-designed CPU'S which have only ever been "improved" with band-aid sollutions at the cost of ever dimishing returns.

You mean,  like, the introduction of extreme power-efficiency in the Dothan line, along with improved branch prediction, SSE,SSE2 and (from Yonah onwards) SSE3 support, SpeedStep, and a larger cache. "Bandaid solutions" all, apparently.

I think the "what the hell are you talking about" is entirely justified because this is a post full of misconceptions

Thanks for the backing-up. =)

[Keizuki]

Maybe we should change this thread' title to "All about Intel' CPU's" ...?

[imyourhuckleberry]

Maybe we should change this thread' title to "All about Intel' CPU's" ...?

or the Applegeeks version of "The Young and the Resteless"

[rusty]

** edited out **

Geez...can't we all just get along?  

I look at it this way....if three of my coders were to go ahead and spend 5 months optimizing something to only get a 3% gain in performance I'd fire them.

But not before I handed in my resignation for being so incompentent as to let that happen in the first place.