oooo! prescott!

[xxsk8er101xx]

" Mega Hertz... what Mega Hertz ?

The 90 nm Prescott is expected to reach speeds of 4 GHz and beyond. The Integer Execution Units however runs at 8 GHz, so does the integer register file, the address generators and now, as we may presume, also the L1 data cache. So why call it a 4 GHz processor? Technically spoken it is not a 4 GHz processor but an 8 GHz processor..."

<A HREF="http://www.chip-architect.com/news/2002_04_16_Prescott_Prospects.html" target="_new">http://www.chip-architect.com/news/2002_04_16_Prescott_Prospects.html</A>

AND

"8GHz speeds possible

By Mike Magee: Thursday 18 April 2002, 09:39


A REPORT BY Hans de Vries at Chip Architect looks at an up and coming chip conference and examines what Prescott may hold in store for us all.
Including the alleged "Yamhill" 64-bit extensions that use X86-64.

He says that Intel has as many as 18 presentations on the Pentium 4 architecture at the VLSI 2002 symposium in June, and summarises the ones that interest him the most.

He compares a 130 nanometer (.13 micron) process to Prescott's 90 nanometer (.09) micron, and also talks about the rumoured Yamhill X86-64 INTC clone, which he reckons will not be too hard for Intel to implement.

He also thinks that the JEDEC DDR II standard is particularly poor, compared to the speed of future caches in X86 processors.

He reckons that a 90 nano Prescott will compete successfully with a 90 nano Sledgehammer chip.

You can find all this and more here <A HREF="http://www.chip-architect.com/news/2002_04_16_Prescott_Prospects" target="_new">http://www.chip-architect.com/news/2002_04_16_Prescott_Prospects</A> <same as above>"
<A HREF="http://www.theinquirer.net/?article=3288" target="_new">http://www.theinquirer.net/?article=3288</A>

i don't trust the inquirer as much as anyone but it was there. the chip arctect site is cool though.

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[Quetzacoatl]

Well, you imagine the Pentium 4 on steriods, and you get an idea of what we're looking at.

A REPORT BY Hans de Vries at Chip Architect looks at an up and coming chip conference and examines what Prescott may hold in store for us all.
Including the alleged "Yamhill" 64-bit extensions that use X86-64.


He compares a 130 nanometer (.13 micron) process to Prescott's 90 nanometer (.09) micron, and also talks about the rumoured Yamhill X86-64 INTC clone, which he reckons will not be too hard for Intel to implement

And I thought Intel was pushing for <i> Yamhill IA-64.</i> I could be wrong...

Sorry, I meant to say Yamhill support and IA-64, separately



"When there's a will, there's a way."<P ID="edit"><FONT SIZE=-1><EM>Edited by Quetzacoatl on 07/08/02 09:36 PM.</EM></FONT></P>

 

[xxsk8er101xx]

yamhill i don't even think intel announced. I think it's just the computer industry telling intel to support the x86-64 architecture. *shrugs*

but man with or without yahhill .. man does the prescott look like a speedy little devil or what? Decent marketing too. Claim the "8ghz" cpu as 4ghz.

An 8ghz cpu would surely out doo the hammer at 2ghz.



<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[Quetzacoatl]

Well yes, I understand. But you know Intel nowadays, they have to put in good support, or they get stabbed by AMD. I personally think they'll give in and support x86-64 or mod their design. Good paper release so far, sounds like a good hit for them as long as they follow through. I still have my doubts though for their first yields, being either .13 or .09. I highly doubt the initial release will be .09 unless Intel has been doing enough research on it, their .13 process is already mature enough, it's still got some life in it though by the looks of the northwood. And yes, 8Ghz PC (Prescott) would easily stomp a 2Ghz Hammer

"When there's a will, there's a way."

 

[LED]

Prescott will be manu. solely in the .09 process.....Was designed that way.

I sold my sig for $50.

 

[juin]

That a old storie.

read well at the end of the article

cheap, cheap. Think cheap, and you'll always be cheap.AMD version of semi conducteur industrie

 

[Quetzacoatl]

I know what they were planning for, I just doubt they will follow through with their paper release of the .09 process. The original yields for .13 were delayed, and eventually though, but Intel did deliver with the Northwood. I just doubt somewhere in myself taht .09 will deliver on time.

"When there's a will, there's a way."

 

[xxsk8er101xx]

