PlaneShift
Support => Linux Specific Issues => Topic started by: Platyna on July 31, 2005, 03:03:23 pm
-
I would like to get some statistics which can help me to make sort of priority list. So, everyone please vote. It only applies for the people who uses Linux/UNIX of course.
Regards.
-
EM64T is buggy in 64bit, and AMD64 runs like dogs. I\'m not sure how Intel screwed it up.
-
I choose 64bits even if Im using both because ill only play ps with my amd64
-
i think 32 bits achitecture still have long time to live, because of the high cost of 64bits CPU
-
Originally posted by A?garion
i think 32 bits achitecture still have long time to live, because of the high cost of 64bits CPU
Keep telling yourself that! ;)
-
\"other\" would be the ones using 8, 16 or 128-bit architechtures?
In that case I\'ll select 8 and 32, although I don\'t play on the C64 very often anymore :P
-
Originally posted by A?garion
i think 32 bits achitecture still have long time to live, because of the high cost of 64bits CPU
roh...
http://www.fcc-informatique.com/indexvente.php?fam=3&sfam=11&prod=131&tri=Code
I dont think it\'s too much... maybe it\'s what can explain what I pay twice this price... I am mad !!! I am mad !!!
-
of course you are ;)
i apolgyze for what i wrote (\'bout the high cost, i was manifestly wrong...), but i guess it\'s too late to comme back on it,
as student i don\'t earn enough money to change my cpu once a year...
i\'m using a barton 2600+ since last year and i just can\'t spend money i earn during my summer job in computing stuff...
-
Originally posted by neme5i5
EM64T is buggy in 64bit, and AMD64 runs like dogs. I\'m not sure how Intel screwed it up.
1) EMT64 and AMD64 are the same thing.
2) Your performance problems aren\'t the hardware\'s fault. Most likely PEBCAK :) 64-bit runs very fast for me.
3) And it isn\'t really Intel\'s fault if there is a design flaw, which there isn\'t, because AMD designed it and Intel copied it.
-
Originally posted by Xordan
Originally posted by neme5i5
EM64T is buggy in 64bit, and AMD64 runs like dogs. I\'m not sure how Intel screwed it up.
1) EMT64 and AMD64 are the same thing.
2) Your performance problems aren\'t the hardware\'s fault. Most likely PEBCAK :) 64-bit runs very fast for me.
3) And it isn\'t really Intel\'s fault if there is a design flaw, which there isn\'t, because AMD designed it and Intel copied it.
Don\'t speak unless you know what is being said. It just makes you look ignorant.
(1) AMD64 is AMD\'s implimentaion of their own amd64 (x86_64) architechture. EM64T is Inte\'s implimentaion of amd64. They are NOT the same thing.
AMD\'s runs like a stalion, and Intel\'s is crashy as hell. I own both, so I know. I\'m not a windows user, so I have no clue from that angle. I use 2.6 64bit on both, and I can show the differences.
(2) So yes, it is the EM64T\'s fault. I have a POWER4 too, and Linux also runs 64bit on it great too. We have a POWER5 on campus, and Linux runs great 64bit there too.
(3) Intel didn\'t copy crap! If they did it would run like an Opteron. Do you even have an EM64T to base your _opinion_? Yeah, I thought not. I have four 64bit machines home in my office.
-
(1) AMD64 is AMD\'s implimentaion of their own amd64 (x86_64) architechture. EM64T is Inte\'s implimentaion of amd64. They are NOT the same thing.
Obviously you don\'t know of the AMD-Intel Technology Exchange Agreement, allowing both AMD and Intel access to each others schematics and to use each others technology in a different implimentation under a different or same name. EMT64 is AMD64. The only difference is that AMD64 is designed from scratch around a whole new architecture, where as EMT64 is just the AMD64 technology stuck onto an existing Pentium4 chip. Basically this means that AMD64 will beat EMT64 on a benchmark due to far better design. This agreement is how every time one company brings out a new technology, the other brings out something identical or similar in the few months following.
AMD\'s runs like a stalion, and Intel\'s is crashy as hell. I own both, so I know. I\'m not a windows user, so I have no clue from that angle. I use 2.6 64bit on both, and I can show the differences.
Yes, I have both as well, and either your chip is faulty or you\'ve configured it badly. Both work great for me, although AMD64 does perform better due to hypertransport and the onboard memory controller.
As for 2 and 3, read above. I\'m using gentoo linux on both systems and I see little difference in day to day performance, only under load. Oh, and assuming things makes you look very stupid :)
I have four 64bit machines home in my office.
Which of course obviously makes you know what you\'re talking about. Far more than someone who only has 2. :)
-
I still know, you don\'t know what you\'re talking about. I study pipelines for scientific computing. I know EM64T, and AMD64 are not the same. That is why it\'s called an \"implimentaion.\" (go look it up) Now who\'s assuming things. \"Obviously you don\'t\" I got a message for you on line 1, it\'s Mr. Pot and he says you\'re black Mr. Kettle.
You said it perfectly \"stuck on.\" Intel running heavy 64bit code is buggy. Oh wait, you just said as much. \"under load\" So which is it? Either my systems are setup wrong, or you just argeed with me?
1.) in your words, \"EMT64 is just the AMD64 technology stuck onto an existing Pentium4 chip.\" (BTW it\'s EM64T, and go look it up if you don\'t believe me \"Extended Memory 64-bit Technology\")
2.) in your words, \"I\'m using gentoo linux on both systems and I see little difference...only under load.\"
Now who looks very stupid? ...or arguing just to be arguing. Nothing I have said in any technical detail is wrong. Only the opposite can be said for you. The obvious conclusion here is that you need 4 64bit machines too, and then you\'ll know also what you\'re talking about? ;)
-
Ah, I see that it is actually EM64T. A lot of people and sites call it EMT64.
And I\'m not saying that the processors are the same. I\'m saying that the technology is the same. The way that technology is implimented doesn\'t matter that much to how that technology performs. Sure, it might be the rest of the processor itself which is crap, but I wouldn\'t blame the technology, especially as I\'ve seen EM64T based processors beat AMD64 based over several benchmarks, both first and third hand. If you\'ve got equivilant processors, with Intels compiled with EM64T specific CFLAGS (Like -march=nocona) and AMD\'s compiled with amd64 specific CFLAGS (-march=K8), with the other hardware in the systems being the same, then you can compare. If EM64T really ran such buggy code, then I blame either the compiler, or the person compiling the code, because otherwise there would be widespread reports of the processors not working properly and they would have to be withdrawn.
-
in case you forgot: \"1) EMT64 and AMD64 are the same thing.\"
You\'re reaching. I said nothing about the technology. Which in this case is amd64 (x86_64 as gcc calls it), I did say that Intel\'s version doesn\'t perform as it should. You said as much too. Why are you still arguing?
\"The way that technology is implimented doesn\'t matter that much to how that technology performs.\"
That is so wrong, I don\'t know where to begin. Stick to writing code, and repeat after me. There is no place like home...
-
\"They are not implementations of x86-64. There is amd64 and em64t/ia32e (Intel uses two names for unknown reasons). The arch formerly introduced as x86-64 in 1999 was renamed to amd64 in 2003. amd64 is not a superset of x86-64, it is the same arch. So it would be correct to state that em64t/ia32e is an implementation of amd64.\"
A quote from the Debian threads on amd64 arch.
-
Originally posted by neme5i5
\"So it would be correct to state that em64t/ia32e is an implementation of amd64.\"
Yes, exactly what I said.
You\'re reaching. I said nothing about the technology. Which in this case is amd64 (x86_64 as gcc calls it).
EM64T is buggy in 64bit, and AMD64 runs like dogs.
No, you definately mentioned the technology. :) But w/e, we both agree that AMD processors perform better than Intels in most cases, although not as bad as you made out. You can really only see the difference in a benchmark, and it certainaly doesn\'t crash all the time. I\'m just pointing out that you can\'t blame one bit of technology. It\'s what the rest of the processor does with that technology which effects how the processor performs overall, not how that technology performs. If Intel had a onboard memory controller and something similar or the same as hypertransport then maybe the performance would be similar in all cases.
-
Runs like dogs. You open the gate, and they scream FREE as the run around the block pissing on poles! Also I said, runs like stalions.
I said nothing about the technology. My comment was on my chips here. I like how you slip your position around to avoid admitting your statments were obviously wrong. In the future if you\'re unclear about something plz ask.
Since you seem to want to know so bad. As for the technology. ANYTHING based on any successor to the i386 (i486 i586 i686 x86 x86_64 amd64 em64t ia32e) is pure dung. I don\'t care if it has gotten 64bits.
I liked IA64 (VLIW/EPIC) before it was implimented. It\'s still got some promise if they can ever realize it. (HP\'s book is a fun read) Alphas are the best, hands down. I like POWER (power optimised with enhanced risc) as a fine grained 64bit chip. (also the PPC970) Mips isn\'t bad either. I like high powered chips, and lots of GP registers.
-
Originally posted by neme5i5
Runs like dogs.
Where I\'m from that means it runs like crap :P I wasn\'t unsure at all, we just meant complete opposites. And I was assuming we were talking about technology, as that\'s what was posted. Obviously another misunderstanding there. :)
Anyway....
IA64 - Very nice imo, although it hasn\'t really gone anywhere. Lack of native IA32 support let it down (although it can run IA32 now if I recall using a IA32 module.), and I don\'t think it will go anywhere now due to lack of general consumer need. It had its chance and didn\'t make it.
I\'m not sure about Alpha (Lack of experience there.), but PPC is a definate yes for a good processor. The best supercomputers run on PPC (See BlueGene/L). :)
As for your dislike of i386 processors... well definatly the amount of registers was a big \'bad\' for x86, but it seems to have pulled through because it was needed for program compatibility. And AFAIK, amd64 isn\'t based on i386 (correct me if I\'m wrong there), but a new design with backwards compatibility. If someone can come out with something much better which is compatible with x86(_64) which will become mainstream then go for it.
What do you think of Cray btw?
-
TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.
(1) Sadly, it\'s why I use x86 as well. (2) Yes, you\'re wrong. ...again. (3) You miss the point x86 its self is dung. Even sparc (ugh) is better. Here\'s another reason to embrace only free software. It makes mass arch migrations trivial.
I almost bought a Cray vector machine from a recycler.
-
TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.
It was designed for server or scientific useage which then would be expanded into consumer usage. Intel wanted to make it the mainstream 64-bit processor but didn\'t manage it. Read this in some court case legal document for a lawsuit between AMD and Intel.
Yes, you\'re wrong. ...again.
Wasn\'t wrong the first time. To a third party anyway....
So why is there a degrade in 32-bit performance on amd64? Surely it would perform the same or better than 64-bit if it was based around a 32-bit design?
(3) You miss the point x86 its self is dung
Maybe, but then it\'s cheap compared to alpha. The price for performance of the x86 design is much less than alpha, which keeps alpha sales down. Alpha may have a great design compared to x86, but it isn\'t practical for the general consumer environment. And it\'s practicality which matters, not how well something is designed.
-
(IA64) You\'re right, it would have gone there in time. Like IBM\'s PowerPC line.
Your always free to believe what ever you want. You chose to ignore relavent commentary all along the way that would have betrayed your chosen view. Reality is perceptual.
\"... I was assuming we were...\"
As you said to me assumptions make you look foolish.
(performance) they added registers. Big performance boost for 64bit code. (32bit design) nope. Think of any amd64 (Athlon64 Opteron) running 32bit, as a old Athlon with a die shrink, and an integrated memory controller + Hyper Transport. Depends on what market you\'re in. Consumer hardware is not well suited to scientific applications. Alphas ruled there, as does Itanic today.
-
(performance) they added registers. Big performance boost for 64bit code. (32bit design) nope. Think of any amd64 (Athlon64 Opteron) running 32bit, as a old Athlon with a die shrink, and an integrated memory controller + Hyper Transport.
hmm, but it runs 32-bit code worse than its 32-bit sempron counterpart does. The extra registers shouldn\'t account for an actual performance degrade on 32-bit code.
-
Read what I said, and what I did not.
(BTW, parting note: Allot of amd64 chips require registered RAM (even in 32bit) great for servers like mine , but bad for over all perfomance. Read with a careful eye on what metrics can influence your results. Chip model, what kind of RAM, remember PC333 was faster than PC400. People seem to have forgotten all of this when the Opteron was released)
Look it\'s been fun, really. I have even more fun arguing with a member of my team over the Pentium M. I\'m getting bored teaching you about semiconductor theory/design. I suggest you go read up on it some more.
Good luck, and have fun.
-
Originally posted by neme5i5
TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.
That\'s just marketing. It\'s not the first, nor VLIW.
It\'s a RISC processor with explicit parrallel instructions (EPIC), where as VLIW goes the opposite way of RISC. VLIW is a russian invention, and I read a quote somewhere from the russians that invented it that Intel doesn\'t understand what VLIW is. And their (the russians who invented it) processor was working before Intel even tried to copy the idea.
IA64 is just PA-RISC on stereoids. It\'s even supposed to be backwards compatible, so if you want to run HP/UX, go ahead. You might need a mainboard that HP/UX knows about though.
-
Thank you for adding to my knowledge, I didn\'t know that. Have any names, or links for me to read about it?
http://www.cs.clemson.edu/~mark/epic.html
http://www.cs.clemson.edu/~mark/architects.html
Some one should break this news to David K Every.
http://www.mackido.com/Hardware/EPICisRISC.html
-
Unfortunately I don\'t have any links.
I read the last of your links though, and as he explains, IA64 is RISC. What is missing, and what Intel apparently missed is that VLIW goes the opposite way from RISC. Well, not completely missed, because I belive they did talk about the fact that they were going the opposite way of RISC back when IA64 was still vaporware.
You have them ordered RISC - CISC - VLIW, with CISC in the middle. IA64 and PA-RISC being Risc, x64 is CISC and that russian thing is VLIW. Risc is about making the CPU simple (simple instructions are faster), CISC makes it complex (complex instructions do more work per instruction), and VLIW is supposed to be on the opposite side of CISC, but details are lacking :( Well, if even Intel don\'t understand it, how would I? :D
The explicit parralel thing is called EPIC, and there is nothing new in that. Microcode always worked something like that, even the examples given in my old Tannenbaum book from 1995 (that\'s before IA64 as far as I know). It\'s just another thing that has been moved from the chip to the compiler, making it even further out on the RISC end.
-
Oh I see where your argument is going. Scheduling is usually done in software, like the new one we got in 2.6. VLIW is moving this on the hardware.
OTOH I would still consider VLIW RISC. Let me explain why. Part of what makes CISC is the instructions are of variable length. This is really all that is left that differentiates CISC from RISC architechtures. I want to add something to your iconography first.
RISC CISC VLIW
The new processors we call RISC are in fact more complicated than CISC every will be. So let\'s say we take the good points of both RISC & CISC, and we make a modern RISC (MRISC) w/ OoO execution, superscaler, DSP, SIMD, and other like technologies. They really fly in the face of the old RISC philosophy.
Now from that we add scheduling to the chip, and we now have where VLIW was going. Can you see my argument?
-
Originally posted by neme5i5
Oh I see where your argument is going. Scheduling is usually done in software, like the new one we got in 2.6. VLIW is moving this on the hardware.
No, that\'s wrong. The EPIC (still nor VLIW, Intel doesn\'t know what VLIW is) idea is that pipelining, like in the P4, where several instructions can be executing at once (instructions of the SAME thread/process, this is not hyperthreading), is done differently. On a P4, the CPU needs all kinds of locking to prevent one instruction from using a value before the previous instruction is done computing that value. On EPIC this job is moved to the compiler, which will group instuctions together, telling the CPU \"these can be executed at the same time without problems\". Much faster, because the CPU doesn\'t have to wait for the value to be calculated, it knows that none of the other instructions executing at the same time will try to use that value.
OTOH I would still consider VLIW RISC. Let me explain why. Part of what makes CISC is the instructions are of variable length. This is really all that is left that differentiates CISC from RISC architechtures.
Some CISC architechtures have variable length instructions, but this is no requirement. The difference between RISC and CISC is microcode, a piece of code embedded inside the CPU. This code actually interprets the instruction set on CISC processors. RISC processors don\'t have microcode.
EPIC is RISC. VLIW is something different.
I want to add something to your iconography first.
RISC CISC VLIW
The new processors we call RISC are in fact more complicated than CISC every will be. So let\'s say we take the good points of both RISC & CISC, and we make a modern RISC (MRISC) w/ OoO execution, superscaler, DSP, SIMD, and other like technologies. They really fly in the face of the old RISC philosophy.
The RISC philosophy was to take out anything that can\'t be done directly in hardware, and leave it to the compiler instead of having microcode. Microcode is really just software, although etched into the CPU. Software is slow, hardware is fast. Getting rid of microcode will speed up everything that can be done by the hardware, because it doesn\'t need to be interpreted first. And leaving the rest to the compiler will not slow anything down, because it\'s still software at the same level.
-
I think you\'re confused. Not only does RISC not have microcode, neither does anybody else who makes CISC based chips. The only CISC to use microcode is from Intel. All CISC implimentations use variable length instructions. One RISC characteristic is non-variable instruction length which speeds up execution. An example of VLIW implimentation is Transmeta\'s Crusoe. (w/o the codemorphing software which is NOT microcode)
url:http://www.transmeta.com/crusoe/vliw.html
I wasn\'t talking at all about EPIC anymore. RISC as a philosophy is no longer being used. Even the POWER5 while being called RISC is more like my argument for calling it \"Modern RISC\", and in that light moving scheduling into the instruction set is the next step on that path.
I was talking about VLIW, and from what I read scheduling was put into the instuction set. (hardware) Also the whole RISC philosophy was lets use multiplication as an example. In RISC you would have no instruction for multiply, instead the programmer would need to do multiple loops of adds to achieve this result. In CISC you would just use the multiply instruction. Now \"Modern RISC\" chips have evolved so far out of this that they are adding SIMD instructions. If you follow this out even further with OoO execution, adding instruction for scheduling is not hard to imagine. Therefore VLIW is RISC, but not in the old context since not even POWER5 is RISC in the old context.
BTW scheduling != hyperthreading && hyperthreading == subset of scheduling
-
Originally posted by neme5i5
I think you\'re confused. Not only does RISC not have microcode, neither does anybody else who makes CISC based chips.
Then they wouldn\'t be CISC.
The only CISC to use microcode is from Intel. All CISC implimentations use variable length instructions.
This wouldn\'t make sense, as fixed-length would be faster, depending on how long the instrucitions need to be. but with current 32 and 64-bit CPUs, there should be bits enough to have a fixed length instruction set without having to fetch multiple words.
The only reason that x86 is variable-length is that it\'s an 4/8/16 bit design, and when you fetch only 8 bit at a time, it\'s better only to fetch the number of bytes necessary. On a 64-bit CPU this wouldn\'t make sense, no matter if it\'s RISC or CISC.
One RISC characteristic is non-variable instruction length which speeds up execution. An example of VLIW implimentation is Transmeta\'s Crusoe. (w/o the codemorphing software which is NOT microcode)
url:http://www.transmeta.com/crusoe/vliw.html
I don\'t have much knowledge about the transmeta processors, and definitely not enough to know if they understood VLIW, unlike Intel.[/QUOTE]
I wasn\'t talking at all about EPIC anymore. RISC as a philosophy is no longer being used.
Just about everything is RISC nowadays, except x86.
I was talking about VLIW, and from what I read scheduling was put into the instuction set. (hardware)
That wouldn\'t make sense at all. Switching the scheduler would imply replacing the chip then. Windows has one scheduler, which is good for some things, and sucks for others, FreeBSD has a completely different scheduler, and Linux 2.6 has several to choose from.
Also the whole RISC philosophy was lets use multiplication as an example. In RISC you would have no instruction for multiply, instead the programmer would need to do multiple loops of adds to achieve this result.
Depends on which chip you\'re talking about. I think either MIPS or Sparc had multiplication in hardware, although I don\'t remember which.
Now \"Modern RISC\" chips have evolved so far out of this that they are adding SIMD instructions. If you follow this out even further with OoO execution, adding instruction for scheduling is not hard to imagine. Therefore VLIW is RISC, but not in the old context since not even POWER5 is RISC in the old context.
You don\'t understand RISC, and I don\'t think you understand VLIW either (but since I don\'t, I can\'t really judge on that). If you do understand VLIW though, you should explain to Intel why IA64 has nothing to do with VLIW.
-
It\'s you who doesn\'t understand RISC. You understand the old concept, but not how it\'s done today. (not even sure how much of that you really know well) You also don\'t really understand CISC, and a good example of CISC is Motorola\'s 68040. (you seem to think CISC is only Intel\'s) Just saying it doesn\'t make sense isn\'t an argument.
You don\'t bring evidence to back up your claims, but I do. You should read these:
http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
http://arstechnica.com/articles/paedia/cpu/g4vsk7.ars
http://arstechnica.com/articles/paedia/cpu/crusoe.ars
BTW, I do give you this. If VLIW is using instructions to schedule execution, then it\'s in hardware as one of the first of my links has said. (written into the compiler) OTOH, if VLIWis packing (not using) instructions together for scheduled execution, then it is indeed software. You have to understand something about piplineing to make any sense of that.
-
Yeah, someone named \"Hannibal\" is an authority when it comes to chip design... If we were talking about killing people, that would make more sense, but even then I don\'t think it\'s the right Hannibal we are talking about. And \"Ars Technica\", the geek tabloid - can\'t you come up with something a little more credible, when discussing with someone who used to read Tanenbaum for fun (Structured Computer Organization, Modern Operating Systems).
And no, I don\'t think that CISC is only Intel, I have never said anything that even hints that way, as I know very well that the 68000 series are CISC. The motorola 88000 series OTOH are RISC. It seems to me that you are not really arguing with me, but with your own delusions. So, continuing the discussion makes no sense for me, you can just post both sides of your discussion yourself - then we can also see what the f*** you are arguing aginst.
-
So the man is wrong b/c you don\'t like his nick name? Hannibal has a non-media (modern), and historical significance. But all Americans seem to know is based on television.
You keep making claims of deep understanding, and learned comprehension. OTOH you can\'t demonstrate it? You resort to an Ad Hominem (go look it up) attack on just one of my sources, yet you think it invalidates everything else? Now just who is delusional?
Have you read even one of them all the way through? Don\'t say you don\'t have time, you read \"Structured Computer Organization, Modern Operating Systems\" for fun. You\'re right, this is a waste of time. I agree with you.
-
Originally posted by neme5i5
So the man is wrong b/c you don\'t like his nick name? Hannibal has a non-media (modern), and historical significance. But all Americans seem to know is based on television.
It has nothing to do with liking his nickname. Nicknames are fine when you\'re a 14 year old playing Counterstrike, but come\'on, could you imagine Tanenbaum having a book published under a nickname like that? Bill Gates? Gordon Moore? Bill Joy? When people know what they are talking about, they tend to put their name on it, and not some CS-nick.
And what does americans have to do with anything? Nothing against attacking them, but I fail to see the relevance.
-
I run PS on a 256bit processor and a MIPS/ARM connected to a dualcore PIC
<.<
-
Originally posted by Androgos
I run PS on a 256bit processor and a MIPS/ARM connected to a dualcore PIC
<.<
\\o/
-
Originally posted by Androgos
I run PS on a 256bit processor and a MIPS/ARM connected to a dualcore PIC
PIC? Would that be PIC as in PIC16c84?
/me wonders if Androgos is joking or not...
-
Originally posted by Leeloo
Originally posted by Androgos
I run PS on a 256bit processor and a MIPS/ARM connected to a dualcore PIC
PIC? Would that be PIC as in PIC16c84?
/me wonders if Androgos is joking or not...
Yes, actually it\'s a PIC16F628 (http://www.interq.or.jp/japan/se-inoue/e_pic8.htm) and running it fine.
It\'s a bit low FPS in the plaza though, but allover it\'s fine.
-
Don\'t mean to be rude, and I know I\'m not a mod/admin, but maybe you could be a bit more speficic on the architecture type?
Eg:
amd
amd64
x86
x86_64
athlon
athlon64
Etc.
-
Originally posted by Kernel
Don\'t mean to be rude, and I know I\'m not a mod/admin, but maybe you could be a bit more speficic on the architecture type?
Eg:
amd
amd64
x86
x86_64
athlon
athlon64
Etc.
Well it\'s not easy to change a poll, and there\'s not much point because I\'m assuming that people who say 32-bit are on x86 or ppc, and people who say 64-bit are on x86_64 or ppc64, so the mainstream arch. I guess there\'s a wider range, like ia64, but that won\'t ever be supported anyway.
-
I think I should change my vote from \"32 bit\" to \"64 bit\" now :]
...I\'ve just got a new Acer Aspire 5022 Laptop (AMD Turion + ATI Radeon)
-
I play on Intel 32 Bit,
not enough money to buy another station on 64 bit :).
-
AMD64 Fedora (custom K8 specific kernel)
-
64-bit mostly, now I\'ve eventually managed to build the client on it.
32-bit sometimes.