Thread: Weird Performance

aliens

That's one option, but it probably won't help you in the graphics case.

Also, a Core 1 1.6GHz CPU should be able to keep up with a P4 2.6Ghz. Perhaps your compiler is tuned to the P4 and generates code that is considerably more efficient there.

But you'd need detailed profiling to find out.

A Core1 doesn't have 64-bit mode. It's not what I meant, anyway. I'm saying the compiler is tuned to the P4. That means that the way it generates instructions is optimized for the P4's endless instruction pipe, instead of the Core's far shorter one.

Originally Posted by CornedBee

A Core1 doesn't have 64-bit mode. It's not what I meant, anyway. I'm saying the compiler is tuned to the P4. That means that the way it generates instructions is optimized for the P4's endless instruction pipe, instead of the Core's far shorter one.

Somehow I find this rather unlikely. In my experience, code written for long pipelines will run well on short pipeline processors (e.g. Athlon-64 vs. P4 using the same code), but the other way around isn't always true.

--
Mats

*shrug* Just a suggestion.

Anyway, what you really should do is profile the program and find out if the performance difference comes from a general slowdown or if there is a specific bit of code that is so much slower.

That is, indeed, a good suggestion. May I suggest a trial version of VTune. (Or use oprofile if it's Linux).

By the way, a built-in graphcis card with small amount of memory may actually be faster than one with large amounts of memory when it comes to WRITING the display-list in OpenGL, so if you are spending a lot of time writing the display-list, and the drawing of the object is trivial (so much that the basic Intel graphics card isn't "pushed" to it's limits), then the basic model graphics card may have a big advantage.

--
Mats

Originally Posted by matsp

Somehow I find this rather unlikely. In my experience, code written for long pipelines will run well on short pipeline processors (e.g. Athlon-64 vs. P4 using the same code), but the other way around isn't always true.

--
Mats

actually you have that backwards. The longer a pipeline (assuming its an efficiently implemented one) the more effecive it is at minimizing small innefficiencies in the instruction stream. Shorter pipelines are statistically less likely to catch every possible chance to perform OOE. They had to shorten the pipelines in the core2 because of going multicore, where pipeline refills due to failed branch prediction have a larger impact on cache performance. Its a trade-off that wont always benefit every program.

When you start measuring AMD vs Intel, all bets are off, because they implement their ALU's in completely different ways. They both execute similar instruction sets, but internally they are like apples and oranges.

8 cores is going to be the limit as far as multicore, since that is the point at which one or more cores will almost always be stalled due to a cache miss. The only way to improve performance at that point will be to start using more advanced memory architectures.

Originally Posted by abachler

actually you have that backwards. The longer a pipeline (assuming its an efficiently implemented one) the more effecive it is at minimizing small innefficiencies in the instruction stream. Shorter pipelines are statistically less likely to catch every possible chance to perform OOE. They had to shorten the pipelines in the core2 because of going multicore, where pipeline refills due to failed branch prediction have a larger impact on cache performance. Its a trade-off that wont always benefit every program.

When you start measuring AMD vs Intel, all bets are off, because they implement their ALU's in completely different ways. They both execute similar instruction sets, but internally they are like apples and oranges.

A long pipeline has nothing to do with OOE (Out Of Order execution). That is all about having a large number of potential instructions to choose from "ready to execute". But once an instruction is actually in the pipeline, it has to either be skipped or executed. A longer pipeline doesn't make that any better.

The length of the pipeline determines [indirectly] how fast you can clock the processor. By increasing the length of the pipeline, the amount of work done in each pipeline step is less, which means that the time it takes to pass a certain pipeline stage is shorter, meaning that the clock-cycles can be shorter without causing problems with the timing of each pipeline stage.

I still would say that a long pipeline is not as good as a short pipeline, unless the code is specifically written to fit in long pipeline [no unpredictable branches, long sequences of instructions with no branches, that sort of thing]. And even then, a short pipeline will not show any drawback in itself - it may not clock as high, but with correct design, this can be overcome by more work per cycle, as proven by both AMD and more recent Intel processors.

--
Mats