it's news to me?

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[xxsk8er101xx]

Cool! I wonder if it's 478 pin compatible?

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[xxsk8er101xx]

thats a possiblity.

In the computer biz unexpected issues happen all the time.


if intel does make it on time i think that would be amazing. If not, i think that would be normal.

I mean for all you know Intel probably already has .09 process and samples of prescott.

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[juin]

0.09 SRAM as been show 4 monyh ago.

cheap, cheap. Think cheap, and you'll always be cheap.AMD version of semi conducteur industrie

 

[juin]

Cool! I wonder if it's 478 pin compatible

Not sure but i think yes

cheap, cheap. Think cheap, and you'll always be cheap.AMD version of semi conducteur industrie

 

[slvr_phoenix]

The 90 nm Prescott is expected to reach speeds of 4 GHz and beyond. The Integer Execution Units however runs at 8 GHz, so does the integer register file, the address generators and now, as we may presume, also the L1 data cache. So why call it a 4 GHz processor? Technically spoken it is not a 4 GHz processor but an 8 GHz processor..."

Yeesh. Appearantly the demons of stupidity are out to play. Hello people! Remember the simple fact that even the Willamette's core had double-pumped simple (16-bit) ALUs. This is nothing new here. If the Willamette runs at 2GHz and the simple ALU is double-pumped, then that ALU is running at 4GHz. This however does <i>not</i> mean that the whole CPU can run twice as fast.

It just means that <b>if</b> the <i>simple</i> ALU can be fed quickly enough, it can perform twice as many calculations. The simple ALU however does not a processor make. Besides completely neglecting FPU, it also doesn't perform complex ALU instructions. For that, the P4 had a seperate, and much slower, complex (32-bit) ALU unit.

Prescott will hardly be any different. Oh sure, <b>if</b> Prescott were to have double-pumped <b>complex</b> ALUs it <i>might</i> make some difference, especially in older code which uses a lot of bit shifting. (Since the old P3 and earlier cores performed bit shifting extremely quickly, this was an ugly code optimization method used to get around slower instructions. The P4 however performs bit shifts very poorly, so all code optimized by bitshifting runs horrible on a P4.)

However, double-pumped simple ALUs are nothing new to the P4 architecture. Therefore, even a double-pumped complex ALU will offer only a minimal performance improvement for the most frequently used consumer applications. The move though to the use of multiple double-pumped complex ALUs (or even better, the return of seperate high-speed bit shifters) instead of a single slow complex ALU and several quick simple ALUs would mark a huge turning point for the P4's ALU execution prowess.

What would truely improve performance of the P4 core though would not be an ALU improvement, but an <b>FPU</b> advancement. The core <i>should</i> have at least two FPU execution units, both capable of full SSE2 instruction execution if Intel is serious about improving the P4s performance.

However, doing so would show another weakness in the P4's architecture, which is its crappy logic unit feeding limitations. If Intel were to really push the P4's performance by allowing the FPUs and/or ALUs to perform more calculations per cycle, then the core would also have to be improved to actually feed these units more commands per cycle, which the current design lacks. Double-pumped units do absolutely no good if you're only feeding your execution units a minimal number of commands per clock.

If we are lucky, Prescott <i>might</i> see such light. Then again, such power just might put the Prescott's performance significantly above anything that AMD will offer, so Intel probably won't risk it.

To re-iterate my main point though, put the hype-monkeys to sleep before they do any more damage. The P4 already has simple double-pumped ALUs, which by definition run at twice the core clock speed. This: 1) Doesn't make the chip twice as fast. 2) Means that even a double-pumped complex ALU won't improve performance <i>that</i> much for P4-optimized applications.

We've already hyped the poor Opteron to points of sheer stupidity. Must we do the same to Prescott?


Tech support said take a screen shot.
Putting it down with my .22 was the humane thing to do.

 

[Quetzacoatl]

Lol *clapping* completely forgot the Pentium 4 had double pumped ALU's, my bad. Still, it's a pentium 4, and we'll have to hope to god they improve the memory bus somehow. Ick, the Willy with doublt pumped ALU's...and it STILL sucked...I hope the Prescott is a step beyond Northwood, otherwise they're giving the Hammer a chance to step back up to plate. And *shudders* on die memory controller...should be quite an expensive Pentium 4 if you ask me.

"When there's a will, there's a way."

 

