Heh.... I guess you haven't seen how many laws there are on the books... and that's not even considering the ones that would probably be considered "unimportant". I don't think they could be reviewed in 10 years' time.
Which is the host depends on what you want to do. If you want to run guests as servers, you can run on either host but probably Linux is best. If you develop or are using it at home, it depends on what you want to use your machine for most. For example, if you are using it at home and you also like to play the most popular games a lot, then you'll probably want Windows to be the host as you can play your games with full graphics acceleration.
I've run VMWare and it works well under Windows 2000 and Windows XP (can't say about Windows 2k3). The only issues are to have tons of RAM and a fast HDD. Having multiple cores (whether multi-core CPUs or multiple CPUs) is a nice boost as well.
I tried to write some non-trivial Java code about three months ago after not programming in Java for a few years. I started out just using vim and my own makefile thinking that it shouldn't be so hard. It was a *mess*. I spent days just dorking with the environment variables to try to get the thing to compile. Once I got it to compile, it wouldn't run. Dorking around more got it to run, but I then couldn't compile anymore. I gave up and fired up Eclipse and let it handle all that crap for me so I could get down to business doing what I needed to do in the first place... writing the damn app itself.
And I wouldn't have had a problem if the article had said "we're running the type of 32-bit applications that most people use". Rather it ran 32-bit versions of some of the very applications that could benefit from larger integer sizes without commenting on the fact that their choice of OS had forced the AMD processors to run in 32-bit mode.
Which ones are you talking about, specifically, and which also offer 64b versions of the application? It's most definitely not a good test if you use AppX which is 32b on the 32b machine and AppY which, even if it does the same thing, is a different application, is a 64b app run on the 64b machine.
a) The Core Duo part has been shipping for a while. Why compare it to something that isn't shipping? I think when the AM2 parts actually ship, we'll see plenty of reviews comparing them. 2) AM2 previews have already shown that AM2 isn't all that great. Under specific applications (memory intensive ones), you will probably see a little speedup... 5% is common with 20% at the extreme. In "regular" usage, you'll probably see less than 10% most/all of the time. D) AM2 seems to be really readying the AMD platform for quad core maybe. The upgrade from S754 (single channel) to S939 (dual channel memory... 2x the bandwidth of S754) showed negligible performance increase most of the time... in fact, the performance increase characteristics were *very* similar in profile to the S939 to AM2 transition. So, AMD doubled the bandwidth *again* on a processor that showed little improvement over doubling it previously... AM2 must be the precursor to something else... given what AMD has allowed us to see, it must be quad core (doubling the cores).
In other words, AM2 is not exciting at all. It's practically a lateral upgrade if anything *today*. In fact, the processor ratings are identical for clockspeed/cache size of AM2 compared to the S939 counterparts. AMD itself is telling you that AM2 isn't a big deal. At least AMD tried to maintain the illusion of the S939 upgrade from S754 as being a speed improvement (processors at the same clockspeed/cache sizes had a slightly higher rating on S939 than their S754 counterparts).
Yeah, for crypto I can see it. Still... the x86-64 64b mode isn't as nice as others. There are plenty of ways to see it not make a difference or even slow you down, extra registers and all. Anything you compile that is non-trivial most likely uses the extra GPRs but also makes use of pointers. Some use pointers more than others (Java, C#, Perl, etc.). All those 84 shared objects in KDE/Gnome yup, more than a few pointers. More pointers means more pressure on your L1/L2 caches. In the libraries/apps that I've tested (all written in C), most often I see speed increases in the range of 5%. The next most common are less than 10%. Very rarely (all computationally intensive) I see more than 5%, sometimes a good deal higher (something simple like multiply two 64b integer vectors, for example) you can see fairly good improvements. To be honest, in my testing I haven't seen any slowdowns in these libraries/code but they aren't particularly pointer heavy. Some architectures support 32b memory with simultaneous 64b arithmetic (PowerPC, MIPS, etc.) and that is sometimes the best of both worlds, but then again, those typically have the entire registerfile exposed in all modes (unlike x86-64).
I agree with you... about time Intel had an answer (more competition is good for us... prices drop, faster CPUs, etc.)
However, by far and away the most FPU intensive applications run by "normal" people is games... and there were a number of game benchmarks included in that review. If you're into HPC or wasting time^w^w Distributed Computing, which will use even more FPU, then AMD is still your machine... at least until Core2 comes out, and the K8L...
OMG... if the test was 64-bit vs. 32-bit everyone would be crying about an unfair test. What would be funny is when the 64-bit application was slower than the 32-bit one:) You aren't guaranteed that the 64-bit application is faster than the 32-bit compiled one. There are a number of situations where your 64b will be slower than the 32b. The x86-64 ISA isn't as nice as others. Other platforms you can use 32b addressing with 64b arithmetic which is the best of both worlds for some applications. With x86-64, you have to pay the full admission fee (large pointers, for example) which may actually slow you down (lots of pointers will almost 1/2 your cache... since languages like Java and C# make very heavy use of pointers, you can easily get into trouble with those).
Nah, just wait a few months for Conroe (Core2). Stock speeds will beat AMD's top of the line at stock speeds then.:)
However, it is fairly impressive, even if you aren't. A laptop chip at stock speeds competing with high-end desktop chips at only a fraction of the power... Basically the Core Duo competes clock-for-clock with equivalently clocked AMD chips at 1/3 of the power. That's pretty nice.
Do you actually do anything that *requires* or really makes use of 64-bit? or do you have it just to say you have it? I run 64-bit Linux as well (not deluded enough to run Gentoo, though) but, to be honest, I only run it to compile under 64-bit as well as 32-bit to make sure my stuff runs in both modes without any issue.
Why is XP Pro required to be equivalent to OSX? Every time I've ever asked this to a Mac fan I get some canned type answer of "there are posts about it, somewhere". I've never seen a definitive argument of why, other than the obvious "to raise the price for the comparison" and I really am interested in why. Are there a list of abilities that OSX has that are *needed* by a consumer that Windows XP Home does not have? I'm not talking about something that's useful in a corporate setting that the average home user would never care about (domains and domain priviledges, for instance).
Also, the arguments about iLife and iSight are somewhat questionable to me. I've never seen any arguments as to why this is such a big deal. If I'm not using OSX right now and if you can't get that type of software on Windows, then why exactly would I need it if I'm not missing it now? Other than being an example of a bunch of bundled applications (that Windows can't bundle for cries of "Monopoly!!!") that OSX has, it really has zero weight with me. Convince me that I need iLife or iSight or whatever and my current life is incomplete without it. Otherwise, it isn't a selling point and who cares if it is a comparison point other than some artificial benchmark to attempt to sooth the ego for buying an Apple product.
I'd really like answers to the above but every time I post the questions, either I'm assumed to be a troll or I'm given very vague answers "someone out there somewhere once told my cousin's uncle's friend that this was the case so it must be true!".
It's very true... would you buy (or accept anything) from someone who treated you like shit and a moron openly to your face and insulted you every time you had a question? or from someone who was being nice and blew sunshine up your butt even if they were overcharging you?
If I had someone who, every time I had a question and asked them, insulted me and called me a moron and/or idiot for asking "such a stupid" question, no matter the question, it wouldn't take long for me to do everything possible for me NOT to deal with that person. Attitudes like that bleed over into anything that person advocated as well.
The problems of Linux have been enumerated many times. Instead of saying "you know, you're right, we can do this multiple ways and we'll work on it", the stereotypical conversation on a Linux forum is "you're an idiot, do it this way and you don't need any other way to do it and if you can't get it to work, then you're just an idiot and can't be helped" (except usually "you're" is spelled "your" or "ur"). Most people will not want to deal with a community that acts like that.
Of course, getting large numbers of kids to use non-Windows systems at school isn't going to happen while MS is allowed to continue pretending to be the "good citizen" and give cheap/free handouts to schools and students - how can a school justify replacing a chunk of their Windows network with Linux systems (and paying to retrain some of the staff) if MS is providing everything to them at knock-down prices anyway?
There are so many things wrong with these statement that you surely wrote them as sarcasm.
I thought RoleMaster/SpaceMaster were the most fun systems to play (only in small groups... a GM and 3 players, 5 at the extreme). WoTC just tried to make a simplified form of RM and named it the new D&D. I've tried the new system and it just seems like a watered down RM. Of course, with RM you pick/choose the skills and stuff you wanted, otherwise you'd end up practically having the butt-wiping skill (which you could fumble!) but when you got the subset of skills to cover the depth you wanted, it was fun. There's nothing like getting really lucky and stabbing that bad guy through the eye, killing him instantly!
No... not if the parenthesis were needed to enforce a particular evaluation order (as opposed to the operator precedence order) of a comparison, for example, or a mathmatical function. It wouldn't be a syntax error then... it'd be a logical error.
Yup... It has always been thus. The difference is that the high-end processors do exotic things and then Intel/AMD suck it in when it is ready for commoditization. The x86 has *always* been behind in those types of technologies (but usually pretty far ahead in tricks to make the x86 ISA fast) because those technologies are high-end. Eventually, it all trickles down to commoditization and then we get it in x86s.
Granted, but it is VERY easy to do, and it is the first thing you do when you are behind and are willing to trade profit for getting a faster product out the door
It is easy to do from a CADD standpoint, yes. However, it doesn't come without its own issues... for example the biggest one is a hit on latency. Larger caches tend to be slower (for a number of reasons). You have to be willing to pay the price(s) to grow the cache(s). Perhaps it isn't a big deal to the K8 core to take another clock cycle hit on the L2. However, AMD's cache architecture (exclusive L1/L2) is a little more complicated in the first place but yields a larger effective cache size (the size is L1 + L2 where the more 'normal' L1/L2 design - inclusive - isn't).
I'm not sure the 'noise' about Conroe is entirely marketing. The previews done by a number of sites, even though they were orchestrated/presented by Intel, were fairly believable. 20% speedup is fairly large since we haven't seen that large of a jump in years (if you look at those previews, 20% was the average, there were some near 0% in there but there were also some near 50%).
Fine, and I can show you an article that says the 65nm Athlons will clock 40% faster,
If you do, I'll show you a site that you shouldn't be reading anymore as it is worthless.
anyone can add cache
And yet not everyone does...:rolleyes:
Why don't we wait 6 months and then start trash talking, when we have actual products.
By all accounts, it will be sooner than 6 months.
- AMD may have some cards to play yet, but it isn't very vocal about them, which is contrary to what it's done in the past when it had something new.
- AM2 is either slower or marginally (usually within stastical noise) faster than the current S939 parts - and only when you use expensive high end DDR2-800 memory, we've already seen those benchmarks from numerous sites.
- K8L is targeting FPU performance for some unknown reason, presumably to duke it out with Itanium which has a tiny share of the market - the HPC centers.
- Conroe is targeting integer performance which is the mainstay of the vast majority of applications and Woodcrest is the server version of that where integer again rules the roost for the vast majority of applications/services (web server, database server, just about any other service you want to talk about, java/.NET languages, etc.).
- Rumors are that within a year (maybe a little longer but in that time frame) AM2 will be replaced with AM3 which is for DDR3. Any CPU you purchase for AM2 will not work with AM3 just like S939 doesn't work with AM2. The joys of the IMC... upgrade the memory type and you have to buy a new CPU. Until AMD clarifies this (which it won't because it would be disasterous for AM2 if there will be an AM3 soon), there is certainly good reason to NOT buy AM2.
This all adds up to my not purchasing any new hardware until Conroe comes out. I imagine many others are like me. While this is pretty much "not good" for Intel or AMD, it's going to mean that AM2 is a flop from the start as only fanbois will buy into that technology path blindly (and given the questions about AM2, there are certainly some big blind spots). This is coming from someone who has four Athlon64s and three AthlonXPs sitting in my computer room. I'm not a fanboi. I buy what is the best for the money when I buy. Right now, I'm thinking that's going to be Conroe (and I imagine there are plenty of folks like me).
Code = programming in general Code = one application or one logical part of an application Codes = multiple applications or multiple logical parts of an application
Code is code is code when you are talking about programming in general. All of us are programmers and we write code.
"Code" can refer to a specific entity. Sometimes you'll hear it as "codebase" or "source" or "sourcebase". An example of a specific set of code is the Linux kernel. Another example of a specific set of code is Firefox.
Codes refers to multiple sets of specific entities. If I install all the source for my Linux distribution, I have many sets of code on my machine. I have the codes for the kernel, Firefox, and whatever else.
In the parallel community, your "appliction" may consist of multiple, seperate yet dependent, executables that must all be run together to make up the single job. So, you have multiple sets of code that make the application... thus... multiple codes.
Example: John, check out the atmospheric code (refering to the source of a single executable) to make sure it's using the correct algorithms. David, check out the ocean code (again, the source of a single executable) to make sure it's using the correct algorithm. Ok, now let's run these codes (talking about both executables) together to form an ocean/atmospheric model.
No, asynchronous circuits (and processors) have existed and were commercial products in the past. This is just another turn of the wheel (just like a central computer with terminals was the common mode once before and now the terminals are just web browsers connecting to web servers now). More recently, a number of processors had subunits that were asynchronous (IIRC, at least one of the PA-RISC variants had an asynchronous divider). Asynchronous is nothing new.
As a side note, asynchronous doesn't come for free. Synchronous designs have a clock circuit (driver and network) that runs all over the chip. Asynchronous designs don't have this but they do have a lot of handshaking logic all over the place.
Yup... The couple times I've bought a car I "dressed down" quite a bit. Torn up jeans and an old t-shirt. At one dealership, I had set my budget and started looking around. The sales guy came over and kept pointing me towards low end vehicles that, I guess, he thought were in my price range. I wanted something a little higher end. Eventually, I got annoyed at the guy because he kept trying to pull me away from what I wanted to look at so I told him what I did for a living. He immediately did a 180 degree change and then started constantly pointing me to vehicles that were above what I wanted to spend, even after I told him what I wanted to spend. Eventually, I got annoyed at him and told him that if he couldn't point me to vehicles near my budget even after I requested him to do so, that I wouldn't buy a vehicle from the dealership and I left.
Almost everything you call into question was covered by the second link (the follow-on to the preview). With respect to the timings you mentioned... the DDR2-667 @ 444 should be slower than the DDR400 @ 222/1T in latency and bandwidth. Even then, it isn't a big deal. For example, if you've seen the latest AMD AM2 review from HKEPC (using DDR2-800 at "good" timings for AM2 compared to current S939 with DDR400 at good timings), the current S939 parts with DDR400 win 1/2 the time. The largest gain of AM2 over S939 was in the Science Mark 2 Streams benchmark when it got about 26% gain. Almost all other gains were less than 5% and some were even negative (meaning S939 was faster). Basically, DDR2-667 should be slower than DDR400 for the most part because of latency and it would have only marginal bandwidth increases (surely a bit less than 26%).
This was some of the biggest news in a while and it all happened about 1.5 weeks ago (where were you?:P)... Here are some from Anandtech.
This one is the preliminary benchmark testing that a lot of folks questioned and this one is the follow up that answered a lot of the concerns about the first one. The conclusion was the same, though... at 2.66GHz Conroe beats an overclocked 2.8GHz FX-60 (overclocked to simulate the upcoming FX-62) quite handily (20%+ most of the time) while using 1/2 the power of the AMD part (and obviously at a lower clock speed). There were a few other sites that had similar previews but they all say the same thing.
Slashdot Mirror
"May allow for legal...."... W...T...F...
How about just not making it illegal in the first place?
Heh.... I guess you haven't seen how many laws there are on the books... and that's not even considering the ones that would probably be considered "unimportant". I don't think they could be reviewed in 10 years' time.
Wouldn't that be "surfaced" their submarine? ;)
Which is the host depends on what you want to do. If you want to run guests as servers, you can run on either host but probably Linux is best. If you develop or are using it at home, it depends on what you want to use your machine for most. For example, if you are using it at home and you also like to play the most popular games a lot, then you'll probably want Windows to be the host as you can play your games with full graphics acceleration.
I've run VMWare and it works well under Windows 2000 and Windows XP (can't say about Windows 2k3). The only issues are to have tons of RAM and a fast HDD. Having multiple cores (whether multi-core CPUs or multiple CPUs) is a nice boost as well.
I tried to write some non-trivial Java code about three months ago after not programming in Java for a few years. I started out just using vim and my own makefile thinking that it shouldn't be so hard. It was a *mess*. I spent days just dorking with the environment variables to try to get the thing to compile. Once I got it to compile, it wouldn't run. Dorking around more got it to run, but I then couldn't compile anymore. I gave up and fired up Eclipse and let it handle all that crap for me so I could get down to business doing what I needed to do in the first place... writing the damn app itself.
And I wouldn't have had a problem if the article had said "we're running the type of 32-bit applications that most people use". Rather it ran 32-bit versions of some of the very applications that could benefit from larger integer sizes without commenting on the fact that their choice of OS had forced the AMD processors to run in 32-bit mode.
Which ones are you talking about, specifically, and which also offer 64b versions of the application? It's most definitely not a good test if you use AppX which is 32b on the 32b machine and AppY which, even if it does the same thing, is a different application, is a 64b app run on the 64b machine.
a) The Core Duo part has been shipping for a while. Why compare it to something that isn't shipping? I think when the AM2 parts actually ship, we'll see plenty of reviews comparing them.
2) AM2 previews have already shown that AM2 isn't all that great. Under specific applications (memory intensive ones), you will probably see a little speedup... 5% is common with 20% at the extreme. In "regular" usage, you'll probably see less than 10% most/all of the time.
D) AM2 seems to be really readying the AMD platform for quad core maybe. The upgrade from S754 (single channel) to S939 (dual channel memory... 2x the bandwidth of S754) showed negligible performance increase most of the time... in fact, the performance increase characteristics were *very* similar in profile to the S939 to AM2 transition. So, AMD doubled the bandwidth *again* on a processor that showed little improvement over doubling it previously... AM2 must be the precursor to something else... given what AMD has allowed us to see, it must be quad core (doubling the cores).
In other words, AM2 is not exciting at all. It's practically a lateral upgrade if anything *today*. In fact, the processor ratings are identical for clockspeed/cache size of AM2 compared to the S939 counterparts. AMD itself is telling you that AM2 isn't a big deal. At least AMD tried to maintain the illusion of the S939 upgrade from S754 as being a speed improvement (processors at the same clockspeed/cache sizes had a slightly higher rating on S939 than their S754 counterparts).
Yeah, for crypto I can see it. Still... the x86-64 64b mode isn't as nice as others. There are plenty of ways to see it not make a difference or even slow you down, extra registers and all. Anything you compile that is non-trivial most likely uses the extra GPRs but also makes use of pointers. Some use pointers more than others (Java, C#, Perl, etc.). All those 84 shared objects in KDE/Gnome yup, more than a few pointers. More pointers means more pressure on your L1/L2 caches. In the libraries/apps that I've tested (all written in C), most often I see speed increases in the range of 5%. The next most common are less than 10%. Very rarely (all computationally intensive) I see more than 5%, sometimes a good deal higher (something simple like multiply two 64b integer vectors, for example) you can see fairly good improvements. To be honest, in my testing I haven't seen any slowdowns in these libraries/code but they aren't particularly pointer heavy. Some architectures support 32b memory with simultaneous 64b arithmetic (PowerPC, MIPS, etc.) and that is sometimes the best of both worlds, but then again, those typically have the entire registerfile exposed in all modes (unlike x86-64).
I agree with you... about time Intel had an answer (more competition is good for us... prices drop, faster CPUs, etc.)
However, by far and away the most FPU intensive applications run by "normal" people is games... and there were a number of game benchmarks included in that review. If you're into HPC or wasting time^w^w Distributed Computing, which will use even more FPU, then AMD is still your machine... at least until Core2 comes out, and the K8L...
OMG... if the test was 64-bit vs. 32-bit everyone would be crying about an unfair test. What would be funny is when the 64-bit application was slower than the 32-bit one :) You aren't guaranteed that the 64-bit application is faster than the 32-bit compiled one. There are a number of situations where your 64b will be slower than the 32b. The x86-64 ISA isn't as nice as others. Other platforms you can use 32b addressing with 64b arithmetic which is the best of both worlds for some applications. With x86-64, you have to pay the full admission fee (large pointers, for example) which may actually slow you down (lots of pointers will almost 1/2 your cache... since languages like Java and C# make very heavy use of pointers, you can easily get into trouble with those).
Nah, just wait a few months for Conroe (Core2). Stock speeds will beat AMD's top of the line at stock speeds then. :)
However, it is fairly impressive, even if you aren't. A laptop chip at stock speeds competing with high-end desktop chips at only a fraction of the power... Basically the Core Duo competes clock-for-clock with equivalently clocked AMD chips at 1/3 of the power. That's pretty nice.
Core2 will be even better.
Do you actually do anything that *requires* or really makes use of 64-bit? or do you have it just to say you have it? I run 64-bit Linux as well (not deluded enough to run Gentoo, though) but, to be honest, I only run it to compile under 64-bit as well as 32-bit to make sure my stuff runs in both modes without any issue.
Why is XP Pro required to be equivalent to OSX? Every time I've ever asked this to a Mac fan I get some canned type answer of "there are posts about it, somewhere". I've never seen a definitive argument of why, other than the obvious "to raise the price for the comparison" and I really am interested in why. Are there a list of abilities that OSX has that are *needed* by a consumer that Windows XP Home does not have? I'm not talking about something that's useful in a corporate setting that the average home user would never care about (domains and domain priviledges, for instance).
Also, the arguments about iLife and iSight are somewhat questionable to me. I've never seen any arguments as to why this is such a big deal. If I'm not using OSX right now and if you can't get that type of software on Windows, then why exactly would I need it if I'm not missing it now? Other than being an example of a bunch of bundled applications (that Windows can't bundle for cries of "Monopoly!!!") that OSX has, it really has zero weight with me. Convince me that I need iLife or iSight or whatever and my current life is incomplete without it. Otherwise, it isn't a selling point and who cares if it is a comparison point other than some artificial benchmark to attempt to sooth the ego for buying an Apple product.
I'd really like answers to the above but every time I post the questions, either I'm assumed to be a troll or I'm given very vague answers "someone out there somewhere once told my cousin's uncle's friend that this was the case so it must be true!".
I'd give you mod points if I had them.
It's very true... would you buy (or accept anything) from someone who treated you like shit and a moron openly to your face and insulted you every time you had a question? or from someone who was being nice and blew sunshine up your butt even if they were overcharging you?
If I had someone who, every time I had a question and asked them, insulted me and called me a moron and/or idiot for asking "such a stupid" question, no matter the question, it wouldn't take long for me to do everything possible for me NOT to deal with that person. Attitudes like that bleed over into anything that person advocated as well.
The problems of Linux have been enumerated many times. Instead of saying "you know, you're right, we can do this multiple ways and we'll work on it", the stereotypical conversation on a Linux forum is "you're an idiot, do it this way and you don't need any other way to do it and if you can't get it to work, then you're just an idiot and can't be helped" (except usually "you're" is spelled "your" or "ur"). Most people will not want to deal with a community that acts like that.
Of course, getting large numbers of kids to use non-Windows systems at school isn't going to happen while MS is allowed to continue pretending to be the "good citizen" and give cheap/free handouts to schools and students - how can a school justify replacing a chunk of their Windows network with Linux systems (and paying to retrain some of the staff) if MS is providing everything to them at knock-down prices anyway?
There are so many things wrong with these statement that you surely wrote them as sarcasm.
I thought RoleMaster/SpaceMaster were the most fun systems to play (only in small groups... a GM and 3 players, 5 at the extreme). WoTC just tried to make a simplified form of RM and named it the new D&D. I've tried the new system and it just seems like a watered down RM. Of course, with RM you pick/choose the skills and stuff you wanted, otherwise you'd end up practically having the butt-wiping skill (which you could fumble!) but when you got the subset of skills to cover the depth you wanted, it was fun. There's nothing like getting really lucky and stabbing that bad guy through the eye, killing him instantly!
No... not if the parenthesis were needed to enforce a particular evaluation order (as opposed to the operator precedence order) of a comparison, for example, or a mathmatical function. It wouldn't be a syntax error then... it'd be a logical error.
Yup... It has always been thus. The difference is that the high-end processors do exotic things and then Intel/AMD suck it in when it is ready for commoditization. The x86 has *always* been behind in those types of technologies (but usually pretty far ahead in tricks to make the x86 ISA fast) because those technologies are high-end. Eventually, it all trickles down to commoditization and then we get it in x86s.
Granted, but it is VERY easy to do, and it is the first thing you do when you are behind and are willing to trade profit for getting a faster product out the door
It is easy to do from a CADD standpoint, yes. However, it doesn't come without its own issues... for example the biggest one is a hit on latency. Larger caches tend to be slower (for a number of reasons). You have to be willing to pay the price(s) to grow the cache(s). Perhaps it isn't a big deal to the K8 core to take another clock cycle hit on the L2. However, AMD's cache architecture (exclusive L1/L2) is a little more complicated in the first place but yields a larger effective cache size (the size is L1 + L2 where the more 'normal' L1/L2 design - inclusive - isn't).
I'm not sure the 'noise' about Conroe is entirely marketing. The previews done by a number of sites, even though they were orchestrated/presented by Intel, were fairly believable. 20% speedup is fairly large since we haven't seen that large of a jump in years (if you look at those previews, 20% was the average, there were some near 0% in there but there were also some near 50%).
Fine, and I can show you an article that says the 65nm Athlons will clock 40% faster,
:rolleyes:
If you do, I'll show you a site that you shouldn't be reading anymore as it is worthless.
anyone can add cache
And yet not everyone does...
Why don't we wait 6 months and then start trash talking, when we have actual products.
By all accounts, it will be sooner than 6 months.
- AMD may have some cards to play yet, but it isn't very vocal about them, which is contrary to what it's done in the past when it had something new.
- AM2 is either slower or marginally (usually within stastical noise) faster than the current S939 parts - and only when you use expensive high end DDR2-800 memory, we've already seen those benchmarks from numerous sites.
- K8L is targeting FPU performance for some unknown reason, presumably to duke it out with Itanium which has a tiny share of the market - the HPC centers.
- Conroe is targeting integer performance which is the mainstay of the vast majority of applications and Woodcrest is the server version of that where integer again rules the roost for the vast majority of applications/services (web server, database server, just about any other service you want to talk about, java/.NET languages, etc.).
- Rumors are that within a year (maybe a little longer but in that time frame) AM2 will be replaced with AM3 which is for DDR3. Any CPU you purchase for AM2 will not work with AM3 just like S939 doesn't work with AM2. The joys of the IMC... upgrade the memory type and you have to buy a new CPU. Until AMD clarifies this (which it won't because it would be disasterous for AM2 if there will be an AM3 soon), there is certainly good reason to NOT buy AM2.
This all adds up to my not purchasing any new hardware until Conroe comes out. I imagine many others are like me. While this is pretty much "not good" for Intel or AMD, it's going to mean that AM2 is a flop from the start as only fanbois will buy into that technology path blindly (and given the questions about AM2, there are certainly some big blind spots). This is coming from someone who has four Athlon64s and three AthlonXPs sitting in my computer room. I'm not a fanboi. I buy what is the best for the money when I buy. Right now, I'm thinking that's going to be Conroe (and I imagine there are plenty of folks like me).
Code = programming in general
Code = one application or one logical part of an application
Codes = multiple applications or multiple logical parts of an application
Code is code is code when you are talking about programming in general. All of us are programmers and we write code.
"Code" can refer to a specific entity. Sometimes you'll hear it as "codebase" or "source" or "sourcebase". An example of a specific set of code is the Linux kernel. Another example of a specific set of code is Firefox.
Codes refers to multiple sets of specific entities. If I install all the source for my Linux distribution, I have many sets of code on my machine. I have the codes for the kernel, Firefox, and whatever else.
In the parallel community, your "appliction" may consist of multiple, seperate yet dependent, executables that must all be run together to make up the single job. So, you have multiple sets of code that make the application... thus... multiple codes.
Example: John, check out the atmospheric code (refering to the source of a single executable) to make sure it's using the correct algorithms. David, check out the ocean code (again, the source of a single executable) to make sure it's using the correct algorithm. Ok, now let's run these codes (talking about both executables) together to form an ocean/atmospheric model.
No, asynchronous circuits (and processors) have existed and were commercial products in the past. This is just another turn of the wheel (just like a central computer with terminals was the common mode once before and now the terminals are just web browsers connecting to web servers now). More recently, a number of processors had subunits that were asynchronous (IIRC, at least one of the PA-RISC variants had an asynchronous divider). Asynchronous is nothing new.
As a side note, asynchronous doesn't come for free. Synchronous designs have a clock circuit (driver and network) that runs all over the chip. Asynchronous designs don't have this but they do have a lot of handshaking logic all over the place.
Yup... The couple times I've bought a car I "dressed down" quite a bit. Torn up jeans and an old t-shirt. At one dealership, I had set my budget and started looking around. The sales guy came over and kept pointing me towards low end vehicles that, I guess, he thought were in my price range. I wanted something a little higher end. Eventually, I got annoyed at the guy because he kept trying to pull me away from what I wanted to look at so I told him what I did for a living. He immediately did a 180 degree change and then started constantly pointing me to vehicles that were above what I wanted to spend, even after I told him what I wanted to spend. Eventually, I got annoyed at him and told him that if he couldn't point me to vehicles near my budget even after I requested him to do so, that I wouldn't buy a vehicle from the dealership and I left.
Almost everything you call into question was covered by the second link (the follow-on to the preview). With respect to the timings you mentioned... the DDR2-667 @ 444 should be slower than the DDR400 @ 222/1T in latency and bandwidth. Even then, it isn't a big deal. For example, if you've seen the latest AMD AM2 review from HKEPC (using DDR2-800 at "good" timings for AM2 compared to current S939 with DDR400 at good timings), the current S939 parts with DDR400 win 1/2 the time. The largest gain of AM2 over S939 was in the Science Mark 2 Streams benchmark when it got about 26% gain. Almost all other gains were less than 5% and some were even negative (meaning S939 was faster). Basically, DDR2-667 should be slower than DDR400 for the most part because of latency and it would have only marginal bandwidth increases (surely a bit less than 26%).
This was some of the biggest news in a while and it all happened about 1.5 weeks ago (where were you?:P)... Here are some from Anandtech.
This one is the preliminary benchmark testing that a lot of folks questioned and this one is the follow up that answered a lot of the concerns about the first one. The conclusion was the same, though... at 2.66GHz Conroe beats an overclocked 2.8GHz FX-60 (overclocked to simulate the upcoming FX-62) quite handily (20%+ most of the time) while using 1/2 the power of the AMD part (and obviously at a lower clock speed). There were a few other sites that had similar previews but they all say the same thing.