x86-64

[meyerm]

Hi.

Are there any plans to build a x86-64 based distribution of gentoo? Or is it enough to install gentoo 1.4 with the correct flags?

Thanks,
Marcel

[delta407]

If your processor understands x86 code, the existing installer will work fine. You just need to tell your compiler to generate x86-64 code and everything will work, much like you can tell it to generate Athlon-specific optimizations or P4-specific opcodes (SSE2).
_________________
I don't believe in witty sigs.

[meyerm]

I just was curious if there are any problems with the 64 Bit optimisations of gcc and some older programs. But since gentoo is one of the most uptodate distris around...

Thanks for the answer.

[masseya]

Because gentoo is a source based distrobution, it's as up-to-date as the latest gcc.
_________________
if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..

[arkane]

Just curious, does Intel even have a 64bit processor out yet?

I know they were talking about Itanium... but is that out yet? If so, is it pure 64 bit, or a risc chip that has emulators to do x86 code?
I don't think gcc even has optimizations for that yet, does it?

[meyerm]

Intel does have a "real" 64 Bit processor (no x86!! ). The Itanium. But it is already outdated...

For now, it is the Itanium 2. But when AMD is successful with its x86-64 they will bring out a new 32/64 Bit x86...

[arkane]

[meyerm]

[masseya]

Itanium was never really any good. AMD's Opteron (64 bit chip) is supposed to be out the first half of 2003. I got this information from this article on Tom's Hardware. If you want to search their archives, I'm sure you'll find plenty of information on why Itanium was horrible.
_________________
if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..

[arkane]

[meyerm]

[Pigeon]

Pushing this even more off-topic than it already was...

Are Mac's RISC? I've always been confused by the FUD stating that Macs are both RISC-based and accomplish more ever cycle.

As for RISC vs CISC... Does RISC have any advantages other than a less complicated/smaller processer? (less complex results in lower price and lower temperature output, which results in greater MHz... at least, that's what I've been told )

All I know about RISC vs CISC is that they usually end up in heated arguments (re: flame wars) that boil down to personal preference, typically along the lines of PC vs Mac.

[syadnom]

RISC :
smaller,
cheaper(yes cheaper - see smaller)
faster(potentially)
cooler(-see less power)
require less power(-see smaller)

CISC:
set instruction set
more engineering time put into them(intel, AMD, Huge industry)
cheap(the more you make, the cheaper they get)
a long time on the job, CISC chips have been around a while.

RISC chips, in general, are very efficient, and very powerfull per clock/pipeline)
a RISC chip with a 10 stage pipeline will most likely be faster than a CISC chip with a 10 stage pipeline, assuming similar clock speeds.

RISC chips are not power hungry, they run cool, and are very powerful per clock. this makes them great for server environments, multiprocessing, server racks, notebook PC, palmtops, etc etc.

for instance:
Apple Xserver
ANY PocketPC computer, my understanding is that StrongARM and MIPS are both RISC
ibook, powerbook

RISC is a better idea for computing than x86, but it has not had nearly the money put into it that x86 processors have, so it is lagging behind in advancement, which goes to show how good it is.

A PowerPC chip is nowhere near as advanced as a P4, maybee about 1/100 the money has been spent on its development, but it is a very powerfull chip. a 1Ghz PPC chip is the equal of a nearly twice as fast(MHz) P4 2Ghz in most computations. It is slower at some things as a cause of the fact that you can't compare two differnet architectures equally, but given its due handicap(engineering time) the PPC chips really are good. and did i mention how cool they are?

If AMD and Intel had put the money that they have put into CISC into RISC architecture chips, they would be at 5Ghz easily by now, if not more, AND more powerful per clock than CISC chips are now.

If apple had not locked up the clone market, maybee we would have a Mac that can compete with a x86 PC, more people developing for it is better right?

x86 Chips are engineered around the fact that RISC chips are better, even modern x86 chips are RISC with x86 encoders and decoders. these eat up valuable die space on the chip, and is why they are as big and expensive as they are. the x86 decoders in a K6-2 processor took up nearly half of the die. they take up equal parts of the logic on the rocessor on an Athlon, while cache has been added to make the x86 en/decoders about 1/3. Imaging how fast your Mac would be if AMD and Intel were building RISC only processors OS X would then TRUELY be an able David to the M$ Giant.

but now i am done with my rant

oh, recommend a move to general linux as thread is securely off topic, or a lock.