[xxsk8er101xx]

apparantly you didn't read the article or you didn't understand it at all.

The advancements that will be in Intel Prescott is shown in chip-architect.com. It is hardware: doubling ALU to 32-bits from 16, having 32KB, 16KB L1 cache(whether one is trace cache, data cache, or instruction cache) up from 8KB instruction and 12KB micro-ops trace cache, L1 cache running at double the speed of the Prescott's core, AGU also at double the core speed, the integer register file increased from 128 words to 256 words and also runs double the clock speed, Hyperthreading Technology that is enhanced from the previous Pentium 4 core, 800MHz quad-pumped bus and Dual-channel PC3200 to accompany the bus. I think with that improvement the performance for the Prescott will be very good. Prescott is expected to run at 4GHz at introduction, and the die size at 90nm is only 80mm2. And it features around 90-110 million transistors. With that many transistors it will probably have FPU at double the speed. AND we all know the ALU is double the speed. That is basicly the entire processor!

It's not just the ALU! Since you called me stupid i'm calling you a dumbass cos you have no concept of what a CPU is.

Do you understand now?

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[xxsk8er101xx]

let me feed you some more concepts so you understand that what you know about cpu's isn't everything you know. There is a LOT more then just an ALU on the processor!

"Prescott's Redesign
Prescott will be Intel's next process revision at 90 nm, but it will be more than that. Its die will be physically smaller than the existing Pentium 4, but it will also incorporate a host of new capabilities. The majority of those new capabilities will extend SSE2 into even greater areas of computing (I'll call them SSE3 for lack of a better name). Additionally, some of its new capabilities will relate to Intel's HyperThreading architecture and ways of providing support for it (I'll call it HT2, with HT being the one currently employed on Xeons).

If the direction Intel has taken with the move from MMX to SSE to SSE2 is any indicator, a pattern begins to emerge. MMX added new capabilities without requiring any changes whatsoever from the operating system. All existing code would work without modification, period. (AMD and) Intel did this by utilizing the same logical register space the FPU used. (Registers are the internal memory storage areas used by the CPU when it processes data--no actual computing takes place outside of the CPU. The CPU must bring all the data required to process something inside of itself to be processed. Once processed it can either be stored in registers or written back to memory). MMX added new logical registers which were "aliased" onto the existing FPU registers, meaning the same physical register space could be identified by two names or aliases, that of "STx" (ST0, ST1, ST2 ... ST7) for when they were being referred to by the FPU commands, and that of "MMx" (MM0, MM1, MM2 ... MM7) when they were being referred to by the new MMX commands."

It's all here:
http://www.geek.com/procspec/features/sse3/index.htm

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[xxsk8er101xx]

Here's a hint the cpu contains more then just the ALU. Such as the execution unit the address generator unit (AGU) the integer file unit .. the FPU could also possibly be double pumped. It has twice the cache! It will also have SSE3 (for lack of a better name).

http://www.geek.com/procspec/features/sse3/index.htm

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[Quetzacoatl]

The ALU's have a serious penalty for their latency however, and they often end up being slower than a single ALU, as in the Athlon. Doesn't matter if it has SSE3, it needs to be first integrated by software programmers, as with the move from SSE to SSE2. By then, AMD will have full SSE2 support with the Hammer series, putting them back on par in software support. Extra cache however, I will agree will significantly help the Prescott, although it will also increase the costs a great deal as well.

"When there's a will, there's a way."

 

[xxsk8er101xx]

*shakes head*

Never coded before i take it then huh?

That takes zero effort. infact it makes the code smaller because you don't have to do extra steps in case of switching bits from 16 to 32 or 32 to 64. takes no effort. Instead of splitting 2 instructions into 16bit registers you load the whole thing in the 32bit register. Not hard at all. It also takes no effort to recompile the code too. Adding instructions takes about 20% effort. Adding cache doesn't double the price of the cpu. it's only an extra 8KB! If the prescott is doubled from 512K of L1 to 1MB then it might add 20 bucks, maybe 40 because it's twice the speed and thats extreme.

The cost is mostly with the research not the parts.

I guantee the hammer chip will be about as expensive as the P4 prescott because AMD has to make money too and they are spending millions on this hammer architecture which they have to make up somehow! Research is NOT cheap!

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[slvr_phoenix]

