Read the Inq, Tom's, TR, or any other 'HW enthusiast site" and they often will say '' but that FSB is restricting performance blah this and blah that'' yet noone has actually done the right experiments to prove blah this and blah that.
Jack
Hey Jack, whats the TR you speak of? Past 2-3 months I've started to become obsessed with learning more about PC tech and check out hothardware, anandtech, toms, inq and 5 or so others every day to try and get something new to read and learn about. If you or any others have some favs it would be appreciated.
Thanks and sorry for the off-topic post.
Read the Inq, Tom's, TR, or any other 'HW enthusiast site" and they often will say '' but that FSB is restricting performance blah this and blah that'' yet noone has actually done the right experiments to prove blah this and blah that.
Jack
Hey Jack, whats the TR you speak of? Past 2-3 months I've started to become obsessed with learning more about PC tech and check out hothardware, anandtech, toms, inq and 5 or so others every day to try and get something new to read and learn about. If you or any others have some favs it would be appreciated.
Thanks and sorry for the off-topic post.
Some of the better one:
Tom's, AnandTech, TechReport, LostCircuits
Some good for general product evals:
Hexus.net, Hothardware, hardwarezone, trustedreviews, legitreviews
Good forums:
THGForumz, Xtremesystem.com
Technically oriented
Realworldtech.com, EETimes
Most of the HW enthusiast sites are good, the one to avoid is HardOCP, Kyle Bennet (the editor) is a diehard AMD fan.... there aren't any Diehard Intel fanbased HW enthusiast sites. Most of the HW sites are pretty fair in their reporting data and analysis, except HardOCP.
Keep up with my posting, I typically dig up technical articles that do not originate from anything you will find on any HW site... rather I try to pull in engineering/scientific technical journal info I can gleen from university servers.
I started a decent thread hear that I will add to as well:
http://forumz.tomshardware.com/hardware/modules.php?name=Forums&file=viewtopic&t=182836&highlight=process
Jack
Thanks a bunch. Ya, I keep an eye on these forums everyday, lots of very interesting topics and debates here. Wish I found these 2 months ago, haha
Yes, 680i should be forward compatible with the 1333 MHz chips -- since nVidia endorses this spec I would be more prone to get into a 680i. I am purchasing a 680i striker as soon as one becomes available ... though I do not know about Penryn. I expect Intel will give a demo of Penryn at the spring IDF in china, so keep your eyes peeled for details, they will likely get questioned on what chipset/socket it is running.
Jack
Probably pairing Penryn with X38 and DDR3-1066 memory
Are you referring to this?
http://techreport.com/onearticle.x/11064
The approach is better than current Intel and AMD approaches.
K8L will incorporate DDR-2 and DDR-3 support, but I think the die space will be wasted.
levicki
Distinguished
- Feb 5, 2006
- 269
- 0
- 18,780
Some?!?
It is ~50 instructions, if that is "some" for you then you will really have to ask your beloved AMD for more.
For those who want to know, there will be CRC32 implemented as an instruction, some new string instructions for regular expression support, dot product, and population count. Others will help code vectorization and data type conversion.
Me being a classic Intel troll will tell you that my E6300 at 2.8GHz has the performance of an Opteron 165 running at 3.4GHz. The only problem is that such Opteron still doesn't exist, let alone cost $190. If you manage to find such an Opteron I really doubt it will be air-cooled like my E6300. You can do your math now.
Umm, because Core 2 Duo wasn't around when they started writing 64-bit code?
Speaking of it, if Microsoft didn't stick to AMD for 64-bit platform, they would have to invest in some real code porting to IA64 and thus lose advantage over IBM, Sun, Oracle, in server software but we would have got way better software and platform.
AMD's weak developer support is exactly the reason why 64-bit XP and applications haven't taken off even though it has been 4 (four!) years since first AMD64 chip introduction.
Finally, AMD64 is stupid name, EM64T better describes what it is all about -- (Extended Memory technology) and it doesn't include vendor name in it. Btw, those are not 64-bit instructions but extensions. Just like 32-bit was an extension of 16-bit in the past. I am still pissed off because AMD got the laurels for that quick hack and for breathing back life into a dead horse (x86) as well as helping Microsoft keep its software monopoly.
MU_Engineer
Splendid
- Feb 18, 2006
- 3,868
- 4
- 23,165
levicki
Distinguished
- Feb 5, 2006
- 269
- 0
- 18,780
I agree with that.
I agree with that too. I only fear that AMD didn't do us a favor. They acted short-sightedly -- they only had in mind short-term profit from siding with Microsoft. And it is short-term in case you wonder, because Intel now has comparable 64-bit offer so AMD has lost its exclusiveness, not to mention that 64-bit OS still hasn't taken off so one really has to wonder how much their pockets are fuller now because of what they did.
It was working mostly in emulation mode which was slow. Microsoft never did any real porting except for Alpha. Now that I mention it, I remember that I heard from Microsoft MSVC compiler developer that their and AMD's plans for AMD64 go as far back as year 2000. That seems to coincide with Alpha support being dropped in Windows 2000 Beta 3.
Oh yes it has. Has AMD been more capable, 64-bit OS would've been released sooner. If AMD offered a 64-bit compiler developers would have tried to port their code and realized the potential benefits sooner.
It was only when Intel high volume manufacturing machinery started pushing EM64T capable Celerons into masses that the popularity and awareness of 64-bitness started to grow.
Please, do not mix things. I do not dispute term AMD64 as an architecture name (although I believe that the architecture name is K8 or Hammer).
I only say that 64-bit instruction set extensions should not be called AMD64 just like SSE2 is not called IntelSSE2.
AMD calls it "long mode" in their docs. Because of that non-imaginative and non-descriptive term, developers coined AMD64 and x86_64. I must agree that x86_64 is better.
However, all the names are fundamentally wrong because you neither have radically new architecture (it is still x86 under the hood) nor you really have 64-bit address space (physical or virtual).
I disagree with the "elegant" part. Adding yet another instruction prefix (0x48 or REX) means a penalty for instruction decoding because instruction lengths change.
Result of that as well as of the bigger footprint of the immediate operands is that 64-bit code can run several percent slower than the exactly same 32-bit code under 64-bit OS. That is absurd because you are actually penalized for making native 64-bit applications.
Note that I am speaking about ports of already highly-optimized code, any other (sloppy) code ported to 64-bit will automatically benefit through the (obligatory) use of SSE2 instead of legacy FPU so the penalty would in most cases be covered.
However, those who still write critical parts of their code in assembler like I sometimes do, will have a hard time to match 32-bit performance in 64-bit code.
I tried very hard and the best I could manage was only 6.5% slower code. Intel compiler's 64-bit code (and I am talking about the same thing I wrote in assembler) lags 8.3% behind 32-bit one.
On the other hand, MSVC gains 9.5% in 64-bit code .vs. 32-bit code because it doesn't use legacy instruction mix anymore, but it is still 4.33x slower than my assembler code and 3.96x slower than the code generated by Intel compiler.
It is not just about the OS. It is about applications such as Office and server software such as IIS, ISA, MSSQL, Exchange, etc. Not having to port all that but instead just recompiling it is a great advantage over other vendors. Having to spend much more time and money to make and test a proper port would create oportunity for others to jump in.
I believe that CPU architecture is for example Netburst .vs. Core, or K7 .vs. K8 but not 32 .vs. 64. It is true that in AMD's case 32->64 coincides with architecture change (K7->K8) but that doesn't mean that x86_64 is a new architecture.
Furthermore, as I already said it really isn't that different. It even doesn't have any new instructions. Just wider registers, more of them (crippled by poorly thought out ABI if I may add) and more physical and virtual memory available. Nothing else has changed.
Some?!?
It is ~50 instructions, if that is "some" for you then you will really have to ask your beloved AMD for more.
For those who want to know, there will be CRC32 implemented as an instruction, some new string instructions for regular expression support, dot product, and population count. Others will help code vectorization and data type conversion.
Me being a classic Intel troll will tell you that my E6300 at 2.8GHz has the performance of an Opteron 165 running at 3.4GHz. The only problem is that such Opteron still doesn't exist, let alone cost $190. If you manage to find such an Opteron I really doubt it will be air-cooled like my E6300. You can do your math now.
Umm, because Core 2 Duo wasn't around when they started writing 64-bit code?
Speaking of it, if Microsoft didn't stick to AMD for 64-bit platform, they would have to invest in some real code porting to IA64 and thus lose advantage over IBM, Sun, Oracle, in server software but we would have got way better software and platform.
AMD's weak developer support is exactly the reason why 64-bit XP and applications haven't taken off even though it has been 4 (four!) years since first AMD64 chip introduction.
Finally, AMD64 is stupid name, EM64T better describes what it is all about -- (Extended Memory technology) and it doesn't include vendor name in it. Btw, those are not 64-bit instructions but extensions. Just like 32-bit was an extension of 16-bit in the past. I am still pissed off because AMD got the laurels for that quick hack and for breathing back life into a dead horse (x86) as well as helping Microsoft keep its software monopoly.
This is essentially aimed at your last bit - calling AMD's 64-bit implementation (and it's name) "stupid" is a little off. Blaming the lack of developer support in the consumer market for 64-bit on AMD (or Intel, for that matter) is silly. AMD64 was developed for servers, where 64-bit apps are far more prevalent, then ported over to desktops. I must agree that x86_64 is a far more accurate and apt name.
I also must say stop bashing AMD for foresight and technical achievement in their execution and delivery of 64-bit extensions ahead of Intel in the x86 market. 64-bit processors from AMD or Intel are still a bit ahead of their time and probably won't hit their stride until late this year or early next year (I'm not calling any processors gimped, because let's face it, the X6800 or QX6700 are far from being held back at current 32-bit uses).
Also, AMD's 64-bit extensions are more efficient than Intel's. Microsoft choosing their model rather than others was both cheaper, simpler, and better than taking in others, as said. Again as someone said, Intel hadn't brought their EM64T to market yet.
XP64 isn't nearly as bad as people are saying. The driver support wasn't there initially, without question, but from everything I've heard it has much better support now. If I were building a new computer I would probably choose it over 32-bit (boo Vista).
Just my 2 cents.
MU_Engineer
Splendid
- Feb 18, 2006
- 3,868
- 4
- 23,165
pausert20
Distinguished
- Jun 28, 2006
- 577
- 0
- 18,980
1333MHz FSB Conroes are not far away.
But for 45nm processors, I don't know if a new VRM will be needed.
QC, It looks like there will be a new VRM needed for the Wolfdale processors. I found out that there is a VRM/VID rework that can be done to allow the Bad Axe2 to run the new Wolfdale processors.
This means that the Bearlake chipset will have a new VRM to support the 45nm processors
levicki
Distinguished
- Feb 5, 2006
- 269
- 0
- 18,780
Next time if you bother to reply please read more carefully. Thank you.
Note how I said "AMD64 is stupid name ..." meaning "stupid name for 64-bit extensions". I believe I explained my reasoning behind it well enough.
Also note how I haven't said that AMD's 64-bit implementation itself is stupid, although as a developer I personally dislike the way x86_64 has been made in general.
Why would that be silly? No matter how excellent a piece of hardware is, without good software, support and documentation it is just an expensive brick. Just look at Ageia. They were selling their SDK at first, and it wasn't cheap, now it is free. Why? Because hardware needs software to survive.
Not only ahead of Intel -- ahead of time. I am bashing them for two reasons:
1. They extended ill-founded x86 YET AGAIN instead of letting it die.
2. They delivered extensions without compiler which can utilize them. I will not discuss Linux and server space but under Windows we got 64-bit capable compiler in 2005 with Visual Studio Whidbey if you don't count DDK compiler which was available a bit earlier. Isn't 2 (two) years a bit too long to wait for a compiler?
I am also bashing both AMD and Microsoft for:
1. ABI design -- you have 16 GPRs but you still have restrictions how many you can use (you still use stack for more than four parameters) and you better avoid higher numbered ones (8-15) because you will then have one byte longer instructions which slows down decoding.
And just Microsoft for:
1. Lack of inline assembler support. It is true that the code requires heavy changing in order to work again but it is easier than having to make separate .asm file.
That was the case with Prescott. Core 2 Duo is equally efficient.
I know, I am using it. Here are just the few issues I am aware of:
1. If you have GeForce 7 VIVO card you can kiss goodbye your Video In because capture drivers have never been released for 64-bit OS by NVIDIA.
2. Creative sound card drivers have some new bugs, some of them ironically preventing you from using more than 4GB or RAM in combination with their sound cards.
3. 8800GTX was launched on November 8th. Drivers for x64 were published on December 8th. What would you do with such an expensive product in the meantime? Use it in VGA mode?
4. Force feedback wheel? Check if you have drivers first. When some Logitech wheels don't have them, I won't even mention noname vendors.
5. Scanners and printers. Many of them lack drivers.
6. USB ADSL modem? No problem as long as it is Thomson (Alcatel) SpeedTouch™ 330 because that is about the only one I know which has 64-bit drivers.
I could go on with some more details if you want, but I am a bit tired right now.
I am beginning to notice a pattern here. Every time AMD does something and it doesn't go all too well, everyone defends them by saying "but it was faster and easier to do it that way".
Never mind that doing it the hard way would be better in the long term, it is dead obvious that short term earnings beat the crap out of everything else. Quantity instead of quality, I heard of it.
I only tried to compile kernel with icc once and it worked. Certain patches were required but it is not impossible thing to do and it does improve performance. gcc has improved for x86 a lot in version 4.0 but neither gcc nor MSVC have automatic vectorization and so many high-level optimizations as icc.
I agree that it is not suitable for every task but in my opinion CPU vendor must have its own compiler or otherwise I don't consider them as serious player. There are two things to consider:
1. Who else will know how to write the best performing code if not those who designed the damn chip?
2. What if Microsoft goes down the drain? I know that is not very likely to happen but it is not good to depend on someone else for such an essential feature.
If I don't count Z80 and Motorola 68000, I am active developer since Pentium 90 days, I remember "birth" of MMX and SSE. I have read all the official Intel documentation, programming guides and application notes and I have never seen the little "i" you mention. It is an invention of SiSoftware and adopted by Lavalys and the others. I claim the "i" never existed. I would really like someone to prove otherwise but not by showing screenshots from Sandra.
Regarding the address space, 32-bit chips are actually 36-bit but still can't address more than 4GB of RAM without windowing. 64-bit ones have 48-bit virtual address space and 40-bit physical address space. Note the difference -- 32-bit have 4 bits more, 64-bit have 16/24 bits less.
They only have 64-bit wide general purpose registers and 64-bit wide data path and that data path is something even 32-bit Pentiums had years ago.
Sure, but as I said they don't help much either. Best performance is still with the lower eight of both GPR and XMM registers because you don't need a prefix byte to use them. There were already very effective mechanisms such as hardware register renaming which countered the need for more registers being exposed to compiler.
To be honest, I would really prefer clean new 64-bit ISA which performs better than x86_64 because I have to rewrite/port most of the code anyway just in order to bring the 64-bit code performance back to the approximate level of the 32-bit code performance.
Compile this code using icc 9.1.033 and -O3 -QxT switches and with gcc of your choice (you will probably have to change align directive syntax, this one is from Windows world). If you don't have Core 2 Duo to run the executable on, just try to compile it anyway, it should get vectorized. Try to compare generated code just for fun.
[code:1:2e80b3fa24]
__declspec(align(16)) float src[1024], dst[1024];
for(i = 2; i < 1024 - 2; i++) {
dst = src[i - 2] - src[i - 1] - src[i + 2];
}
[/code:1:2e80b3fa24]
I just can't wait for those SSE4 instructions to become available.
EDIT:
People all over the www are speculating as to what the new SSE4 instructions will be. I am surprised because I already knew all about them for quite some time.
New Instructions
MU_Engineer
Splendid
- Feb 18, 2006
- 3,868
- 4
- 23,165
I've used icc on certain projects and I did notice that it did vectorize code automatically with the right switches enabled. Let's see, I think it was -O3 -xB for my P4 Woody and simply -fast and something with "threads" for the dual Xeon Irwindale box that was really the target of the code. It does make a good difference with the right code, I won't lie. icc can do excellent work in some cases but it is kind of hampered by not being the default toolchain compiler for much of anything. I'd think that Intel would do themselves a favor by giving "the good stuff" that's in icc to the FSF so that -march=<some-intel-chip> and the right gcc switches will accomplish the same as the stuff in icc. That would lead to the same result- code that runs excellently on Intel CPUs- but with the added benefits of being able to have this advantage used more widely and regularly. That would only make Intel look better IMHO and I don't see what the downside is, besides not being able to sell developers compilers that are of limited use.
levicki
Distinguished
- Feb 5, 2006
- 269
- 0
- 18,780
Your idea is interesting, but I believe that the problem lies somewhere else. To be able to optimize so efficiently, icc probably does completely different analysis of the code (and especially the data flow) than the gcc.
Most likely the changes required to merge gcc with icc optimizations would break the gcc in much the same way you find icc broken now for certain tasks. It is completely different philosophy behind those two compiler engines. One is pragmatic, the other is opportunistic.
There is a document order #248966 available free of charge (both on a CD and as a download) called "Intel 64 and IA-32 Architectures Optimization Reference Manual" currently at revision 14. gcc developers should spend more time reading that document because it defines set of optimization rules for compiler writers all neatly classified by impact and generality. I am sure that they could match icc performance if they try following those rules.
MU_Engineer
Splendid
- Feb 18, 2006
- 3,868
- 4
- 23,165
TRENDING THREADS
-
News Windows 11 will reportedly display a watermark if your PC does not support AI requirements- Started by Admin
- Replies: 21
-
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 3K
-
Facebook
Twitter
Instagram