[masseya]

The battle between RISC and CISC isn't quite that cut and dry. There's not really a good way to compare them because they are different architectures.

In general, a CISC chip will have a huge pipeline with complicated branch prediction because each instruction requires more work than an instruction in a RISC chip. This means there's a high penalty for a missed branch prediction because there's a lot of work that was done to fill the pipeline with bad data.

A RISC chip will not have as big of a pipeline or as complicated a branch prediction unit as a CISC chip. There's not a huge penalty for missing a branch because there really wasn't all that much in the pipline (relatively) to begin with. Kinda makes you think, "Well, why not just use that instead??" Well, the complication has to go somewhere.

This mystical somewhere is the compiler. A compiler for a RISC chip has to be very compilicated compared to a compiler for a CISC chip because it doesn't have as many instructions to work with.

Here's a good example. We could modify english to where it would be easier to write a single letter. Right now there are 26 letters of the alphabet. That's a lot to remember how to write. What if there were 5 letters? We'd only have to remember how to write five things. However, all our words would be huge combinations of these 5 letters. This would make speaking very complicated and if we were writing anything other than a few letters it would take more letters to make sense even if we could write each letter really really fast.

This is the job a RISC compiler has. It can be done. It would certainly make the post-production usefullness of a RISC chip longer because to improve performance with a compiler would be easier. However, even x86 compilers are not all that simple. Adding complexity to a compiler creates a huge problem in other areas as well. Think of compile time. Who here wants to wait longer for their gentoo install to finish? Also, think about how much fun it would be if we wanted to have a hugely complicated Open Source compiler. The Intel compiler has pretty much come from no where and passed GCC as the best compiler for x86. That's because the people making it were able to do it 24/7, get paid for it, and (let's be honest) use the code of gcc for inspiration. Now if we make it even more complicated to make a good compiler the advantage for a company to produce a better compiler than a team of Open Source (on their own time) developers is increased. Who wants to start paying for a compiler update every six months?

I'm not saying it's not possible because I certainly believe it is. Open Source people develop a lot of great stuff. (ahem, uh, Linux?) I'm just saying that if we have to do more work it's only going to help corporations who want to sell their products. Wouldn't it suck if Windows actually ran faster than Linux because they were able to take advantage of the fact that they could spend millions on buying the best compiler designers out there to make a compiler that was 50% faster than the best open source effort?
_________________
if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..

[swingarm]

I work for a contractor to HP and I've installed Linux on McKinley's(Itanium2) and it doesn't look any different than anything on the X86 platform. I've installed Debian and Redhat on them but can't tell you much about them as they pertty much ship out after I load them. I do know that the first Itanium's were pertty much castrated due to some of the features not being enabled on them, the McKinley's are now fully enabled and maybe we can now see the real potential of this platform. I think the Itanium2 is going to be released in the next couple of weeks.

[syadnom]

itanium2 is out, a hospital in my area that i do some tech work at just got one. the thing is fast for just 1Ghz, but still just 1Ghz and can't really keep up with a P4 2.4Ghz+ processor for most things. The floating point abilities of this processor are amazing from what i have read though.

anyway, the Itanium is a VLIW processor. Its not RISC but it is designed using the ideas that RISC has been using for years. VLIW has fewer instructions that x86 but each instruction is very powerful as compared to the very simple instructions in x86 and RISC chips.

Tristam29 - nice description, i agree 100% with that.

RISC chips do typically produce larger binarys than x86. And compiling software on a PPC does take a bit longer than on an equivelent x86 machine, keep in mind that a PPC RISC compiler can easily cache results from the compiler to be re-used while on an x86 that becomes quite expensive in terms of memory use, and processor use to sort and manage the cached data. although slower to compile, it is not horribly slower because of compiler optimizations that are much easier to do on a RISC system.

now i dont know if gcc for PPC does any kind of cacheing or anything to improve compile times on any platform.

anyway, their are much better RISC chips out their than PPC, like sparc, PARisc, Alpha.

when Alpha was still a serious chip(you know what i mean) tell me that and intel chip could even think of keeping up. i remember Alpha chips shipping at 600Mhz when the p233mmx was juist comming out, and well all know an Alpha is faster per clock that a p1@233.

[masseya]

[phong]

A couple important points on the CISC vs. RISC thing, which is really a complicated issue, and not as simple as one is old and one is new, or one is good and one is bad.