xxsk8er101xx, I already know that you're a complete flipping moron, you don't have to keep proving it. Really. We all figured that out long ago, so you can stop making such an effort to look like both an idiot and an arse.

Because you obviously have difficulty comprehending the purpose of quoting statements, let me enlighten you. People quote statements in order to provide replies and/or counterpoints specifically related to the material that was quoted.

So, when I quoted "Technically spoken it is not a 4 GHz processor but an 8 GHz processor" before me response, it meant that my reply was aimed specifically at that particular innane piece of dribble you call information.

Since the ALU was the <b>only</b> component to be double-pumped, my entire point was that the chip will <b>not</b> perform at 8GHz levels, which is completely contrary to your ludicrous innacuracies.

Further, as you seem to have absolutely no comprehension of what goes into a CPU and how it works, doubling the cahce does <b>not</b> make it run twice as fast. It just allows it to hold twice as much. So a 16KB L1 cache does <b>not</b> run twice as fast as an 8KB L1 cache.

Now, to completely point out your ignorance, <b>if</b> Intel were to officially support Yamhill, this would mean that in Yamhill's 64-bit operation, all standard integers and floats would now be twice as large as they were in Northwood's 32-bit. Imagine that! This means that <b>all</b> standard objects would require <b>twice</b> as much memory to store. Hmm... What do <i>you</i> think would be required then for the CPU to operate at the same efficiency?

No, I'm sorry, it wouldn't be required that the CPU run twice as fast.

The <b>correct</b> answer is that <b>all</b> storage units and <b>all</b> execution units would need to be twice as large so that they could store and process data that is twice as large without suffering a severe penalty.

Now, think back to that article. The L1 cache is twice as large. The L2 cache is twice as large. The simple ALUs are increased from 16-bit to 32-bit. The complex ALU is inrceased from 32-bit to 64-bit. Why, I'll bet that even the FPU doubles its bits as well. And low and behold, a new extension is needed for SSE2. Why? Because all of this <b>has</b> to be extended if Prescott is going to support the new larger integers and floats inherant to x86-64.

<b>EVERYTHING</b> stated in precious articles is a <b>requirement</b> if Intel does indeed support Yamhill. Will this magically double your CPU's speed? Not bloody likely. All it will allow is x86-64 operation. Whoopie!

At absolute best, if designed properly, it <i>will</i> improve 32-bit performance. However, as I have already stated, unless Intel actually designs the CPU to feed the logic units properly for these extensions, then the CPU will run <b>no</b> faster despite all of those extensions.

xxsk8er101xx, go buy a clue from eBay. Even a used and water damaged clue is better than what you have.

You see, the difference between your posts and mine are that my posts actually show knowledge of how a CPU works without the need to quote other authors, where as all you can do is quote other authors. (Authors who obviously themselves have little to no clue on how a CPU works to have written such innacuracies.)

So xxsk8er101xx, go run along now and play with the other little boys and girls. Processors are obviously over your head. Why not try something simpler, like an Etch-A-Sketch?

<font color=red>Flame not, lest ye be flamed!</font color=red>

 

[slvr_phoenix]

Never coded before i take it then huh?

By looking at your post, you obviously never have.

That takes zero effort.

Must be a nice fantasy world you live in. I bet in your world, MS products have zero bugs too, huh?

infact it makes the code smaller because you don't have to do extra steps in case of switching bits from 16 to 32 or 32 to 64. takes no effort. Instead of splitting 2 instructions into 16bit registers you load the whole thing in the 32bit register.

Assuming that in 32-bit operation you actually have access to the new and improved registers provided by x86-64, which you <b>won't</b> since they're x86-64 extensions and <b>not</b> native to 32-bit processors. Otherwise, your code will be entirely x86-64/Yamhill dependant, which will prevent it from running on any P4, P3, P2, P1, 32-bit Athlon, K6, K5, C3, etcetera, etcetera, ad nausium.

It also takes no effort to recompile the code too.

Uh huh. Why? Since unless you're re-writing the code to work explicitely in 64-bits, there is no code change!

<b>However</b>, if you <i>do</i> re-write the code to work explicitely in 64-bits, then you have to go through each and every instance of a workaround where your code broke down the variables to play nicely in a 32-bit CPU. In a high-order language (Such as C++) this should require minimal changes. In a very-high-order language (such as Python) it probably wouldn't require any changes. In a low level language though (such as Assembly) you might as well just throw your self head-first down a flight of stairs because that'll be a lot less painful than converting the code and while you're in the hospital on workman's comp, someone else will be stuck with the task of converting the code.


