Slashdot Mirror
Merced Design Completed
NoWhere Man writes "Merced's design
is complete and are due to go into production mid-2000, but it is expected that McKinley, Merced's successor (due late 2000), will likely be the most popular in Intel's 64-bit chips.
"
← Back to Stories (view on slashdot.org)
Is Merced destined to become a consumer chip, or just the high end like Xeon?
mid-2000? phff, by then the new Alpha 21364 processor is ready to kick its ass
Wow, that will make a nice gaming machine. I wonder how soon it'll be before we get photorealistic FPS.
eh, but mid-2000 I'd bet Athlon's would whoop on Merced...much less the Elbrus E2K and Alpha 21364 stuff.
They are talking about Athlon's @ 1GHz by year end (wanna guess 1200~1400MHz by mid year) and the Merced is @ 800MHz? IA64 may be better (wait and see) but it'll be hard to overcome that much of a MHz diff.
Not even worth mentioning how much fatser the Alphas are---nothing's even close.
750MHz by the end of this year, all RISC (w/ a vector processing unit) & 2MB of L2 cache. Run linux, bsd, or macos. When does the P4 come out?
-Potatoswatter
The egcs compilers are not the fastest, but they keep up quite well overall. egcs will compile Merced code. More importantly, you can use egcs on all platforms, while most commercial compilers only work on 1 OS or 1 CPU.
a 64 bit architecture has long been neccesary for servers etc, but on a home computer, won't it just lard up the processor? And if this isn't a home computer processor, what's the big deal - that it's just been delayed so long?
Take a look at the PowerPC G4 - there's something new. It's even RISC!
Don't forget, Intel gave in to Microsoft once already by delaying Merced for 6 months. I don't know how willing they would be to do that again.
I think you're referring to the highly touted release of the "G4" processor with Motorola's Altivec unit.. However, the G4 is not a 64 bit chip and therefore isn't all that relevent to this discussion..
If you're compelled to talk trash and want a 64 bit processor to hold up and shout about.. Try the one of the "Power" series (I believe IBM is currently up to the Power3).
Some time ago, HP's engineers figured that Merced was gonna be a dog. So they started designing a new 'EPIC' chip based on the common spec. Intel got wind of this and sent some engineers over to take a look. McKinley was born.
///, and Xeon.
Intel needs ONE good new chip to take them into the next century, and the McKinley will be it. Look how long they've milked the P6 core: Pentium Pro, Pentium II, Celeron, Pentium
If McKinley performs like the next generation of PA-RISC should, then unfortunately Alpha DOES have a lot to worry about. I don't think Alpha will disappear, but it will actually have to extend its performance lead by a very wide margin before choosing Alpha becomes a no-brainer.
ARM machine code??
My, what foresight you have!
Not really. Remember that 16 --> 32 -> 64 is not a mere doubling. It's an exponential leap in many regards. Trying to apply hindsight here is like claiming that hindsight needs to be applied so that we can start (right away, now!) working on the Y10K problem. After all, we trivialised the Year 2000 problem for a long time. Why make the same mistake with the Year 10000 problem?
How much of the time is your present hardware not fast enough for what you want to do with it? I myself am guilty of not asking that often enough, so now I have a K6-2, a Pentium-233, and a Pentium-166 all sitting in the office. They all work fine (and lotsa hardware is nice for people like myself who retch at the thought of dual-boot systems) but I have some credit card debt now I could do without. The urge right now is to start anticipating the purchase of a K7 box later this summer when they're available. But the stuff I have now gets almost everything done that I need, and most of what I want.
I'm not an expert, but the "first born child" thing is a good point. I'm sick of paying through the nose for sparc cpus that are costing more than my desktop. I mean jeez, they're not turning anywhere near the performance for that price.
If DEC hadn't screwed up, we'd have 1 GHz alphas by now and my desktop could run a data warehouse as fast as my E10k (a little exageration).
Hey people, Intel is no longer the Borg of the CPUs. They help Linux now. And Linux is portable as hell. So, you aren't locked to them unless you use closed-source programs.
If things get nasty in the x86-based side, we will go to Alphas. No need for discussion anymore.
...would be to fix the bug and supply a patch, or to bring the problem to the attention of the person who is maintaining the code.
...is that optimized binaries for the new CISC/RISK/EPIC instruction set will be 3x (yes, 3x!!!) times larger than they are for x86 alone. Thank God those new 20GB drives are becoming so cheap nowadays...
I was told in the neighborhood of $9K for a reasonably tricked out machine (RAM,HD).
This is expensive for a desktop but not for workstation which is cranking out performance like this (Based on HP's estimates).
Last time I checked a 21264 on a good machine was ~6->7 thousand.
And (for the other AC reply) a desktop machine is not in this class.
I find the performance exciting considering that HP/Intel designed the Merced.
Isn't Puffin or somebody working on bringin linux to HPPA?
I have found bugs in commercial compilers,
including the most popular one. GCC has no more
bugs than the average commercial compiler. If you
think that a colorfull shrink-wrap box makes a
compiler better you've got some learning to do.
actualy, I think the k7 has 512k or 256k of l2 cache, but what's *really* cool is that it has 128k of L1 cache... that's a lot :P (piii has 32k)
Actually, I believe tape-out referred to using tape to make a much larger version of the mask, which would then be photo-reduced.
what? the PPro is a true 32 bit chip, as is th 386....
the PPro was slow running 16bit code (and therefor windows95(!?!?))
However, the G4 is not a 64 bit chip
Errnt. It IS a 64bit chip. So is the 750 (G3). Only problem is, Apple uses 32 bit 750's. Don't know how it works, but there were 64 bit 750s. No one's really sure if Apple will use 64 bit G4s, but since they have a 64bit clean OS now, I suspect they will. Seeing as Apple is the main buyer of PowerPC chips (which are just low cost POWER chips), they can affect the product line. besides, what's the A in AIM for, anyways?
You're are correct, "tape-out" != "done", however, HP has booted and ran HP-UX on it's IA-64 simulator.
1997 CGDC:
"Realtime photorealizm will not be achieved for another 50 years."
I once heard a RUMOR that Apple owned 80% of the patents that allowed you to effectively run FAT Binaries so they could transition from one CPU to other, and I heard in the same rumor that NeXT had approx the other 20%, so that for Microsoft to do it they would actually have to invent a new way, any way thats just what I heard.
not quite yet, there are hundreds of millions of legacy units running x86 code. but I think the writing is on the wall for the x86 architecture. Intel is trying to dump it, and the open-source movement is making cross-processor compatibility less important.
That's where I think Intel is headed. The only weak point of the StrongARM is its floating point unit. However, Intel can definitely improve that; anyway, for the typical consumer floating point isn't important except for 3D games. And there are much better solutions to 3D acceleration than floating point.
16 to 32 was definitely necessary to get true 32-bit addressing. You definitely do not want 16-bit addressing on modern applications.
32 to 64? Um, gee I dunno, do consumers need more than 4GB of addressable RAM? There's not a compelling case for that right now, that's for sure.
Well for a factor 2, and on expensive machines, some people are willing to sacrifice portability for speed.
if you think that the magic pixie dust of open source will make gcc's problems dissappear. I've used both gcc and MSVC for big projects, and although I was initially _far_ biased towards gcc, because it didn't produce as bloated code and was command line based and thus more flexible, in the long run, MSVC never, ever, miscompiled code, while gcc did with alarming regularity. MSVC code was often faster as well on i386s, although it was specifically optimized for this while gcc was not.
No. The response was to "fix it yourself" or to bring the problem to the attention of the person who is maintaining the code.
Broken, sad, shit. Linux, apache- these are the exceptions, not the norm. I'm sure this will be downgraded to flaimbait.
Well the "broken piece of shit" is able to compile Linux and apache, along with, say the 2 GB of the Debian distribution, etc.
My guess is that you are probably using new code such as C++ novelties (templates, RTTI, exceptions, ...), doing something not ANSI-C, or something unfrequent ; otherwise if you report this bug to the gcc maintainers they will treat it of course very seriously.
For your information, I've never met a bug with gcc for C programs, often with gcc 2.7.x with C++, rarely with egcs and C++.
Linux, apache- these are the exceptions, not the norm.
No they aren't. It's compiler development which is an exception. It is difficult. That's why there is only one free 'C' compiler (lcc is only free for 'personnal and instructionnal use'), and even the *BSDites, some of whose prefer to use BSD-licensed software, have to use this GPLed one. Compiler development is tedious, it requires handling hundreds of cases in hundreds of contexts and does not lend itself to individual hacking (either you know everything at the front-end/back-end of gcc, or you can't modify it at all ; contrast with Linux: to add a driver you just need to understand a handful of APIs).
Plus if you are using "C++", you are using a spectacular language design failure (ill-specified language, many exceptions, inconsistencies, bloat, ...), which complicates incredibly gcc developers' job.
I'm off to the commerical UNIX world, to get some real work done.
Or you can buy commercial C++ compilers for Linux. Commercial compilers have bugs to ; commercial C++ compiler have probably less bugs, but if you find one, it might be more difficult to trace or get fixed.
Yeah,
I have a 26 cpu Sun E6000 system with
Memory: 22G real, 931M free, 8127M swap in use, 12G swap free
All 400 Mhz UII's. And more disk space than you
can shake a stick at.
And it doens't run linux... (yeah!)
You've gotta admit, Apple did do a great job with their 68k->PPC conversion once you look back at what they did. I wouldn't quite call the transition seamless though. I must say that it was quite painful running MacOS 7.5 -> 7.5.3.6.5.1.3 beta 4 professional edition supreme prerelease service pack 2.4a4 as they were not the nicest versions of their OS. I believe this was due to the CPU migration and probably one of the causes of their near bankruptcy.
I guess my point is that if the designers of such a great OS had troubles with this CPU switch I wonder how poorly some 'other' company will handle their inferior OS.
I'm waiting the release of this new processor to watch some 'other' company mess up and lose some... MWA HA HA HA!!! Get the damn 32-bit OS working before you try 64...
HY
Yes, Win2k will implement Win64, but Win2k for IA-64 likely won't be released immediately when Merced is released.
On the other hand, Linux/IA64 isn't ready yet, either, but it'll likely beat win2k to market.
Yes and no. IA-64 does not *replace* IA-32. Intel will continue to produce new IA-32 chips for the desktop and IA-64 for high-end server use. Further, IA-64 chips will still run IA-32 code as well as native code. Intel also plans to release the P7 (the first new IA-32 chip generation since the P6-class Pentium Pro was introduced) sometime next year (the chip code name is Willamette).
>I don't know what you are all talking about the Alpha chip for. If you mean the really fast one, that Digital designed... It doesn't exist anymore. Digital is dead. It was bought by Intel and Compaq. That is what I do.
:)
Alpha certainly DOES exist, it is now owned by Compaq, and Compaq only. Intel had nothing to do with the Compaq/DEC deal.
>Intel got the StrongARM chip from Digital.
Uh... No. ARM licensed their chip design to Intel, like they do to any company who is willing to pay for it. That's how ARM operates. ARM doesn't manufacture the StrongARM, they design and license it(among other stuff) to semiconductor companies.
>expect to be able to surf the web on your tv pretty soon.
Pretty soon? Ever heard of WebTV?
>Check it out on ARMs homepage.
I did. I would suggest you do the same
Uh... IA-64 uses an architecture called EPIC, which has more in common with VLIW than RISC.
If Intel ships Merced when it says it will, and the chip performs according to spec, then intel will likely have a respectable CPU for servers and other high-end systems. But the problem that Intel faces is that it is trying to move into a new market where you already have companies with equally respectable CPUs. Even if Merced is great, it doesn't mean that anyone who already owns a Sun or an Alpha is going to throw all that away to run out and buy one, especially if the primary OS for it is some version of NT. Merced doesn't mean squat for people running a middle of the road PC. There is always something faster than your desktop PC around if you're willing to spend the money. The fact that intel now has something to base a system like that off of, doesn't mean that any reasonable person is going to run out and buy one to replace their PII/III or K7. The compiler needed to actually make a VLIW design work is another problem. The compiler for the merced will take far more work to design, and be an order of magnitude more complicated, than the chip itself. I know that cygnus is working with intel to create a native compiler, but I have not heard anything about how they are coming with it. They have to be done before intel begins shipping sample chips to vendors, which is supposed to happen by the end of the year. My guess is that they aren't going to be ready with the compiler, meaning that in the beginning merced will be running x86 code for which it offers no performance improvement. So what you have is a processor which you can't create native code for, is extremely expensive, and won't run legacy applications any better than the hardware you currently own. Merced is a desperate marketing move on intels part rather than a try at a successful product. McKinley might pan out, but merced is simply a latter day 80186.
win2k will run in some kind of 32 bit emulation mode, but even if it would run in 8 bit mode, ;) if we want to make the next step in computer future.the idea to fight windoze with "incompatible hardware" is not really good, i am afraid that could result in M$ making people by only 32bit cpus ! In times of win31, there were 368 and 486 CPUs they were real 32 bit cpus, but windows was only 16 bit, same scenario, and the people were alright with windows. So theres still a long way to go until M$ is scaled to a small software company and until there is real competition on the OS markte.
machosofts managers would use their smart market strategies
to force the people to accept their standarts.
they have so much money, they are so powerful...
Many users dont care if there Osystem is running in 64 bit or 32 bit mode as long as they can use their software mostly games,so
the only chance in my opinion to fight m$ is to make people see what important role computers and communication systems will have in the future.
People tend to depend more and more on relayability and stability as well as availability of computers in all day use, for comunication, office, work, household...so what will be the social consequences if there is a monopolist providing the software(and hardware?) we use, and whos only goal is to become even richer ? One would be a possible seperation of society in two parts, the ones who can afford the software, and the other who cant. We need open standarts, competions and linux
Win2k 64bit will be shipped whether its ready or not, at a cost to those who really need it ready. Then Janus will come out, promising to fix all the problems in the universe.
You know, this is the one truly amazing technical thing that Apple did that it never gets credit for. When I was in college and got my first PowerMac 95% of the older software just worked (except for a few really cool hacks - but I knew they wouldn't).
They moved an entire OS, an entire platform and all of the applications that ran on it from one chip to another almost completely seamlessly.
It went so well that no one talks about it. I think that that is Apple's best technical achievement ever.
- AC
As anyone in the hardware business knows, there is a huge gulf between what Intel's just announced (preparing the design to be fabricated into physical chips for the first time, traditionally called "tape-out" becasue the design data used to be shipped to the people making the masks on spools of tape) and actually being ready to ship product to customers (i.e. OEMs).
Keep in mind that this means they don't have a sungle physical Merced chip yet, which means they've only been simulated, never really tested. Although I don't know anything about Intel's internal simulation tools and methodologies, I'd be surprised if they've even been able to boot an operating system on their simulated design. I'd be amazed if they've simulated significant real-world applications. In other words, at this point Merced has had very little real-world testing. That's what the next step ("first silicon") is all about: testing out whether the design actually works in practice (and systems) rather than just in theory (under pre-silicon simulation).
That's not to say that Intel hasn't expended a huge effort already in working to eliminate as many bugs as possible before taping out (in fact, I'm sure they have), but there are always more bugs when the silicon arrives. In fact, many of the problems encountered in first silicon are effects which simulation can't (or at least doesn't) effectively capture (race conditions that earlier analysis missed, unanticipated electrical and electromagnetic effects, yield problems, etc.). These problems are worse when you're talking about a new from-scratch design. There are also bound to be other problems when you're talking about a totally new processor architecture (such as IA-64).
Usually the process between tape-out and shipping to clients goes like this:
To me, it seems that the estimate of one quarter between tape-out and shipping samples to OEMs seems extremely optimistic. Of course, I suppose Intel could be planning on using the OEMs for debugging their first or second pass silicon (before they've made it really robust), but somehow I doubt that. I would expect that it might be more like two quarters before anybody outside Intel actually sees a physical Merced chip.
But then again, hey, what do I know.
Kenneth C. Schalk < kenneth.schalk@compaq.com>Software Engineer
CAD & Test Group
Alpha Development Group
Compaq
I just had to reply to all these random comments about Merced to answer a few questions. I don't know everything because I didn't design it but I've heard bits and pieces. These first concern was when is Merced going to be out. I noticed there was on reply that explained that pretty well. They just finished the DESIGN of the chip. You are going to have to wait until the processor is taped out, and silicon is ready for system validation. After the initial chip is produced which takes a few weeks, it will be hammered for bugs. I also wanted to comment about it being buggy. Intel learned from the first pentium that had problems. You don't make a mistake like that twice, but there is no such thing as a bugless chip. Some bugs will never be found. Sometimes you have to run a single test 100,000 times to find one bug. But you better bet this chip isn't going to be the Windows 95 of microprocessors. I also wouldn't get your hopes up to actually get one of these in your hands. They are going to start out like the Xeon. Really expenisve for businesses. There is no way everything is going to jump from 32 to 64 bit architecture over night. So keep your pants on, it will be a while. Anyway, I can't wait until they are affordable but it will be a long time. Faster games are always good, but they don't rely on CPU's as much anymore. Processor speed isn't the bottle neck anymore. Think about it. I have a Pentium 400 at home, but the bus speed is only 100. Anyone see the problem? Oh yeah before I forget. I don't know what you are all talking about the Alpha chip for. If you mean the really fast one, that Digital designed... It doesn't exist anymore. Digital is dead. It was bought by Intel and Compaq. That is what I do. Intel got the StrongARM chip from Digital. It will be used in top set boxes. Really useful when digital television becomes a standard. expect to be able to surf the web on your tv pretty soon. I think some of the technology that went into the StrongARM cames from the Alpha chip. Its a risc processor, the 2nd chip due out should give 600 MHz at half a watt. Check it out on ARMs homepage. :)
That the initial version of the IA64 chip won't be all that fast... stick with IA32 unless you need to develop for IA64...
-- Erich
Slashdot reader since 1997
Linux will not be a 32-bit OS on Merced. If it can be made to run natively at all (and Linus has been quoted as saying that this is a "done deal"), it'll be full 64-bit, just like it is on Alpha and UltraSparc.
And it's not '3dfx' stuff- yes, Altivec is vector registers, i.e. four 32-bit values can be changed with one instruction, but these are general purpose registers, and Apple is already trying to figure out ways to use these 'fscking huge' registers in anything from screen update to memory management to Quicktime to yada yada yada- sky's the limit! If you can get a 128-bit chunk of it into the register, you can do it faster. One convolution kernel ran something like 200x faster on Altivec because it happened to coincide with register operations.
Because these registers are general purpose, there's every reason to expect that gcc/egcs can be told about them, and hackers can find ways to make use of them- ideally by telling compilers how to optimize so the vector processors/huge registers get used. At that point, any PPC Linux users can simply recompile favorite applications to get them running markedly faster- and recompile the kernel to get that running markedly faster- something that MacOS users will only see indirectly, with system updates and with Quicktime.
Personally, I'm looking forward to hearing about this...
Cyrix dead, Winchip dead, AMD has had the COO bail out and is hemorrhaging money like mad. All this because of Intel and their basic viciousness and inability to coexist with competition. And you think everyone should make nice with them _now_ that they are finally stepping into almost complete monopoly for CPUs? :P Brought home the pet 486 from work that I've been putting linux on. However, the main computer is non-Intel. It's a Mac. I like Macs, but isn't it kind of pathetic that the only choice you have other than Intel is to go use Macs? (yes, I know, Athlon. Yes, please go and buy lots of them. AMD deserves better than the stomping they are getting. I don't think being better will save them, so buy _now_ before it's too late.)
I do have one of their CPUs in the house.
I've never been so pleased to be running a 604e as now, when the whole x86 market is being systematically exterminated. I'll just keep on supporting PPCs, seeing as I already have the Mac and the software to run on them. Things are already nasty on x86, good luck being able to afford Alpha machines (and people say Macs are expensive!) and if you're still supporting Intel, well, just think about what your money is doing, won't you? One hand supports Linux, for now- the other's killing all your hardware choices as fast as it can.
The first few instances of each new product line from Intel have always sucked:
- Pentium 60 & 75
- Pentium II 233 & 266
- Cacheless Celerons
- Pentium III (not much faster than a Celeron at the same clock speed)
Later revs will probably kick butt.I'm surprised noone seems to talk about Transmetta anymore....
I havn't heard a good Transmetta gonna whoop Intel rumor in months.
This is because the biggest bottleneck isn't the WARP engine setup details, or anything chip-related, it's the fact that GLX (the OpenGL framework the G200/G400 and nvidia drivers use) relies on the X protocol, and moving that much info through sockets is gonna slow it down. I would not expect to see anything better than 10-20 fps on X at all until XFree86 4.0 and DRI are out later this year.
-lee
for a good example of how to dump legacy support in a chip look at what apple did when they moved from the 680X0 to the PowerPC... the PowerPC has no support for 680x0 instructions so apple built an emulator... works flawlessly and is a very elegant solution
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Heh.
I have more faith in HP than Intel... ;>
Very nice... I'm hoping to add a second 400MHz CPU to these E250s and add another 1GB of RAM. Not a 3500, but still damned nice... :)
And I get paid to do this!!! God, sometimes I really love my job... Pity I have to ship it out after build and installation
I hear ya. Feel the same way... The E250 under my desk has gotten quite comfortable... :)
The newer, better, faster Sparcs on the horizon should be even sweeter.
>Look at Digitals compilers under Digital Unix.
.25G.
>Produces much faster code than \1. But does
>that matter one bit for the \1 community? No.
>Didn't think so.
Speak for yourself. I work daily from my FreeBSD box to my boss's linux box running a commercial fortran compiler (g77, etc., don't even play in the same league). We have absoft fortan, but it would have been digital if it were available.
We were even willing to pay the extra cost for the alpha box, but the costs of DU itself, both for purchase and the risk of getting sucked into the university system and fee'd to death there, mean the x86/linux/absoft solution.
A year an a half later, I've hit the price. I never thought I'd see the day I *needed* a 64 bit operating system, but now I do: I need an array with more thatn 2^32 bits, and more than 2^32 bytes would be nice, too. Absoft uses Cray code that bit addresses, leaving the size limit on an array of derived type at about
jeeze, and our company has been running on 64 bit AS/400's for years... hmm...
Large print giveth, and the small print taketh away
>Think about it: if a kernel compiled under,say, Sun compiler will run >twice as fast as one compiled under gcc,what will happen to gcc?
Absolutely nothing. People will still keep on using using GCC as they have always done. Why? Because GCC is multi-platform. Compilers like Sun's aren't. End of story.
Actually, you have it backwards; Motorola will be supplying the Altivec-enabled chips, while IBM is concentrating on increacing the clock speed rather than the number of instructions.
Phil Fraering "Humans. Go Fig." - Rita
(currently testing something about signatures here)
I doubt 64-bit support will be robust. I think there will be a lot of heat-related reliability issues, especially when run flat-out. I think there's likely to be at least one bug in the arithmetic unit.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
There's also something bigger, better and eventually cheaper on the horizon. If a system meets your needs now then get it.
So what kind of nifty bugs in these chips are we going to be anticipating?
True! But design should be complete before production starts, and this is what they claim. It is just another link in the chain. For those who know which link they depend on, it gives you something to think about ;-).
I just like to see new announcements
and if you merge those two (while they are still trying to make a duo/coalition) their future is even more uncertain.
but anyway, whether they both will suceed ot not (or both fail) it can be good: it'll show the people that past years of "inovation" as performed by wintel coalition has been mostly result of marketing (because real inovation is done in laboratories, not on papers containing press releases).
it can also cost us (or them? or some other users? ot some other developer? ...) lot.
hany
just encourage competition so we can get better products at better prices and with a lot of choises.
hany
To get their NUMA work?
Alpha: Born 1992. Merced: Born 2000? Who needs yet another 64-bit architecture, anyway, especially since Alpha is rumored to be at 1400 MHz in 2000?
there are 3 kinds of people:
* those who can count
there are 3 kinds of people:
* those who can count
* those who can't
Computer programmers have lost one of the original coding techniques that they all used to follow; "Use efficient coding methods".
Most good programmers went to "get it right, and then get it fast."
I was talking with my sys admin (an HP fan). I mentioned getting an alpha for some number crunching which I need to do. Take a look at this
0 0/tech_specs/index.html
http://www.hp.com/visualize/products/cclass/c30
I'm not sure where the alpha is not but this thing is turning out some impressive numbers.
Does it also mean that it is a bad idea to buy an "old" PentiumIII processor ?
Software written for the Merced may not run on a PIII, but software written for older x86s will still run on the Merced. Just as current x86 chips can emulate "real mode" for older apps, so the Merced will be able to use and/or emulate the processing modes used in current x86s.
A dedicated x86 clone - like the K7 - will be able to run these applications faster. However, _if_ they did a good job on the Merced's core, applications written natively for the Merced will run faster than applications written natively for the K7, as the K7 will still be hampered by the x86 instruction set and register structure.
_If_ Intel did a good job on the Merced core, it will be fast but still 1.5x as expensive as other RISC solutions due to the extra silicon needed to support x86 legacy features.
However, I gather that they may not have done such a good job on the core. We'll see when prototypes are benchmarked.
Please click on "user info" above and see my previous response in this thread. It is a reply to another poster who presented almost identical arguments.
Again Linux is the exception....
Correction: Windows is the exception. See the post that I referred to.
Re. games, I realize that most game software isn't perfectly tuned, but all of the "boost FPS by 50%" optimizations will already have been made, because it is in the game company's financial interest to do so - as a result of this optimization, they can either lower the system requirements or keep the frame rate and jack up the graphics detail. Both correlate directly to better sales.
From where do you get the impression that games are horribly written?
Um, no. New games require more hardware because they have fancier special effects and more detailed models. This is not really related to code complexity. It makes the _data_files_ larger, naturally, but that's about it.
Granted, there are some game writers who consider special effects a reasonable substitute for gameplay and plotting. These writers' games will sink, however, because consumers do want games that are actually fun to play.
Re. hardware vs. games, game hardware requirements will plateau when cheap hardware exists that can handle just about all of the special effects in the OpenGL feature set for photorealistic models at high resolution in real-time. Beyond that, there isn't anything left to add hardware load on the graphics side of things.
Things like AI and physics may continue to develop after that, but physics at least won't add much more load if you have hardware that powerful.
Added to that, processor design has become more bloated, moving deeper into a large, complex instruction set. Simpler processors, such as the ARM, outpaced the Intel chips even at a fraction of the clockspeed, because they were better designed.
Um, no. Look at just about any non-Intel processor. Intel chips are bloated because Intel continues to support and extend an instruction set that wasn't designed to be extensible. They're about the only major microprocessor manufacturer that made this mistake.
Also, didn't ARM not _have_ a floating-point unit? With more silicon to devote, of course they'll be faster at integer operations.
Finally, throw in that most modern OS' are bloated and top-heavy, Linux being one notable exception
And *BSD and BeOS and...
Microsoft is the primary culprit for slow OSs. This is because Microsoft is purely market-driven, and the market that they cater to would rather buy a new version of the OS with more features than a new version of the OS that works more efficiently.
OSs and chips can be designed cleanly - and _are_, with only a few exceptions. Take a look around at what's available, and you may be pleasantly surprised.
I saw a report earlier this year sometime that they'd managed to boot NT on their simulation.
Which must give them some hope.
My Journal
> Because, if there isn't a stable, scalable
> 64-bit version of Windows Server
> ready by the end of next year, the path will be
> clear for the *nixes to severely
> dent Microsoft's marketshare.
Nope. w2k is not 64 bit capable. In fact, windows will probably run in a 32bit emulation mode. Much like what NT4 does on the Alpha. From what I understand, NT4 is _not_ easily ported to 64bit, for some reason or another (otherwise, why isn't the alpha version of NT running in 64bit?). This means it will require significant time on the part of M$ to either port their OS to 64bit, or write a totally new version of windows...
As soon as Linux gets a compiler, we will take full advantage of the architecture. You know how quickly we work... Another factor is that Intel has been making friendly gestures at the Linux community. They were even so audacious as to donate some compiler optimizations. Personnally, I think Mickeysoft and windows are heading into some dark days, which I don't think they will survive.
Jeff
It must be nice to have a major website quote you without any challenge whatsoever. Where's the skepticism? If Intel has missed all of its other targets, why does anyone think Merced by middle 200 will be any different? I'm not knocking what they are trying to do, but they are still along way from a product anyone can use, and there's no guarantee that this will be a success.
/. but you're young, you can afford to slum a little.
This article from Byte goes into some of the problems Intel has from this stage forward. A little low-tech for
IA64 is not desighned to be 64bit totaly but expanderable easyly
what this says to me is, to get press on server stuff so K7 doesn't !?
they are still signifactly tweaking the compiler !!
the actual silicon is not the hard part its the software IE the compiler
IA64 needs a *GOOD* compiler to even compete with alphas but a realy good compiler (years off) would kill an alpha at the same clockrate HP are doing TRIMERAN and many supercomputer centers have done research on how VLIW (sorry EPIC) work and could be better
>>>wait and see boys and girls IBM bought sequent for a reason
john jones
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
Who wants to bet that M$ will be pressuring Intel to delay the release of the Merced until they can finish throwing something together?
The Merced is supposed to run IA32 code, but will it run a 32-bit OS like Linux or NT out of the box (or straight of the net in the case of Linux)?
Intel themselves have said in press releases that IA-64 is intended to be a server architecture. It may happen somewhere down the line that they slowly migrate into the consumer realm, but not even Intel is pushing that concept. If it's any indication of their plans, the "Willamette" architecture has been handed the "P7" designation, not Merced. Maybe they'll call it Pentium !V or something like that.
Don't you have to be a bit of a sicko to have gotten attached to x86 machine code? :-) Maybe I've just been programming ARMs for too long...
--
Matthew
Matthew @ Bytemark Hosting
Come now! I see many people espousing the myth that faster computers make lazy programmers. Do any of you people claiming this write code? Have you looked at other people's code? I don't know about you but where I work stuff is tight. Not a bubble sort to be seen. If the code gets sloppy it's not lazyness, it's MARKET DRIVEN. Sheesh...get a clue. ANd put those VBRUN DLLs away before you hurt someone.
Blar.
Merced family is heavily dependent for performance on paralellizing compilers. I suspect that making the silicon will be the easy part (I'm a software guy, hardware guys may disagree with that), but making good compilers to take advantage of the chip will be a bitch.
It seems that we are entering an era when the performance of your application is going to depend on the quality of your compiler/interpreter as much as on the actual hardware inside the machine. This is both good and scary. Good if the free compilers (like egcs) will be able to compete with and outperform commercial compilers -- that will be a great boost to free software. But there is also the scary part: if the free compilers fail to keep pace with commercial offerings, they will die. Think about it: if a kernel compiled under, say, Sun compiler will run twice as fast as one compiled under gcc, what will happen to gcc?
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Your point being ? ( bar some pedantic machine code/assembler distinction... )
-- I'm drinking myself to sleep again...
they should just tack MMX and SSE onto the 386 core, and then embed that in the Merced... then forget about it... it's running at like 10gigahz, or whatever. so it'll at least be as fast as regular chips...
_
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
I've heard rumors that Intel has rooms full of Quad Xeon PC's running Linux Beowulf to do chip simulations for IA-32 and IA64 designs...
Starman97@Gmail.com (bring it on spammers)
Mid-2000 is like so late to bring a 64-bit architecture to the market!!!
Alpha all the way, baby!!
"Code free or die!"
isn't this kind of like saying that the move from 16-bit processors to 32-bit processors was not necessary?
get nemulator
Sun went from 68000 to SPARC andf now UltraSPARC
:)
DEC went from some old MIPS (I think) to ALPHA
IBM went from who knows what to PowerPC
Apple went from 68000 to PowerPC
All companies got to a point they dropped everything and moved on. UltraSPARC is still very similar with old SPARC V.8, but all companies got to a point that they said this old 70's and 80's CPU design methods just don't apply anymore. Will Intel ever do that and get rid of the Legacy patchwork?
backwards compatible.
;)
just it isnt going to do a great job at it.
so just recompile everything for it
The Alpha did not go to intel. Samsung has been keeping it alive and well, ever hear about the 21264?? You should check the specInt/FP's on this puppy if you want fast. The Mercede doesn't even come close on its estimates to the current real-world 21264. Hell, even the 21164 / 533 MHz that I am using now is faster than intels fastest pIII Xeon @ 550! (which is now about two years old, where was intel when the 500+ bandwagon drove by then, 550 is slow, alpha is already shipping 700Mhz plus, using a .25 core).
Get with it!
What reason will there be to buy an Intel IA-64 chip when the major reason business' buy Intel is backwards compatability. I will be able to get a 64-bit Alpha chip that not only outperforms but is cheaper than a 64-bit Intel. The reason people kept buying Intel is backwards compatability, and while this still maybe true it is irrelivant. The people buying 64-bit processors are usually corporate customers with large databases in mind. So unless, maybe you just want a kick ass game box, why would one buy it when there are far better solutions through other vendors.
---- aut viam inveniam aut faciam
In fact there will be 2 versions of the G4. One will be 32bit data path and the other will be 64bit. Look up "powerpc G4" at www.mcg.mot.com.
Don't lead me into temptation... I can find it myself.
I can't wait to hear what a 600 MHz UltraSPARC can do!
Disclamer - Opinion of Person
It is a pitty that we'll have to forget that old machine code, which some of us got so attached to.
Does it also mean that it is a bad idea to buy an "old" PentiumIII processor ?
Human beeing is just an advanced, self-learning machine.
So you think it is all bloated and bad, huh? The problem is not the coders, its the language. The compilers really aren't that efficient. If you want really fast, really small programs, I guess we could all learn Assembly, or better yet, we could write directly to binary code. Yeah, that's it!
...for any speed record breakthroughs. The IA-64 chip will rely VERY heavily on compilers and code quality to achieve great performance. Right there you can go ahead and scratch out windows. Linux will run nicely on it PROVIDED a good compiler is released with it.
You want 1 Ghz? Look out for AMD, people.. the K7/Athlon will be there by Y2k (ok that's just my estimate). They are going to go hand-in-hand with Alpha. Intel's a great company, but they just got outclassed by AMD for the first time and the won't lead the race again for about another 2 years at least. Alpha? Here's their chance to make a break for it, too.
The faster computers get it seems the more bloated code seems to be. Computer programmers have lost one of the original coding techniques that they all used to follow; "Use efficient coding methods". Now it seems to be "Hey, this works..". When you compare the speed of todays computers with todays software and that of 10 years ago...computers are running no faster then they did back then. Sure you could load the old software onto the computer and it would run fast as ****. But it is all obselete now. What is the point in making faster computers? Just gives software companies the ability to slack off a bit...
Like in the case of M$...give them a faster chip and they can add a few more million lines of code to their already bloated OS's...
(Of course Linux is the one exception to this statement..)
"Imagination is the only weapon in the war against reality." -Jules de Gautier
I am fully aware that games are getting more complex then those of earlier years, but there is still no doubt in my mind that code still could be optimized. And my comment goes beyond just games; but applications and Operating Systems as well...
Again Linux is the exception....
"Imagination is the only weapon in the war against reality." -Jules de Gautier