I've often thought that. They already have support for NUMA in OSes like Windows, Linux, etc, and DRAM cells take 1/6th as many trasistors as SRAM cells (used in cache). You could still have RAM external to the CPU, it would just be recognized as being non-local.
"The first tests that I have seen put it on an almost even footing with the A64 when the cache is not a factor. I cannot wait for more tests so we can see more details."
I don't think the results warrant that conclusion...
Instead of being equal and having an edge due to the larger cache, I'd say the execution core is better than an Athlon64's, and this is most evident when the working set fits inside the cache. The fact that the cache is larger only helps matters.
Athlon64s still have an edge in memory bandwidth and latency due to the on-die memory controller, but from what I've seen Conroe has a significant edge in integer performance, the FSB isn't that much of a disadvantage most of the time, and the floating point stuff is dramatically ahead of Athlon64s. In particular, SSE instructions now have a single-cycle latency.
Either way, early benchmarks of Conroe, as limited as they are, are very impressive, while early benchmarks of AM2 chips don't show much improvement over existing stuff. This may change, and I won't be making any final determinations until I see multiple reviews of shipping hardware, but at the moment it looks like Intel will take back the lead.
The one thing that I found impressive and surprising about the AM2 chips is the power usage. 65 watts for most of them, meaning they've matched Intel even though Intel has moved to 65 nm and AMD hasn't, and they even have a 35 watt desktop chip, which is almost in laptop territory. This is one area where I thought Intel would hold a considerable lead, and I am impressed that AMD has managed this.
"All I know it that when Intel shows this great new Conroe, and the cache size on the initial units is 4MB, It makes me wonder if they even believe they have a superior product. If they believed that, they would have a 1 MB cache - take the profit and run. (we will see, maybe I am wrong)"
I don't think huge caches like that would help all that much if they didn't have a good execution core to back it up. They didn't help Pentium 4s (well they did, but not enough).
"Actually, early indications seem to indicate that it stomps the Athlon when everything fits in the massive L1 Cache, but the "architechtural improvements" you talk about only bring it up to parity without the gigantic cache. (anyone can add cache, it is an expensive move that you only make if you really need the performance)"
Even if that's true, Intel usually holds a pretty big lead in moving to smaller processes, so bigger caches aren't likely to leave their arsenal.
"we really need to read more than ONE article before we decide who is king, and that Conroe will be superior to AM2"
Well, I certainly won't be making purchasing decisions until I read multiple reviews of shipping hardware. These are just early indications.
"Sure this meant a lot for the intel architecture but from what I understood the AMD architecture will not gain a lot from this memory speed increase."
Early indications are that Intel's architechtural improvements with Conroe will give them a significant edge over AM2 chips, even though AMD still has an on-die memory controller and Intel doesn't.
"Also, the latency on the memory will likely also increase which might cancel all gains made from the increased speed."
They'll be using 667 and 800 mhz clock speeds, so it won't be too bad, but the gains from the extra memory bandwidth aren't as big as one might expect. At least for AMD.
"Therefore, I'm waiting and seeing before I get me one of those."
Sound advice for any pre-launch situation.:)
I'm going to take the wait-and-see approach as well, but so far looks like I'll be continuing my pattern. My last few computers have been Pentium II, Athlon, Pentium 4, and Athlon 64.
Though I rarely get top-of-the-line chips, so if AMD cuts the prices for their high-end stuff when Intel has faster parts, that might make them preferable even if Intel holds the performance crown at the time.
I mostly want dual cores and hardware-supported virtrualization so I can run OpenBSD under Xen. Both AM2 and Conroe will have that, so it's pretty much a question of who gives me the best performance.
In practice I think the FreeBSD approach probably does have speed advantages in most cases, and the fact that it's transparent to the userspace developer would seemingly be a big advantage.
But Linus makes a good case, and I'm glad to see him taking a more conservative approach after the troubles with getting some decent stability out of 2.6. write() and sendmsg() aren't that slow, and the new way will be faster and less fragile. It provides opportunities for optimization for those willing to do platform specific stuff, and it provides a reasonably fast portable way for everyone else. This is nothing new, there's plenty of platform-specific system calls on Linux, like epoll(), and the BSDs do it too with stuff like kqueue().
This sort of thing matters almost exclusively to people doing really deep performance tuning, and for them it's better to present a simple API with large rewards for tuning, instead of transparently doing something weird to an existing API that will break in the field without you noticing and requires really weird usage to get the best performance.
Basically, it's an appliance that sits between your WAN connection and the rest of your network. It understands most protocols that send bulk data over the network, and does transparent caching such that the clients on your network don't notice anything (except improved speed), and the server on the other end still thinks it's sending the data.
I saw a demo at a CUUG meeting, it was quite impressive.
It is a disincentive to make Mac-native software, but that pressure does not exist in isolation. Balancing against that are the increased sales that will result, increasing the number of people running MacOS and therefore the incentive to produce native software.
A useful example to consider is Linux. It has always been able to dual-boot with Windows, VMWare has allowed Windows to run in a VM for some time, and Wine allows Windows apps to run transparently. Yet, in the last few years it has reached the point where companies have started to produce native software anyway.
Apple has always been at that point, and if they're going to make signficant gains this year (early indications are that they already have) then it will strengthen that position. There will be apps that don't make it (eg games), but I don't think the net impact will be a problem.
"I can understand how someone might want to escape Windows for Linux, but I don't understand craving that Linux experience when you have a Mac."
Performance: Linux has significant performance advantages covered in more detail in another post. This isn't necessarily a raw speed issue, you might be trying to profile your code and want results from a system that's similar to where the code will run in production.
Software availability: This doesn't mean Macs have less software (as they have stuff Linux doesn't as well), only that they have different software. There are plenty of things that are only available or better available on Linux. The big example is Java, the Apple version on OS X isn't 100% compatible with the official version (has some extra bugs and stuff), and the Apple implementation typically releases new versions late and only for updated OS versions.
Compatibility: MacOS isn't binary compatible or source compatible with Linux. If you're doing development for Linux, you usually need Linux. Even though it's possible to port software between the two, there's different platform-specific APIs (eg kqueue vs epoll) that make it impossible to move development entirely to the other platform.
Features: Linux and Linux specific software has powerful features that MacOS doesn't. One is LVMs, which allow dynamic resizing and snapshots for filesystems. Apparently commercial virtualization software will be available in the future for MacOS, but at the moment there's nothing to match Xen or VMWare.
None of this means Linux is "better", only that it's useful for different things. If you do the things where Linux is better suited, but want to retain the ability to do things for which MacOS is better suited, then that's a very compelling reason to dual-boot.
"If a light sabre is say, twice as hot as that then I dont care how small the sureface area is you are going to notice it if its less than 1 meter from you."
To glow red, the slab would have to be about 700 K, but I think it's fair to say it has a large surface area.
In comparison, the filament in an incandescant light bulb is about 2800 K, 4 times as hot. You do indeed notice it, but it doesn't burn you. And they have to coil the filament very tightly to increase the surface area enough to emit useful amounts of light. I don't know how thick a light saber is, but it could potentially be pretty hot without burning the person weilding it.
"Can anyone tell me why BSD with it's enhanced security isn't incorporated into most Linux distros?"
It's not a simple matter of importing code, to duplicate the changes in the Linux kernel and the GNU toolset would be prohibitively difficult. Also, much of the improved security comes at the expense of performance or functionality.
In my experience, they tend to be pretty sharp (as they figured out mainframes Back in the Day) and able to recognize holes in their knowledge/experience.
"Kid: do you seriously think scientists could give a boulder escape velocity by colliding another object with the earth?"
Given a sufficiently large and fast asteroid, yes.
"Or think about it this way -- given random directions for the boulders, about 1 in 10e15 boulders (approximate average view factor from earth to the moon where they supposedly landed) will go from earth to the other planet.
Low odds don't make it impossible, but your estimate of the odds is also deeply flawed. Your estimate of the odds ignores gravity. A simple guess based on the angular size of an object isn't sufficient, particularly we're talking about the chances of a collision with something as massive as the moon, Mars, Titan, etc. Moreover, much of the debris ejected at higher than escape velocity from a collision on Earth will enter into an orbit around the Sun (as solar escape velocity is higher), and the chances of a collision with something are much higher over billions of years.
"Given the number of boulders they claim made it, that would imply the total number of ejected boulders should be huge, and we should see it happening all the fucking time."
Strange, isn't it? You'd almost think that the number of asteroids now is smaller than it was in the past. As if there was something causing attrition. As if they were being used up somehow.
What do you think could reduce the number of asteroids available for collisions if collisions do happen sometimes? Any guesses?
"And yes, it is hard to believe even tiny objects went *from the ground*, straight into space due to a collision, rather than usual dust formation. Remember, objects fry up coming *into* the atmosphere, but we're supposed to believe they don't *when leaving*?
Sure:
Many objects survive to hit the surface, and subsequent investigation shows that conditions within the objects would not have necessarily sterilized them. Apparently they ablate more than they fry.
Many objects have been found on Earth that were ejected from other planets like Mars by other impacts, demonstrating the principal very clearly.
As I said before, the moon very likely formed from impact ejecta. Its composition and orbit are very difficult to explain without it being the result of a very large impact early in Earth's history. The moon is huge, comparable in size to the large gas giant moons and bigger than some planets. Is there any reasonable way to discount smaller impacts doing something similar on a smaller scale?
Obviously, it is uncommon for large amounts of material to be transported around in this way, and something like the Moon is probably rare in the universe, but smaller impacts are more common. Given the physical evidence and theoretical support, it doesn't make sense to dismiss the idea out of hand.
"Is it just me, or does the idea of meteors kicking stuff *off the earth* not pass the laugh test?"
Only a tiny fraction of the original mass need reach escape velocity to allow bacteria to escape (they're fairly small compared to some of these objects after all). If the moon formed from ejecta from a large impact (as seems to be the case), is it so hard to believe that objects a tiny fraction of that size reached escape volocity?
"If you know of a motherboard with SATA that'll take a CPU that can be passively cooled and has open source drivers for everything, I'd like to hear about it, as I plan to build a bigger server this year."
In the enlarged picture of the board, you can clearly see two SATA ports at the bottom right.
"Firewire is a capable interface, and IP traffic is one of its capabilities. It works with a Firewire cable, peer-to-peer, between two Macs and at 400 Mbit/sec it's sometimes an improvement on crossover-cable-Ethernet."
This isn't very useful for what many of us will use a VIA machine for, and that is firewalling. To provide firewall service to a LAN, a second ethernet port is required. That's fine for a home LAN or small office, but larger networks will require multiple APs even if they're wireless, and that's much easier to do with an ethernet network. It can need more than 2 network ports if there's more than one network segment or other requirements (see below), and the PCI card can handle a 4-port NIC. VIA also generally has a version of the board with two network interfaces, and that plus a single-port NIC is pretty cheap. Also, a Firewire 400 port will typically not be that much faster than a 100 megabit ethernet port, even though the bitrate is nominally faster. While Firewire can handle faster speeds, the nature of IP traffic keeps it from reaching its potential.
An example of a network setup that would need more ethernet ports would be a site that has multiple network segments. You may have different departments, have some servers that you want to isolate, or a wireless and wired network that you want to isolate. You might also want a firewall cluster with failover capability, as is possible on OpenBSD (pfsync + carp), where an additional network interface is required.
Basically, a mini can be adequate for firewalling purposes if the requirements are simple enough, but a VIA machine is much more capable in that role. It's also much cheaper, so you can get yourself a firewall cluster for what a single mini would cost you.
In summary, a mini isn't necessarily totally useless as a firewall, but a VIA machine will be much more useful for demanding situations.
"Bwah? That's the most interesting part, to me. I mean, they MUST have had that sucker plugged into a surge protector. From where did the energy appear?"
It says they used a steel wire instead of tungsten, and iron fusion is endothermic... but there's carbon and other stuff present, and the containment vessel probably has other stuff.
I'm torn. C and C++ are too complex and expose too much. Java is too pedantic and large (at least the API is), yet Python and other similar languages are too permissive.
Pascal is pretty reasonable. It has the benefit of not being that useful by itself, so you have to broaden your horizons a bit, but structured enough that it won't teach bad habits.
But I don't think C is a good beginner's language either. Best to teach someone how to code in an environment where they don't have to worry about other stuff like pointers.
Once they know how to code, then they can learn other concepts like pointers.
Slashdot Mirror
"Are you suggesting AMD buy SGI?"
Hell, I've got some change left over from lunch, I'm thinking of buying SGI.
I've often thought that. They already have support for NUMA in OSes like Windows, Linux, etc, and DRAM cells take 1/6th as many trasistors as SRAM cells (used in cache). You could still have RAM external to the CPU, it would just be recognized as being non-local.
"The first tests that I have seen put it on an almost even footing with the A64 when the cache is not a factor. I cannot wait for more tests so we can see more details."
I don't think the results warrant that conclusion...
Instead of being equal and having an edge due to the larger cache, I'd say the execution core is better than an Athlon64's, and this is most evident when the working set fits inside the cache. The fact that the cache is larger only helps matters.
Athlon64s still have an edge in memory bandwidth and latency due to the on-die memory controller, but from what I've seen Conroe has a significant edge in integer performance, the FSB isn't that much of a disadvantage most of the time, and the floating point stuff is dramatically ahead of Athlon64s. In particular, SSE instructions now have a single-cycle latency.
Either way, early benchmarks of Conroe, as limited as they are, are very impressive, while early benchmarks of AM2 chips don't show much improvement over existing stuff. This may change, and I won't be making any final determinations until I see multiple reviews of shipping hardware, but at the moment it looks like Intel will take back the lead.
The one thing that I found impressive and surprising about the AM2 chips is the power usage. 65 watts for most of them, meaning they've matched Intel even though Intel has moved to 65 nm and AMD hasn't, and they even have a 35 watt desktop chip, which is almost in laptop territory. This is one area where I thought Intel would hold a considerable lead, and I am impressed that AMD has managed this.
"All I know it that when Intel shows this great new Conroe, and the cache size on the initial units is 4MB, It makes me wonder if they even believe they have a superior product. If they believed that, they would have a 1 MB cache - take the profit and run. (we will see, maybe I am wrong)"
I don't think huge caches like that would help all that much if they didn't have a good execution core to back it up. They didn't help Pentium 4s (well they did, but not enough).
"Actually, early indications seem to indicate that it stomps the Athlon when everything fits in the massive L1 Cache, but the "architechtural improvements" you talk about only bring it up to parity without the gigantic cache. (anyone can add cache, it is an expensive move that you only make if you really need the performance)"
Even if that's true, Intel usually holds a pretty big lead in moving to smaller processes, so bigger caches aren't likely to leave their arsenal.
"we really need to read more than ONE article before we decide who is king, and that Conroe will be superior to AM2"
Well, I certainly won't be making purchasing decisions until I read multiple reviews of shipping hardware. These are just early indications.
"Sure this meant a lot for the intel architecture but from what I understood the AMD architecture will not gain a lot from this memory speed increase."
:)
Early indications are that Intel's architechtural improvements with Conroe will give them a significant edge over AM2 chips, even though AMD still has an on-die memory controller and Intel doesn't.
"Also, the latency on the memory will likely also increase which might cancel all gains made from the increased speed."
They'll be using 667 and 800 mhz clock speeds, so it won't be too bad, but the gains from the extra memory bandwidth aren't as big as one might expect. At least for AMD.
"Therefore, I'm waiting and seeing before I get me one of those."
Sound advice for any pre-launch situation.
I'm going to take the wait-and-see approach as well, but so far looks like I'll be continuing my pattern. My last few computers have been Pentium II, Athlon, Pentium 4, and Athlon 64.
Though I rarely get top-of-the-line chips, so if AMD cuts the prices for their high-end stuff when Intel has faster parts, that might make them preferable even if Intel holds the performance crown at the time.
I mostly want dual cores and hardware-supported virtrualization so I can run OpenBSD under Xen. Both AM2 and Conroe will have that, so it's pretty much a question of who gives me the best performance.
In practice I think the FreeBSD approach probably does have speed advantages in most cases, and the fact that it's transparent to the userspace developer would seemingly be a big advantage.
But Linus makes a good case, and I'm glad to see him taking a more conservative approach after the troubles with getting some decent stability out of 2.6. write() and sendmsg() aren't that slow, and the new way will be faster and less fragile. It provides opportunities for optimization for those willing to do platform specific stuff, and it provides a reasonably fast portable way for everyone else. This is nothing new, there's plenty of platform-specific system calls on Linux, like epoll(), and the BSDs do it too with stuff like kqueue().
This sort of thing matters almost exclusively to people doing really deep performance tuning, and for them it's better to present a simple API with large rewards for tuning, instead of transparently doing something weird to an existing API that will break in the field without you noticing and requires really weird usage to get the best performance.
"Typically if drives do die they don't die all at once."
You must not use Maxtors.
Good man.
I don't see why not. They can handle entire racks filled with drives almost that big now.
Riverbed makes an appliance that may be suitable.
Basically, it's an appliance that sits between your WAN connection and the rest of your network. It understands most protocols that send bulk data over the network, and does transparent caching such that the clients on your network don't notice anything (except improved speed), and the server on the other end still thinks it's sending the data.
I saw a demo at a CUUG meeting, it was quite impressive.
It is a disincentive to make Mac-native software, but that pressure does not exist in isolation. Balancing against that are the increased sales that will result, increasing the number of people running MacOS and therefore the incentive to produce native software.
A useful example to consider is Linux. It has always been able to dual-boot with Windows, VMWare has allowed Windows to run in a VM for some time, and Wine allows Windows apps to run transparently. Yet, in the last few years it has reached the point where companies have started to produce native software anyway.
Apple has always been at that point, and if they're going to make signficant gains this year (early indications are that they already have) then it will strengthen that position. There will be apps that don't make it (eg games), but I don't think the net impact will be a problem.
"I can understand how someone might want to escape Windows for Linux, but I don't understand craving that Linux experience when you have a Mac."
Performance: Linux has significant performance advantages covered in more detail in another post. This isn't necessarily a raw speed issue, you might be trying to profile your code and want results from a system that's similar to where the code will run in production.
Software availability: This doesn't mean Macs have less software (as they have stuff Linux doesn't as well), only that they have different software. There are plenty of things that are only available or better available on Linux. The big example is Java, the Apple version on OS X isn't 100% compatible with the official version (has some extra bugs and stuff), and the Apple implementation typically releases new versions late and only for updated OS versions.
Compatibility: MacOS isn't binary compatible or source compatible with Linux. If you're doing development for Linux, you usually need Linux. Even though it's possible to port software between the two, there's different platform-specific APIs (eg kqueue vs epoll) that make it impossible to move development entirely to the other platform.
Features: Linux and Linux specific software has powerful features that MacOS doesn't. One is LVMs, which allow dynamic resizing and snapshots for filesystems. Apparently commercial virtualization software will be available in the future for MacOS, but at the moment there's nothing to match Xen or VMWare.
None of this means Linux is "better", only that it's useful for different things. If you do the things where Linux is better suited, but want to retain the ability to do things for which MacOS is better suited, then that's a very compelling reason to dual-boot.
"Unless, I suppose, you're running an app that you only need occasionally."
Or you're running an app during the day to pay the bills, but want the same computer to be useful in the evening when you're done.
"If a light sabre is say, twice as hot as that then I dont care how small the sureface area is you are going to notice it if its less than 1 meter from you."
To glow red, the slab would have to be about 700 K, but I think it's fair to say it has a large surface area.
In comparison, the filament in an incandescant light bulb is about 2800 K, 4 times as hot. You do indeed notice it, but it doesn't burn you. And they have to coil the filament very tightly to increase the surface area enough to emit useful amounts of light. I don't know how thick a light saber is, but it could potentially be pretty hot without burning the person weilding it.
It probably doesn't have that much surface area...
"Can anyone tell me why BSD with it's enhanced security isn't incorporated into most Linux distros?"
It's not a simple matter of importing code, to duplicate the changes in the Linux kernel and the GNU toolset would be prohibitively difficult. Also, much of the improved security comes at the expense of performance or functionality.
In my experience, they tend to be pretty sharp (as they figured out mainframes Back in the Day) and able to recognize holes in their knowledge/experience.
"Kid: do you seriously think scientists could give a boulder escape velocity by colliding another object with the earth?"
Given a sufficiently large and fast asteroid, yes.
"Or think about it this way -- given random directions for the boulders, about 1 in 10e15 boulders (approximate average view factor from earth to the moon where they supposedly landed) will go from earth to the other planet.
Low odds don't make it impossible, but your estimate of the odds is also deeply flawed. Your estimate of the odds ignores gravity. A simple guess based on the angular size of an object isn't sufficient, particularly we're talking about the chances of a collision with something as massive as the moon, Mars, Titan, etc. Moreover, much of the debris ejected at higher than escape velocity from a collision on Earth will enter into an orbit around the Sun (as solar escape velocity is higher), and the chances of a collision with something are much higher over billions of years.
"Given the number of boulders they claim made it, that would imply the total number of ejected boulders should be huge, and we should see it happening all the fucking time."
Strange, isn't it? You'd almost think that the number of asteroids now is smaller than it was in the past. As if there was something causing attrition. As if they were being used up somehow.
What do you think could reduce the number of asteroids available for collisions if collisions do happen sometimes? Any guesses?
Sure:
Obviously, it is uncommon for large amounts of material to be transported around in this way, and something like the Moon is probably rare in the universe, but smaller impacts are more common. Given the physical evidence and theoretical support, it doesn't make sense to dismiss the idea out of hand.
There's
"Is it just me, or does the idea of meteors kicking stuff *off the earth* not pass the laugh test?"
Only a tiny fraction of the original mass need reach escape velocity to allow bacteria to escape (they're fairly small compared to some of these objects after all). If the moon formed from ejecta from a large impact (as seems to be the case), is it so hard to believe that objects a tiny fraction of that size reached escape volocity?
"If you know of a motherboard with SATA that'll take a CPU that can be passively cooled and has open source drivers for everything, I'd like to hear about it, as I plan to build a bigger server this year."
In the enlarged picture of the board, you can clearly see two SATA ports at the bottom right.
"Firewire is a capable interface, and IP traffic is one of its capabilities.
It works with a Firewire cable, peer-to-peer, between two Macs and
at 400 Mbit/sec it's sometimes an improvement on crossover-cable-Ethernet."
This isn't very useful for what many of us will use a VIA machine for, and that is firewalling. To provide firewall service to a LAN, a second ethernet port is required. That's fine for a home LAN or small office, but larger networks will require multiple APs even if they're wireless, and that's much easier to do with an ethernet network. It can need more than 2 network ports if there's more than one network segment or other requirements (see below), and the PCI card can handle a 4-port NIC. VIA also generally has a version of the board with two network interfaces, and that plus a single-port NIC is pretty cheap. Also, a Firewire 400 port will typically not be that much faster than a 100 megabit ethernet port, even though the bitrate is nominally faster. While Firewire can handle faster speeds, the nature of IP traffic keeps it from reaching its potential.
An example of a network setup that would need more ethernet ports would be a site that has multiple network segments. You may have different departments, have some servers that you want to isolate, or a wireless and wired network that you want to isolate. You might also want a firewall cluster with failover capability, as is possible on OpenBSD (pfsync + carp), where an additional network interface is required.
Basically, a mini can be adequate for firewalling purposes if the requirements are simple enough, but a VIA machine is much more capable in that role. It's also much cheaper, so you can get yourself a firewall cluster for what a single mini would cost you.
In summary, a mini isn't necessarily totally useless as a firewall, but a VIA machine will be much more useful for demanding situations.
"Bwah? That's the most interesting part, to me. I mean, they MUST have had that sucker plugged into a surge protector. From where did the energy appear?"
It says they used a steel wire instead of tungsten, and iron fusion is endothermic... but there's carbon and other stuff present, and the containment vessel probably has other stuff.
Strange though.
Indeed.
I'm torn. C and C++ are too complex and expose too much. Java is too pedantic and large (at least the API is), yet Python and other similar languages are too permissive.
Pascal is pretty reasonable. It has the benefit of not being that useful by itself, so you have to broaden your horizons a bit, but structured enough that it won't teach bad habits.
"My only minor nit, isn't C a subset of C++?"
Mostly. There's a few conflicts.
But I don't think C is a good beginner's language either. Best to teach someone how to code in an environment where they don't have to worry about other stuff like pointers.
Once they know how to code, then they can learn other concepts like pointers.