Tech support said take a screen shot.
Putting it down with my .22 was the humane thing to do.

 

[imgod2u]

Since the ALU was the only component to be double-pumped, my entire point was that the chip will not perform at 8GHz levels, which is completely contrary to your ludicrous innacuracies.

The ALU will not be the only component in Prescott to be double-pumped. Both the AGU and the L1 cache (and probably the trace cache as well) will be double-pumped. He was pointing this out. Also, if I remember correctly, the standard for what counts as 1 "hz" in a CPU is how fast the ALU unit can run. A CPU can be said to be divided into as many stages as possible and each stage count as 1 clock, however, the ALU unit must be at most 1 clock. In the case of the P4, 1 pass in the ALU is only 1/2 a clock.

Now, think back to that article. The L1 cache is twice as large. The L2 cache is twice as large. The simple ALUs are increased from 16-bit to 32-bit. The complex ALU is inrceased from 32-bit to 64-bit. Why, I'll bet that even the FPU doubles its bits as well. And low and behold, a new extension is needed for SSE2. Why? Because all of this has to be extended if Prescott is going to support the new larger integers and floats inherant to x86-64.

x86-64 brings about no specifications for a new FP data type. It only extends the general purpose registers (which can handle either FP or integer data) to 64-bit so that the CPU can handle 64-bit integers.

And btw, in your post, you specifically pointed out that "the P4 already has double-pumped 16-bit ALU's" and that what is in Prescott is nothing new. He pointed out that that statement was BS since Prescott's ALU units were double-pumped 32-bit ALU's. Whether those ALU's can be tied together to perform a 64-bit operation (like the ALU's in the P4 are to perform a 32-bit operation) is anyone's guess.

Yeesh. Appearantly the demons of stupidity are out to play. Hello people! Remember the simple fact that even the Willamette's core had double-pumped simple (16-bit) ALUs. This is nothing new here. If the Willamette runs at 2GHz and the simple ALU is double-pumped, then that ALU is running at 4GHz. This however does not mean that the whole CPU can run twice as fast.

Nobody mentioned twice as fast. Not in the article and not in the post. Clockspeed is clockspeed, not performance and it said "technically" it is an 8 GHz processor. And technically, it is. Does that mean it will run twice as FAST as a 4 GHz P4? Of course not, but nobody said it would. Technically, a 1.6 GHz P4 is actually 3.2 GHz. However, Intel chose not to count each pass of their ALU as 1 clock (which, by all standards, they could). A single clock of a CPU can be as small as 1 pass through the ALU, that's the definition. Everything else can take multiple clocks for 1 pass.<P ID="edit"><FONT SIZE=-1><EM>Edited by imgod2u on 07/09/02 10:15 AM.</EM></FONT></P>

 

[xxsk8er101xx]

ohhh ok sooo you're right .. the ONLY component on the CPU is the ALU .. ok ... Who cares about the execution unit or the cache or the lookup table or the AGU or FPU or hyperthreading or the extended architecture of SSE2 (sse3) or every other component in the cpu running twice that of core clock. use your brain!

int core_clock = 4000; \\speed in mhz

if((core_clock == 4000) && (everyother_component == 8000)){
printf("Thats basicly a 8000mhz cpu you moron!\n");
printf("Have a good day! \n");
Printf("\t\tPress any key to continue");

while(!kbhit()){;}
}

and good job calling me names because that only shows me how immature you are. which proves to me you know jack about the units that make up the CPU. Considering you think the CPU is just the ALU.

And by the sounds of your frustration also shows me you understood nothing i quoted to you and what i've said.
clearly you don't seem to understand there is more then just the ALU but i'll leave that to your own little dream world where you know everything.

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[xxsk8er101xx]

riiiight .... you got some serious anger management issues.

good day

<A HREF="http://www.anandtech.com/mysystemrig.html?id=9933" target="_new"> My Rig </A>

 

[Matisaro]

It's not just the ALU! Since you called me stupid i'm calling you a dumbass cos you have no concept of what a CPU is.

Do you understand now?

Skater you will lose this one, badly, I suggest you surrender now.

The Cash Left In My Pocket,The BEST Benchmark