One thing to zap right of the bat is any information from Apple reguarding performance. Their FUD re: PPC vs. Intel IMO put's Microsoft's worst to shame. My favorite is their claim that G4's were automatically faster than P4's because they had a shorter pipeline. In actuality, all other things being equal, the opposite is usually true (within what the laws of diminishing returns permit). The advantage of a shorter pipeline is less impact from branch mispredicts, and the advantage of a longer pipeline is the ability to take in more operations per unit of time. Judging the speed of a processor just based on the length of its pipeline is even more stupid than judging it based on MHz. Fortunately, Apple's actually recently started to stop with the mis-information campaign re: performance. Sadly, their not alone - on CNBC I saw a big-wig from AMD state that x86-64 would "automatically" be twice as fast as 32-bit processors because it's 64-bit. Sigh.

PPC processors ARE smaller and run cooler than Intel, but since Apple hardware is so expensive, I don't know that they've proven cheaper, which is supposed to be one of RISCs big advantages.

CISC has some performance advantages that people ignore. True, they do more per instruction, but that's a minor deal, since most of the insturctions you use most of the time (loads, stores, bitshifts, adds, subtracts, etc.) are simple operations that are basically the same on RISC and CISC, and you use the complex CISC operations infrequently.

Also, sometimes it is more efficent hardware AND software wise to use CISC-style operations. For example, many RISC processors (early ones mostly) don't have a multiply or divide opcode. They have "partial" multiplies and divides that have to be executed several times in microcode (or something similar). Turns out, that's stupid, and it works better to just have a mul and div (which are present in newer RISC processors).

Also, CISC usually clobbers RISC processors when it comes to code density, espescially x86 CISC. Opcodes on RISC processors are fixed sizes - 32-bits or 64-bits sometimes. On an x86 they vary from just a single byte for quite a few, any where up to, um, lots IIRC. The most commonly used ones are usually shorter, which results in a sort of huffman-coding style compression of your executables. This means your processor has to fetch fewer bytes to do the same amount of work. The saves in cache misses, bandwidth, etc. aren't insignificant.

Also, the whole CISC vs. RISC argument is really moot anyhow. Modern CISC cpus (i.e. current Intel and AMD processors) actually translate incoming CISC opcodes to internal simpler RISC-like ops on the fly. Sure, that extra translation hardware isn't simple, nor free, but over time, it's becoming an increasingly smaller percentage of the hardware in a CPU.

Now, it is true that it would be dumb to start a new instruction set that was CISC, but when you've already got one that's popular, works great and has been around a long time, there isn't that much pressure to change it.

It's also moot because new instruction sets won't be traditional CISC or RISC. They're more like post-RISC. Even the processors in our computers we're using right now are sorta post-RISC (superscalar RISC really). F.ex. Intel's Itanium IA-64 processors are more like VLIW (or their term, EPIC). Instead of having a string of simple, sequential operations as in RISC, the opcodes have information coded into them by the compiler to tell the processor which operations can be executed in parellel, rather than having to have all the extra hardware on the processor to determine parallelism. There's also information in the opcodes to help the processor better predict branches - or how to execute both possible outcomes of a branch and just squash the one that shouldn't have executed as soon as you determine which it was.

Of course, the advantages of such an instruction set have yet to be proven, just as RISC hasn't been able to squash that ol' Intel. The performance of such a processor is critically dependant on compiler optimization. To me, the most exciting thing about IA-64 is the juicy 128 general purpose and 128 floating-point register file. I was very dissapointed that AMD just went with 16. Most compiler optimizations increase the number of simultaneously used registers, and the 8, not-completely general purpose regs on ix86 really put a limit on how aggressive a compiler can be and still get returns.

I have a bit of a passion for compilers and architecture, and could go on for hours, but now this post is ten times too long and I'm going to stop. Really.

[arkane]

