Depends... I use Linux 99% of the time at work and I have both Linux and Windows boxes at home. I've been using Un*xs since around 1986. Depending on the task, I can do some things faster on Windows than Linux and some faster on Linux than Windows.
Scalable has other meanings. I doubt he was talking about hardware.
Consistent also has other meanings. Consistency between point release versions is one that I'm fighting right now. Our software runs on set-top boxes, in effect. There were a number of version/package upgrades going from SuSE 9.0 and SuSE 9.1 to SuSE 9.2 and it severely broke a few things (such as compiles failing - changes in tools, GUI code behaving very different - changes in underlying libraries/resources, breaking/changing behaviour of some binaries we use, etc.) I've seen this happen many times but it has gotten better. I've seen OSS that was constantly updated so that it would only work with the latest/greatest of other packages so every time you wanted to upgrade that software for whatever fixes were in the newer release, you had to end up typically upgrading anywhere from one to five others.
Predictable, will the next point release break our stuff or not?
Self-contained I imagine means support for the common things done today out of the box. I don't know what he's talking about here... I have plenty of browsers, email clients, mp3 players, etc. out of the box on Linux.
Opterons were designed to have a second SRQ port (unused in single core processors) where the second core will talk to the first. And yes, for all intents and purposes, a dual core processor should logically look the same as a 'conventional' dual processor machine today.
What AMD did for designing for dual cores was SRQ and designed the memory controller on-chip and a seperate unit from the CPU. The memory subsystem is seperated from the core itself, all the cores on-chip make requests through the IMC for off-chip memory. The IMC is designed to allow for more than one core to access it (arbitration logic, queues, etc.) and those other connections aren't connected, but the IMC in the dual cores will run exactly the same as they do today, just with more cores requesting its services.
Well... I find it difficult to believe that someone can "reverse engineer" or make a client capable of interacting with a complex piece of software such as an RCS (including the protocols) without examining the behavior of said software. You have to know how it talks (or how the schema is laid out) or something.
You examine benchmarks that are similar to what you intend to be doing. In other words, if you want a machine to do video editing, look for video editing benchmarks that use the software package you will be using on the machine. Don't look at game benchmarks.
I would be more worried about correctness of operation at that much overclock. Heat problems can be solved. It's difficult to verify the correctness of operation. Running memtest, prime95, and the like are attempts to "prove" that an overclock is stable, but they aren't definitive, much in the way that you can't prove by example.
Yup. I'm in the choir, Mr. Pastor. I went through the overclocking phase myself, then grew up and out of it. Many overclockers don't understand how a CPU works, much less why the *best* outcome of overclocking is a hard crash (because then you know for sure that you've pushed too far). The most insidious errors don't cause crashes... the computer just keeps cranking along just fine but is outputing incorrect results.
They don't understand that the governor for how fast a CPU runs isn't directly time... it's distance (and because of distance, time). They probably don't know much about data setup and hold times, hysteresis, the fact that computing incorrect values because of setup/hold time violations won't cause a crash, you'll just get wrong answers without a crash, etc.
But hey, they are able to get 2% faster computers while spending less money! That is teh kewl!
I hate to say this, but if you can't see the value in developing software for free, you're probably not a very talented developer.
Either that, or you are a talented developer and you realize that your skills are worth being paid for. Also, you may want to eat occassionally.
FOSS software is frequently effectively subsidized (unknowingly many times) by commercial companies. The FOSS developer has a day job to put food on the table and contributes to FOSS on his own time. There are some, but not many, software companies out there who actually create and make money selling FOSS products. These tend to be the exception rather than the rule, though.
While these differences are much higher as more CPU's are linked, it will still make a difference in a single chip/dual core setup.
I never said that AMD's solution wasn't better... I just think that the "reasons" listed as to why Intel's solution isn't a "true dual core" are simply grasping at straws in order to make the fanbois feel better about their religion.
In any case, a dual core Opteron should perform similarly to a current dual socket (single cores) Opteron board that only had memory hanging off of CPU0 (MSI Master2 board for example). A dual core Opteron *should* be a little better than this because of chip speed communications instead of board speed, for example, but I imagine that the performance will be similar (just as I imagine the dual-core Intel parts to be similar in performance to the current dual Xeon machines).
Well, there is no getting around the fact (and it is fact) that the Intel Smithfield is dual core in every sense of the term. It may not be an optimal solution or even a good one, but it is a solution.
The major issue with Intel's approach to dual core designs is that the dual cores must contest with one another for bandwidth across Intel's 64-bit NetBurst FSB.
There is only one memory bus off of the AMD part as well and both cores have to share the bandwidth that it provides. So, I guess that is a major issue with the AMD part too, unless you are an AMD fanboi and that is somehow superior (even though they are the same, but then, that's a fanboi for you).
You don't seem to understand... Intel isn't selling dual core chips either - they are selling chips with two normal P4 dies on them, which are now forced to share I/O bandwidth from a single socket.
And this is different from two Opterons on a single die/package how exactly? In both cases, there is only one path to memory off the package. In both cases, both cores will share the available bandwidth of that path.
First off, it's true dual core - basically a single die with two cores on it, hence the name dual core.
And this is different from Intel's how? Both are two cores on one single die. Liking AMD (as I also do) is no excuse for ignorance. The only reason AMD fanbois are claiming Intel's parts aren't dual core is to soothe their sore pride that Intel beat AMD deliving a dual core product. So what? When AMD's part comes out, it will be better than Intel's and it isn't that long until it does come out.
Well... I would expect dual-core P4s to perform similarly to dual CPU P4s. I'd have liked to seen if this was true (compare against a current dual Xeon) but they didn't do that either. For a simulation of a dual core Opteron, they could have used one of the dual socket Opteron boards that had memory hanging only off of CPU0. That should simulate it pretty close, although the SRQ communication would probably run faster on the dual-core.
Dual core is two cores on a single die. Intel's solution may not be optimal by any measure, but to call it not "true" dual core is simply AMD apologists trying to live down not being the first out the gate with one. Yes, AMD's solution is much better (in my opinion and others) and it will be the one that I buy, but you cannot dismiss Intel's chips simply because they hurt your pride.
You are simply wrong. Functionally, from the OS or programmers' perspectives, there is no difference between a dual processor machine (two sockets, one core per socket) and a dual-core machines (one socket, two cores in a single package).
Without looking at the CPUID or BOIS type information that just outright tells you what you have, you'd have to write some pretty specific code to detect the difference between the two.
Actually, nVidia and ATi follow Microsoft's standards. For example, their newest cards are DX9 compatible. Windows isn't nVidia or ATi compatible.
It isn't about opening the source and what-not. It's about functionality that is considered to be "core" but is actually optional, depending on the distribution you are using. We first developed on one platform and started porting to the second. The second one didn't have functionality that we had designed around in the default kernel, so we either work around it or say: first, you have to compile your kernel, which is an absolute horrid thing to tell a customer to do.
Another example is this: we bought a Gb NIC at CompUSA that had "Linux" explicitly listed in the supported section. Well, it didn't work. After searching around, we found the driver source but we had to compile the kernel with this driver in it. Completely unacceptable for any OS that wants to ever become mainstream.
I'm neither. The base computer I have runs at a certain speed. After you put Windows on it (a bunch of code) and Linux on it (another bunch of code) the performance characteristics are different. Similarly, you can have MySQL as a base data store and put an app on it and the app can be fast. You can put another app on it and the app will be slow. If I had to code into my application all of the features that MySQL doesn't support in order to make use of those features, then my app has simply added the code into it that MySQL should have in it and it will pay the performance penalty (probably more of a penalty since the MySQL folks are probably smarter than me at DBMS coding and could write more optimal code for it into the DBMS).
I do have access to those pieces of software but I'm not an idiot. Put an application that needs ACID on top of Oracle and the same application with all of the required ACID components implimented inside it that MySQL doesn't have and then compare the two. A DBMS by itself does nothing useful.
The main issue is that many folks who think they are DBMS savvy wouldn't know when ACID functionality is required and when it isn't. Most of them I wouldn't trust to write a DB management system for a teenager's Magic card collection, much less some application dealing with my money.
The one thing that MySQL excels in is raw speed. It's faster than everything else because it doesn't have all the data integrity features that a RDBMS does.
However, I stick everything into the application layer, so MySQL lacking these features doesn't bother me a bit.
So... do you add in all the code overhead that you have to write into your application into your MySQL performance numbers? This includes time-to-deployment, development costs, and the like as well as how many queries per second your app can perform?
Yeah... a lot of folks use screwdrivers as chisels, wrenches as hammers, knives as screwdrivers, and pliars for wrenches, too. It doesn't make a screwdriver a chisel, a wrench a hammer, a knife a screwdriver, or pliars a wrench.
There are other issues as well. For instance, if the entire world were to switch over to FOSS today, we would degenerate back to nearly the same conditions that were around in the late 70s and early 80s (only a little better). You know... those who don't know history are doomed to repeat it.
Here's a quick/brief/skim history lesson:
Back in the 70s and early 80s, every Tom, Dick, and Harry made a computer and put it onto the market. The didn't work so well (or at all) with each other either the software or the hardware. Every one of these companies had their own standards and pushed them. It was basically chaos, although it was fun.
There were many "standards" for anything you wanted to do, depending on things like what platform you were on. 2D graphics is a good example. On one system, you had player/missle graphics, on another, you had sprites, and yet on another, there weren't any special things at all. This made porting software fairly painful. It also made making hardware add-ins hard. You had to target any number of hardware platforms in order to get a wide market.
One of the things that came out of all that (that Linux, for example, uses to a very high degree) is that one company came out ahead of the rest (for whatever reason) and standardized the landscape. At first, this was IBM. ISA cards started becoming *the* platform for hardware even to the point that other systems (Amiga, for example) started including them in the system.
This didn't clear up the landscape for software though. VESA had some standards that people tried to conform to, but these were loose at best. Many times if you bought a game, you had to make sure that your specific video card was supported before you bought it because the game developers had to target individual cards for ports. Many times they'd fall back into a VESA mode for minimal compatibility but for the good stuff, you had to have one of a short list of well supported cards. Likewise, many hardware devices had very specialized software (scanners, printers) to be used with them. If you wanted to use a particular software package, you had a short list of hardware that it could be used with at all.
Later, Microsoft came out of the pack and standardized video card interfaces. Now, game developers could write to one interface and target any card that supported the interface. Also, a number of other interface standards came out in the DirectX packages. Now, hardware vendors and software vendors alike had a common platform to design towards. This made large software and hardware markets available and companies could take advantage of this and make money.
Anyway, to shorten things up, Linux makes great use of a common hardware platform (the x86 box that we know and love/hate today). It also makes use of many consolidations that were made due to a single big player (hardware/software interfaces). However, the FOSS world itself is still fairly fractured. Many think choice is nice, and it is a lot of the time. However, choice also tends to dilute efforts. For example, you have KDE and Gnome, both with a religious following. That's not only duplication of effort but it's also two paths that a software company has to follow if they want to reach as far and wide as they can with their software. A company could just follow one, but what if that was the wrong choice (that path dies off or basically loses to the other path). If they target both, then they have to double their efforts and this costs time and money. Some developers can afford this. I imagine that many FOSS developers can't. This doesn't even come close when comparing it to the number of Linux distributions out there. Where I am, we target two distributions right now and that's mainly because we can't afford to target more. Even those two distributions (two of the widest used) cause us software compatibility problems. Things that work on one do not always work on the other. Sometimes they are easy to work around (locations of certain resource
Slashdot Mirror
Depends... I use Linux 99% of the time at work and I have both Linux and Windows boxes at home. I've been using Un*xs since around 1986. Depending on the task, I can do some things faster on Windows than Linux and some faster on Linux than Windows.
Scalable has other meanings. I doubt he was talking about hardware.
Consistent also has other meanings. Consistency between point release versions is one that I'm fighting right now. Our software runs on set-top boxes, in effect. There were a number of version/package upgrades going from SuSE 9.0 and SuSE 9.1 to SuSE 9.2 and it severely broke a few things (such as compiles failing - changes in tools, GUI code behaving very different - changes in underlying libraries/resources, breaking/changing behaviour of some binaries we use, etc.) I've seen this happen many times but it has gotten better. I've seen OSS that was constantly updated so that it would only work with the latest/greatest of other packages so every time you wanted to upgrade that software for whatever fixes were in the newer release, you had to end up typically upgrading anywhere from one to five others.
Predictable, will the next point release break our stuff or not?
Self-contained I imagine means support for the common things done today out of the box. I don't know what he's talking about here... I have plenty of browsers, email clients, mp3 players, etc. out of the box on Linux.
Opterons were designed to have a second SRQ port (unused in single core processors) where the second core will talk to the first. And yes, for all intents and purposes, a dual core processor should logically look the same as a 'conventional' dual processor machine today.
Half of what?
What AMD did for designing for dual cores was SRQ and designed the memory controller on-chip and a seperate unit from the CPU. The memory subsystem is seperated from the core itself, all the cores on-chip make requests through the IMC for off-chip memory. The IMC is designed to allow for more than one core to access it (arbitration logic, queues, etc.) and those other connections aren't connected, but the IMC in the dual cores will run exactly the same as they do today, just with more cores requesting its services.
a) Two cores sharing the same bus... well... what have all the dual processor machines in the x86 line from Intel used?
2) There's more to life than games.
D) Hypertransport doesn't enable dual cores.
Well... I find it difficult to believe that someone can "reverse engineer" or make a client capable of interacting with a complex piece of software such as an RCS (including the protocols) without examining the behavior of said software. You have to know how it talks (or how the schema is laid out) or something.
Pipe and a pancake?
Bong and a blintz?
Cigar and a crepe?
You examine benchmarks that are similar to what you intend to be doing. In other words, if you want a machine to do video editing, look for video editing benchmarks that use the software package you will be using on the machine. Don't look at game benchmarks.
I would be more worried about correctness of operation at that much overclock. Heat problems can be solved. It's difficult to verify the correctness of operation. Running memtest, prime95, and the like are attempts to "prove" that an overclock is stable, but they aren't definitive, much in the way that you can't prove by example.
Yup. I'm in the choir, Mr. Pastor. I went through the overclocking phase myself, then grew up and out of it. Many overclockers don't understand how a CPU works, much less why the *best* outcome of overclocking is a hard crash (because then you know for sure that you've pushed too far). The most insidious errors don't cause crashes... the computer just keeps cranking along just fine but is outputing incorrect results.
They don't understand that the governor for how fast a CPU runs isn't directly time... it's distance (and because of distance, time). They probably don't know much about data setup and hold times, hysteresis, the fact that computing incorrect values because of setup/hold time violations won't cause a crash, you'll just get wrong answers without a crash, etc.
But hey, they are able to get 2% faster computers while spending less money! That is teh kewl!
I hate to say this, but if you can't see the value in developing software for free, you're probably not a very talented developer.
Either that, or you are a talented developer and you realize that your skills are worth being paid for. Also, you may want to eat occassionally.
FOSS software is frequently effectively subsidized (unknowingly many times) by commercial companies. The FOSS developer has a day job to put food on the table and contributes to FOSS on his own time. There are some, but not many, software companies out there who actually create and make money selling FOSS products. These tend to be the exception rather than the rule, though.
While these differences are much higher as more CPU's are linked, it will still make a difference in a single chip/dual core setup.
I never said that AMD's solution wasn't better... I just think that the "reasons" listed as to why Intel's solution isn't a "true dual core" are simply grasping at straws in order to make the fanbois feel better about their religion.
In any case, a dual core Opteron should perform similarly to a current dual socket (single cores) Opteron board that only had memory hanging off of CPU0 (MSI Master2 board for example). A dual core Opteron *should* be a little better than this because of chip speed communications instead of board speed, for example, but I imagine that the performance will be similar (just as I imagine the dual-core Intel parts to be similar in performance to the current dual Xeon machines).
Well, there is no getting around the fact (and it is fact) that the Intel Smithfield is dual core in every sense of the term. It may not be an optimal solution or even a good one, but it is a solution.
The major issue with Intel's approach to dual core designs is that the dual cores must contest with one another for bandwidth across Intel's 64-bit NetBurst FSB.
There is only one memory bus off of the AMD part as well and both cores have to share the bandwidth that it provides. So, I guess that is a major issue with the AMD part too, unless you are an AMD fanboi and that is somehow superior (even though they are the same, but then, that's a fanboi for you).
You don't seem to understand... Intel isn't selling dual core chips either - they are selling chips with two normal P4 dies on them, which are now forced to share I/O bandwidth from a single socket.
And this is different from two Opterons on a single die/package how exactly? In both cases, there is only one path to memory off the package. In both cases, both cores will share the available bandwidth of that path.
First off, it's true dual core - basically a single die with two cores on it, hence the name dual core.
And this is different from Intel's how? Both are two cores on one single die. Liking AMD (as I also do) is no excuse for ignorance. The only reason AMD fanbois are claiming Intel's parts aren't dual core is to soothe their sore pride that Intel beat AMD deliving a dual core product. So what? When AMD's part comes out, it will be better than Intel's and it isn't that long until it does come out.
Well... I would expect dual-core P4s to perform similarly to dual CPU P4s. I'd have liked to seen if this was true (compare against a current dual Xeon) but they didn't do that either. For a simulation of a dual core Opteron, they could have used one of the dual socket Opteron boards that had memory hanging only off of CPU0. That should simulate it pretty close, although the SRQ communication would probably run faster on the dual-core.
Dual core is two cores on a single die. Intel's solution may not be optimal by any measure, but to call it not "true" dual core is simply AMD apologists trying to live down not being the first out the gate with one. Yes, AMD's solution is much better (in my opinion and others) and it will be the one that I buy, but you cannot dismiss Intel's chips simply because they hurt your pride.
You are simply wrong. Functionally, from the OS or programmers' perspectives, there is no difference between a dual processor machine (two sockets, one core per socket) and a dual-core machines (one socket, two cores in a single package).
Without looking at the CPUID or BOIS type information that just outright tells you what you have, you'd have to write some pretty specific code to detect the difference between the two.
Subspace Powerball *rules*.... GOOOOOOAAAAAALLL!!!!
- 9mmHemorrhage
Actually, nVidia and ATi follow Microsoft's standards. For example, their newest cards are DX9 compatible. Windows isn't nVidia or ATi compatible.
It isn't about opening the source and what-not. It's about functionality that is considered to be "core" but is actually optional, depending on the distribution you are using. We first developed on one platform and started porting to the second. The second one didn't have functionality that we had designed around in the default kernel, so we either work around it or say: first, you have to compile your kernel, which is an absolute horrid thing to tell a customer to do.
Another example is this: we bought a Gb NIC at CompUSA that had "Linux" explicitly listed in the supported section. Well, it didn't work. After searching around, we found the driver source but we had to compile the kernel with this driver in it. Completely unacceptable for any OS that wants to ever become mainstream.
I'm neither. The base computer I have runs at a certain speed. After you put Windows on it (a bunch of code) and Linux on it (another bunch of code) the performance characteristics are different. Similarly, you can have MySQL as a base data store and put an app on it and the app can be fast. You can put another app on it and the app will be slow. If I had to code into my application all of the features that MySQL doesn't support in order to make use of those features, then my app has simply added the code into it that MySQL should have in it and it will pay the performance penalty (probably more of a penalty since the MySQL folks are probably smarter than me at DBMS coding and could write more optimal code for it into the DBMS).
I do have access to those pieces of software but I'm not an idiot. Put an application that needs ACID on top of Oracle and the same application with all of the required ACID components implimented inside it that MySQL doesn't have and then compare the two. A DBMS by itself does nothing useful.
The main issue is that many folks who think they are DBMS savvy wouldn't know when ACID functionality is required and when it isn't. Most of them I wouldn't trust to write a DB management system for a teenager's Magic card collection, much less some application dealing with my money.
The one thing that MySQL excels in is raw speed. It's faster than everything else because it doesn't have all the data integrity features that a RDBMS does.
However, I stick everything into the application layer, so MySQL lacking these features doesn't bother me a bit.
So... do you add in all the code overhead that you have to write into your application into your MySQL performance numbers? This includes time-to-deployment, development costs, and the like as well as how many queries per second your app can perform?
Yeah, I've seen logs used as hammers, screwdrivers used as chisels, and knifes used as screwdrivers before, too.
I've also seen the religious (not just diety religion) bang square pegs into round holes.
I've also seen those who proclaim loudly that they know "exactly what they are doing" actually be the furthest from reality.
Yeah... a lot of folks use screwdrivers as chisels, wrenches as hammers, knives as screwdrivers, and pliars for wrenches, too. It doesn't make a screwdriver a chisel, a wrench a hammer, a knife a screwdriver, or pliars a wrench.
There are other issues as well. For instance, if the entire world were to switch over to FOSS today, we would degenerate back to nearly the same conditions that were around in the late 70s and early 80s (only a little better). You know... those who don't know history are doomed to repeat it.
Here's a quick/brief/skim history lesson:
Back in the 70s and early 80s, every Tom, Dick, and Harry made a computer and put it onto the market. The didn't work so well (or at all) with each other either the software or the hardware. Every one of these companies had their own standards and pushed them. It was basically chaos, although it was fun.
There were many "standards" for anything you wanted to do, depending on things like what platform you were on. 2D graphics is a good example. On one system, you had player/missle graphics, on another, you had sprites, and yet on another, there weren't any special things at all. This made porting software fairly painful. It also made making hardware add-ins hard. You had to target any number of hardware platforms in order to get a wide market.
One of the things that came out of all that (that Linux, for example, uses to a very high degree) is that one company came out ahead of the rest (for whatever reason) and standardized the landscape. At first, this was IBM. ISA cards started becoming *the* platform for hardware even to the point that other systems (Amiga, for example) started including them in the system.
This didn't clear up the landscape for software though. VESA had some standards that people tried to conform to, but these were loose at best. Many times if you bought a game, you had to make sure that your specific video card was supported before you bought it because the game developers had to target individual cards for ports. Many times they'd fall back into a VESA mode for minimal compatibility but for the good stuff, you had to have one of a short list of well supported cards. Likewise, many hardware devices had very specialized software (scanners, printers) to be used with them. If you wanted to use a particular software package, you had a short list of hardware that it could be used with at all.
Later, Microsoft came out of the pack and standardized video card interfaces. Now, game developers could write to one interface and target any card that supported the interface. Also, a number of other interface standards came out in the DirectX packages. Now, hardware vendors and software vendors alike had a common platform to design towards. This made large software and hardware markets available and companies could take advantage of this and make money.
Anyway, to shorten things up, Linux makes great use of a common hardware platform (the x86 box that we know and love/hate today). It also makes use of many consolidations that were made due to a single big player (hardware/software interfaces). However, the FOSS world itself is still fairly fractured. Many think choice is nice, and it is a lot of the time. However, choice also tends to dilute efforts. For example, you have KDE and Gnome, both with a religious following. That's not only duplication of effort but it's also two paths that a software company has to follow if they want to reach as far and wide as they can with their software. A company could just follow one, but what if that was the wrong choice (that path dies off or basically loses to the other path). If they target both, then they have to double their efforts and this costs time and money. Some developers can afford this. I imagine that many FOSS developers can't. This doesn't even come close when comparing it to the number of Linux distributions out there. Where I am, we target two distributions right now and that's mainly because we can't afford to target more. Even those two distributions (two of the widest used) cause us software compatibility problems. Things that work on one do not always work on the other. Sometimes they are easy to work around (locations of certain resource