I just wanted to thank everyone who described the differences, good and bad, in comparison of the two architectures. I have done work in the past with the two register combinations on paper, however alot of the newer stuff is still beyond me. (I was very interested in assembler language in the mid 90's and learned a great deal but thats old news now.)


This thread is still somewhat on topic.. but anyhoo... just wanted to say thanks.

[syadnom]

i also agree with you phong.

CISC is not a BAD design, in fact it can be VERY efficient when build as a specialized processor , on the other hand, as a general purpose processor CISC is not as good as RISC(in most cases). i also agree on the pipeline part(how could i not??) BUT the advantage is that in general purpose processing where branch mispredictions are fairly common the performance hit on a misprediction gives an advantage to lower pipeline count processors.

sure a 10 stage pipeline cant execute as many instructions in parrelell or with pipeline overlap(i made that term up, i cant remember what to call it, you know, one operation is at the end of the pipeline and another can start before the first is done) but mispredictions require at least one full clock to fix. fiving a lower pipelined cpu that much more time to catch up.

RISC chips should be cheap because of simplicity and size. not to say that they are curently cheaper but thats what happens when 100 times as many CISC chips are made, they get cheaper

i agree that the issue of CISC vs RISC is much more complicated than what has been said or even what will be said, but politics play a role as well, why ditch x86 when its so well supported, and so well understood? its stable and solid and wont go away for a while.

i also dont believe that apple/motorola/ibm with their ppc chips are going to be the future of RISC and the desktop. i personally see some variant of a sparc moving forward. the linux community is catching on the the sparc thing rather quickly as the cost of sparc hardware comes down. AND sparc is an open design, to can see the "source code" for the architecture, which is second best to actually seeing the "source code" to the specific chip. i dont know whoo all makes sparc compatible chips, but SUN and Fujitsu are two of them.

in the future i see a community of open source people and companies (redhat, mandrake, suse, etc) getting together on a standard open platform and having TSMC or UMC build some chips. but that is quite a few years off, problably after some intel/amd market collapse or something, maybee intel will turn in =to the next enron


tristam29 - just look at how much faster binaries are comming out of gcc3.x than from gcc2.x, your looking at a significant gain on most programs, 5+% for just a new compiler. how fast would a 1GHz Athlon be if it had a "perfect" compiler? maybee 20% faster than it is today, maybee more? classic case of software not holding up its end, hardware keeps getting faster and faster but software doesnt, in fact software gets slower and slower because the hardware can handle it.

look at how much faster windows3.11 was than 2000 or XP, sure your missing a lot of features, but look at the hardware that win3.11 would run on. now look at KDE and Gnome. and now black/fluxbox.10000 features, but each feature adds to bloat and theirfore slowness.

in a perfect world, the processors would be so fast that programmers could just build it and let it run and it would be good, but this is not a perfect world so programmers need to optimize their software, and the compiler to improve efficiency and theirfore speed, performance.

about your question, i think that it would take a company with a bit of money to build a better compiler for the closed x86 platforms, we know the x86 part, but what about the rest? you need to license it to see the 'source' and then to improve it. if, on the other hand, every part of the x86 family of chips were open, the opensource community could build the absolute best compiler in a very short time.

also, the MANY MANY people that have not followed standards in the past have made it very difficult to build a good compiler, look at gcc3.x, it is more standard compliant and STRICT about those standards and that makes it break a lot of apps, if these apps were standards compliant in the first place, and not build on a "flawed"(i said it and meant it) gcc1,2.x series compilers their would be a lot less pain in the switchover that is happening.

id like to use the intel compiler as an example, intel has the plans for the x86 chips, everything from x86,x87, mmx,sse, and even 3dnow, and every other little part of the chip, so they build a very very good compiler in a very short period of time. unfortunately they charge for it so its not available to me who is poor.

[syadnom]

though drifting from topic, id like to thank everyone for keeping this topic, which is usualy a fight starter, civil and enjoyable.

[Pigeon]

I think it would be interesting to see what Intel and AMD would make if they could do it all over again- ie, it doesn't have to be backward compatable with every chip since the 8088. There'd be somewhat major teething/compatability problems for the first 2 years or so, but after that I think the desktop environment at large would be drastically better off.

I was fairly excited when Intel announced their 64 bit chip, since I assumed they were starting the whole thing over again- but it looks like AMD is b0rking that idea up a little bit.

[masseya]

[Pigeon]

I have the business sense of a horse-radish, so I don't really care, hehe.

<personal opinion>

Granted that backward compatability would have a lot more business sense- but IMO we'd be better off as consumers if they threw the 18 odd years of x86 advancement out the window and made the fastest processor they could.

</personal opinion>

[masseya]

If wishes were fishes we'd all be casting our nets.

<personal opinion>

I think we'd all be a lot better off if Microsoft suddenly decided to open its source code to all of it's products to the public.

</personal opinion>
_________________
if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..