5GHz is great, especially if they can keep the leakage to a manageable level, but what DRAM and interconnect technology do they have to keep these chips fed with instructions and data? What good is 5GHz if half the cycles are spent stalled waiting for an L2 miss to come back from DRAM or another chip's L2? Increasing L2 cache size can help but it's not a panacea.
The entire point of mobile phones is convenience. If we wanted 100% reliability, no one, ever, would own a mobile phone. Let's forget about the handsets - consumer-grade semi-private radio networks are unreliable. Note that I said consumer-grade; private radio networks for emergency response teams, police, fire, etc are, in fact, reliable, but they probably cost much more per subscriber. Anyway, if reliability was everyone's concern, we'd all be using payphones and maybe pagers, and mobile phones would be a niche market or maybe relegated to 3rd world nations that don't have the existing land-line infrastructure. The entire market is built around this principle of convenience.
With that said, I found brick phones to be a huge pain in the ass. I hated that I had to lock the keypad if I didn't want my phone to dial out while in my pocket. I hated the size and shape of the phones themselves. I hated the stubby little antenna that ripped a hole in my jeans. And guess what - these are all convenience things. With an entire market built around convenience, why would I settle for a brick phone that pisses me off and is inconvenient to me? The fact that my phone drops a call every so often or the phone breaks if I drop it (which is basically my own fault) is just not as important as the convenience of not having to carry around a heavy brick that pokes my jeans and dials random numbers. If your market surveys asked people why they own a mobile phone in general, you'd find convenience (and I guess maybe safety) would be at the top of those lists. It's at the top of mine, anyway, and that's why I have my (in your words) unreliable, flaky Motorola clamshell.
Microsoft is releasing its Live Search Books, a rival to Google's Book Search, in test, or beta, version in the US.
I seriously think that people reading Slashdot know what "beta" means. Especially considering the "tagging beta" phrase that appears below every article summary. You can just say "beta" next time. Thanks.
I'm not going to be stupid and claim that all of Intel's performance gains in C2D come from this, but consider:
Intel puts twice as much L2 cache on their dies as does AMD for their high-end parts. The high-end Intel part has 4MB, the high-end AMD part as 1MB per core for a total of 2M.
Intel's L2 cache architecture is "shared", meaning that when you're running a single-thread benchmark, the single core on which the benchmark is running basically has access to the entire 4M L2. This is significant because it now means the single core running on an Intel part has 4M of L2, whereas on AMD it has 1M. This is quite a nice feature for Intel's single-thread performance.
In 32-bit x86 mode, there are 8 general purpose registers (GPRs). That means spill/fill code (which certainly hits in L2 and almost certainly hits in L1) is a lot more common. In other words, memory ops are more common. Intel, with the C2D, introduced a more aggressive out-of-order memory architecture, basically allowing any memory op, even with an unresolved address, to execute out of order, fixing it up later if there was a problem. This really, really helps with memory ops, especially the common spill/fill ones going to the (cached) stack. In 64-bit AMD64/EM64T code, there are more GPRs for the compiler to play with, so you have less spill/fill code and fewer memory ops, which mitigates C2D's advantage here. That's one of my theories on why 64-bit performance of AMD vs. Intel chips is closer (the other, which isn't a theory, is Intel's lack of a 64-bit-capable IOMMU, causing the OS to use bounce buffers for DMA to high-addressed main memory).
What I'm basically saying here is, C2D's larger cache and more-aggressive load/store architecture are really helping it for certain apps. My guess is that the libtomcrypt benchmarks are run in 64-bit mode (mitigating Intel advantage point #3 above) and either a) fit entirely in the L1 or L2 of both processors, nullifying any cache advantage C2D has, or b) fit in *neither* of the L2 caches, and is significantly larger than 4MB, which lets AMD's faster on-die memory controller make up for its lack of L2.
The maximum resolution you can get is completely dependent on how the video card BIOS sets up the flat-panel DVI control registers (for timings I think). The nv driver cannot do it - it doesn't know how, apparently. You, like some others I've seen on forums, are fortunate to have a video BIOS that programs panel sizes all the way to 1920x1200 DVI. My video card BIOS only sets up a maximum panel size of 1280x1024, and because the nv driver can't change these settings, I'm stuck. My options are to run my panel at 1280x1024 DVI with the nv driver, 1600x1200 VGA with the nv driver, 1600x1200 DVI with the proprietary driver, or get a new video card - I don't know anything about ATI, and if I got an nVidia card, I'd have to pray that its BIOS is like yours.
The guy having problems with the proprietary driver must be having another issue, possibly an incorrect modeline or something. I can absolutely get 1600x1200 DVI with the proprietary driver.
This is crap. First, I don't know how many people run their normal, local user account as root. I sure don't. Second, look at any of the Windows XP exploits that are available (Windows XP being a personal system, not a server) that turn those systems into spambots, members of a distributed DoS net, or identity theives. Third, whenever exploits are found on XP, everyone on Slashdot jeers at XP and how insecure it is, but when this exploit surfaces that affects single-user Linux systems, it's "zero impact". I'm no Windows fan, but this is pure Slashdot fanboyism.
The reason I use the closed-source binary blob driver is because the 'nv' driver can't program my flat-panel monitor to accept a 1600x1200 DVI signal. I have to use my glorious 20.1" panel in 1280x1024 mode or hook up the old VGA cable to get a 1600x1200 signal. Here's the thread about how the 'nv' driver depends on the video card BIOS to program up the flat panel registers:
Ben Sander is actually a lead for one of the Performance Modeling team at AMD, meaning he's a hardcore CPU architect, not a "media presenter". It just so happens that because he's the lead, he gets to present his team's findings at media and conference events.
People have been doing this in academia for at least 10 years. No one has made an actual processor that supports it, and it might be incredibly complex, but it's not impossible. Read the following papers and you'll find answers to all the questions that the Ars articles posed.
Right on, man. I posted something similar a few weeks ago and got blasted by all the hardware people that say "hardware will always be faster". Maybe, but 1) eventually software will be "fast enough", 2) especially when we'll be able to throw 32 cores at the job.
But since this is/. versus Intel, everything has to be a joke, right?
Look dude, it took 10 years and K8 for people to stop calling AMD's products "crappy Intel clones", despite K7 being a pretty decent chip. It's going to take at least a few years before people, especially Slashdot, get over NetBurst and Itanium.
Sure, you might get 200fps on a current generation game, but if we want to increase the resolution by a factor of 4 (not inconceivable) then you're back down to 50fps.
The traditional way graphics cards increase rendering bandwidth is by throwing more pixel pipes onto the card. Rendering graphics is "embarrassingly parallel", which means that, literally, you can double your execution resources and get basically double the performance. This scalability would apply to properly-written (i.e., threaded) software-based rendering engines running on a multicore system as well. If we're all going to be running 8-core systems in 2 years, we get to throw multiple cores at the job. It's the same principle, and as long as we're upgrading our CPUs, we might as well put them to use.
Dedicated hardware is more cost effective for a given task than a general purpose processor. Why waste your expensive general purpose CPU on a fairly repetitive single purpose task that can be performed more quickly by a dedicated processor that's half the cost?
The short answer to this is "because we can." If we're all running 8-core systems, we're going to have 4-6 "spare" cores anyway. It's not a matter of waste, it's a matter of using what the CPU people give us. And what they're giving us nowadays, and for the forseeable future, is more cores. And to turn around the cost-effective argument - when we all have 32GB of RAM in our systems, why spend more money to put another 2GB on a video card when the extra 6 cores that we're using for graphics rending have access to 32GB for "free"? Seems like a big power drain, too.
Seriously, I understand the argument of dedicated hardware vs. general purpose CPUs. I really do. I'm talking about having the same performance scalability with much lower costs.
Alright, you probably do have a point - specialized hardware is certainly faster than software on a CPU. But at some point, things happen "fast enough". If you have an OpenGL-based game that delivers 200fps using 1 out of the 8 CPU cores, who cares if a graphics accelerator card can deliver 300fps? Especially if the software is millions of dollars cheaper to produce? That's the point I'm trying to make here. Specialized hardware has its place for things that absolutely have to happen as fast as possible, that general-purpose CPUs aren't good enough for yet. But I say "yet" because I believe, at some point, that eventually they will be good enough.
There have been a good amount of articles recently on Slashdot about specialized hardware to improve performance. Here's my prediction: all these specialized hardware cards are going to die a quick death once we move to quad-core or eight-core chips running HyperTransport or whatever next-gen interconnect Intel is cooking up. Killer NIC, physics processors, even graphics accelerators. Here's why:
Each core can handle one of these tasks much faster than specialized hardware. Got 8 cores? Let one of them handle the networking stack, one of them handle the physics engine, two or three or four handle rendering. That leaves 2 cores for general processing.
General-purpose CPUs are cheaper and easier to program than developing hardware in-house. ATI or nVidia or Ageia or whoever makes Killer NIC would develop very simple hardware (an Ethernet PHY, or a basic framebuffer), and then hire a bunch of driver developers to write C code to process their stuff in software, in a driver. Modern x86 CPUs can crank through a lot of this stuff just as fast if not faster than the dedicated hardware, especially with vector instructions (SSE).
The only problem with an approach like this is that if all these hardware drivers have to run in the kernel, the companies had better write bulletproof kernel code. Fortunately, networking stacks are already pretty bulletproof. Rendering and physics engines would have to get there. Other approaches to solving this problem - userspace drivers, maybe some sort of driver isolation - exist, but these add overhead. But I still think the cost and complexity of writing drivers is much cheaper than developing hardware, and I think some overhead for protection could be paid and you'd still see better performance.
AMD alluded to this convergence in its talk when it announced its acquisition of ATI. It's still 10 years away, but I believe it's going to happen.
Install Tab Mix Plus, which has an Undo Close Tab feature that lets you restore closed tabs (10 closed tabs are preserved and available to be un-closed by default).
You can install Tab Mix Plus for FF 1.5 and have it give you close buttons on each tab. Actually, I have it set up so "Middle click on tab" closes the tab. That way you get the even better functionality than the red X (since you can position the mouse anywhere on the tab and middle click), and you don't have red X's cluttering up your tab bar. But anyway, this is right now in FF 1.5.
Is it at all possible that the Earth's magnetic field is oscillating, however small the amplitude of the oscillations, at some reasonable rate, and that they have exactly matched the frequency of the oscillations with their coil motion so as to obtain some sort of alternating energy/voltage/current? Perhaps the amplitude of the oscillations is magnified by the upcoming N-S pole switch? I know I'm grasping at straws here, but might it be possible?
After thinking about it more, I agree that it's possible. However, the overall tone of your post seemed to indicate only a multi-threaded model, not a single-thread, out-of-order execution model.
Basically what you're proposing is taking the single-stack ISA and converting it, internally, to a multiple-stack execution model (sort of analogous to how current processors convert the architectural registers into physical registers. sort of.). I'll agree that this is possible; however, how exactly is this faster/better than current register-based processors? You'd still have the rename, scheduling, and reorder buffer logic, so there goes any complexity/power argument. And stack swap operations only exist because the instructions (say, subtract) only operate on the top few elements of the stack (say, M[top-of-stack] - M[top-of-stack - 1]), and so those are actually overhead operations when compared with the register-based model. I have yet to hear a convincing argument for building such a processor.
how many out of order processes...It would need to be able to implement rapid task switching
The parent was referring to out-of-order execution of a single thread/process, not multiple threads/processes. OoO execution is something that mainstream microprocessors have done since the Pentium Pro. A stack-based instruction set (ISA) basically precludes any sort of out-of-order execution of individual instructions, because every instruction is directly dependent on the one before it (basically, every instruction is dependent on both the value at the top of the stack AND the top-of-stack pointer). When every instruction is dependent on the one before it, the ONLY thing a microprocessor can do is execute the very next instruction. It can't "look ahead" in its instruction window to find independent instructions to execute out-of-order because there aren't any.
The upshot of this is, a stack-based microprocessor is stuck executing instructions in-order. This is very slow compared to out-of-order execution. Now, you've inadvertantly brought up a decent point: with the multi-core CPU trend upon us, and assuming software ever gets parallel enough (it's not even close right now), maybe it would be better to have 32 or 64 cheap, low-power, in-order, stack-based CPU cores on a single die. But that's 10-15 years away. For now, OoO cores kill in-order cores.
You *have* to know that the current model is not sustainable.
The "limited commodity" model only lasts until supply catches up with demand. And in this case, the resource is not limited by some sort of natural phenomenon, only by the market. Eventually the ISPs and backbone providers will figure out how to offer fast-enough links/big-enough pipes for a reasonable cost. They did it with phone service, both local and long distance back in the 80s - eventually they built enough capacity for it. I don't see why we won't get there with broadband - eventually it will be "fast enough" to stream HD video, and that will be that.
Are you claiming that this will never happen and the supply will never catch up to the demand? That's what it seems like, so correct me if I'm misinterpreting. Maybe we'll have to endure 10 years of high prices or exorbitant per-GB fees, but they'll come down. I really don't see anything preventing it other than time.
Conroe is a next-generation architecture, built on a next-generation process. AM2 is K8. You totally missed the point I made, but that's okay, this is Slashdot.
You truly are a broken record. The K8 architecture is over two years old. Lots of things can happen in 2 years, including 1) Intel coming out with a processor with new power-saving and performance features, and 2) Intel moving to 65nm processes. Please stop comparing Intel's new processors with 2-year-old AMD processors as if AMD's were brand new as well.
I've already given the performance and performance/watt crown to Intel (and to you, in a response in a previous topic) for the next year or two. Will AMD come out with something competitive in the next 2 years? We'll have to wait and see.
Slashdot Mirror
My god, can the mods not spot troll/flamebait posts at all?
Anyone have an answer?
With that said, I found brick phones to be a huge pain in the ass. I hated that I had to lock the keypad if I didn't want my phone to dial out while in my pocket. I hated the size and shape of the phones themselves. I hated the stubby little antenna that ripped a hole in my jeans. And guess what - these are all convenience things. With an entire market built around convenience, why would I settle for a brick phone that pisses me off and is inconvenient to me? The fact that my phone drops a call every so often or the phone breaks if I drop it (which is basically my own fault) is just not as important as the convenience of not having to carry around a heavy brick that pokes my jeans and dials random numbers. If your market surveys asked people why they own a mobile phone in general, you'd find convenience (and I guess maybe safety) would be at the top of those lists. It's at the top of mine, anyway, and that's why I have my (in your words) unreliable, flaky Motorola clamshell.
I seriously think that people reading Slashdot know what "beta" means. Especially considering the "tagging beta" phrase that appears below every article summary. You can just say "beta" next time. Thanks.
- Intel puts twice as much L2 cache on their dies as does AMD for their high-end parts. The high-end Intel part has 4MB, the high-end AMD part as 1MB per core for a total of 2M.
- Intel's L2 cache architecture is "shared", meaning that when you're running a single-thread benchmark, the single core on which the benchmark is running basically has access to the entire 4M L2. This is significant because it now means the single core running on an Intel part has 4M of L2, whereas on AMD it has 1M. This is quite a nice feature for Intel's single-thread performance.
- In 32-bit x86 mode, there are 8 general purpose registers (GPRs). That means spill/fill code (which certainly hits in L2 and almost certainly hits in L1) is a lot more common. In other words, memory ops are more common. Intel, with the C2D, introduced a more aggressive out-of-order memory architecture, basically allowing any memory op, even with an unresolved address, to execute out of order, fixing it up later if there was a problem. This really, really helps with memory ops, especially the common spill/fill ones going to the (cached) stack. In 64-bit AMD64/EM64T code, there are more GPRs for the compiler to play with, so you have less spill/fill code and fewer memory ops, which mitigates C2D's advantage here. That's one of my theories on why 64-bit performance of AMD vs. Intel chips is closer (the other, which isn't a theory, is Intel's lack of a 64-bit-capable IOMMU, causing the OS to use bounce buffers for DMA to high-addressed main memory).
What I'm basically saying here is, C2D's larger cache and more-aggressive load/store architecture are really helping it for certain apps. My guess is that the libtomcrypt benchmarks are run in 64-bit mode (mitigating Intel advantage point #3 above) and either a) fit entirely in the L1 or L2 of both processors, nullifying any cache advantage C2D has, or b) fit in *neither* of the L2 caches, and is significantly larger than 4MB, which lets AMD's faster on-die memory controller make up for its lack of L2.The guy having problems with the proprietary driver must be having another issue, possibly an incorrect modeline or something. I can absolutely get 1600x1200 DVI with the proprietary driver.
This is crap. First, I don't know how many people run their normal, local user account as root. I sure don't. Second, look at any of the Windows XP exploits that are available (Windows XP being a personal system, not a server) that turn those systems into spambots, members of a distributed DoS net, or identity theives. Third, whenever exploits are found on XP, everyone on Slashdot jeers at XP and how insecure it is, but when this exploit surfaces that affects single-user Linux systems, it's "zero impact". I'm no Windows fan, but this is pure Slashdot fanboyism.
https://bugs.freedesktop.org/show_bug.cgi?id=3654
"The "nv" driver currently can't change the BIOS-programmed display timings. Unfortunately, this is not something that we can fix right now."
This just sucks, IMHO.
Ben Sander is actually a lead for one of the Performance Modeling team at AMD, meaning he's a hardcore CPU architect, not a "media presenter". It just so happens that because he's the lead, he gets to present his team's findings at media and conference events.
http://www.eecg.toronto.edu/~moshovos/ACA05/read/A kkary.1998.MICRO.pdf T R2208.pdf s calar.pdf
http://www.crhc.uiuc.edu/~mfrank/pubs/Malik-2006-
ftp://ftp.cs.wisc.edu/sohi/papers/1995/isca.multi
Right on, man. I posted something similar a few weeks ago and got blasted by all the hardware people that say "hardware will always be faster". Maybe, but 1) eventually software will be "fast enough", 2) especially when we'll be able to throw 32 cores at the job.
But since this is /. versus Intel, everything has to be a joke, right?
Look dude, it took 10 years and K8 for people to stop calling AMD's products "crappy Intel clones", despite K7 being a pretty decent chip. It's going to take at least a few years before people, especially Slashdot, get over NetBurst and Itanium.
The traditional way graphics cards increase rendering bandwidth is by throwing more pixel pipes onto the card. Rendering graphics is "embarrassingly parallel", which means that, literally, you can double your execution resources and get basically double the performance. This scalability would apply to properly-written (i.e., threaded) software-based rendering engines running on a multicore system as well. If we're all going to be running 8-core systems in 2 years, we get to throw multiple cores at the job. It's the same principle, and as long as we're upgrading our CPUs, we might as well put them to use.
Dedicated hardware is more cost effective for a given task than a general purpose processor. Why waste your expensive general purpose CPU on a fairly repetitive single purpose task that can be performed more quickly by a dedicated processor that's half the cost?
The short answer to this is "because we can." If we're all running 8-core systems, we're going to have 4-6 "spare" cores anyway. It's not a matter of waste, it's a matter of using what the CPU people give us. And what they're giving us nowadays, and for the forseeable future, is more cores. And to turn around the cost-effective argument - when we all have 32GB of RAM in our systems, why spend more money to put another 2GB on a video card when the extra 6 cores that we're using for graphics rending have access to 32GB for "free"? Seems like a big power drain, too.
Seriously, I understand the argument of dedicated hardware vs. general purpose CPUs. I really do. I'm talking about having the same performance scalability with much lower costs.
Alright, you probably do have a point - specialized hardware is certainly faster than software on a CPU. But at some point, things happen "fast enough". If you have an OpenGL-based game that delivers 200fps using 1 out of the 8 CPU cores, who cares if a graphics accelerator card can deliver 300fps? Especially if the software is millions of dollars cheaper to produce? That's the point I'm trying to make here. Specialized hardware has its place for things that absolutely have to happen as fast as possible, that general-purpose CPUs aren't good enough for yet. But I say "yet" because I believe, at some point, that eventually they will be good enough.
The only problem with an approach like this is that if all these hardware drivers have to run in the kernel, the companies had better write bulletproof kernel code. Fortunately, networking stacks are already pretty bulletproof. Rendering and physics engines would have to get there. Other approaches to solving this problem - userspace drivers, maybe some sort of driver isolation - exist, but these add overhead. But I still think the cost and complexity of writing drivers is much cheaper than developing hardware, and I think some overhead for protection could be paid and you'd still see better performance.
AMD alluded to this convergence in its talk when it announced its acquisition of ATI. It's still 10 years away, but I believe it's going to happen.
Install Tab Mix Plus, which has an Undo Close Tab feature that lets you restore closed tabs (10 closed tabs are preserved and available to be un-closed by default).
You can install Tab Mix Plus for FF 1.5 and have it give you close buttons on each tab. Actually, I have it set up so "Middle click on tab" closes the tab. That way you get the even better functionality than the red X (since you can position the mouse anywhere on the tab and middle click), and you don't have red X's cluttering up your tab bar. But anyway, this is right now in FF 1.5.
Is it at all possible that the Earth's magnetic field is oscillating, however small the amplitude of the oscillations, at some reasonable rate, and that they have exactly matched the frequency of the oscillations with their coil motion so as to obtain some sort of alternating energy/voltage/current? Perhaps the amplitude of the oscillations is magnified by the upcoming N-S pole switch? I know I'm grasping at straws here, but might it be possible?
After thinking about it more, I agree that it's possible. However, the overall tone of your post seemed to indicate only a multi-threaded model, not a single-thread, out-of-order execution model.
Basically what you're proposing is taking the single-stack ISA and converting it, internally, to a multiple-stack execution model (sort of analogous to how current processors convert the architectural registers into physical registers. sort of.). I'll agree that this is possible; however, how exactly is this faster/better than current register-based processors? You'd still have the rename, scheduling, and reorder buffer logic, so there goes any complexity/power argument. And stack swap operations only exist because the instructions (say, subtract) only operate on the top few elements of the stack (say, M[top-of-stack] - M[top-of-stack - 1]), and so those are actually overhead operations when compared with the register-based model. I have yet to hear a convincing argument for building such a processor.
how many out of order processes...It would need to be able to implement rapid task switching
The parent was referring to out-of-order execution of a single thread/process, not multiple threads/processes. OoO execution is something that mainstream microprocessors have done since the Pentium Pro. A stack-based instruction set (ISA) basically precludes any sort of out-of-order execution of individual instructions, because every instruction is directly dependent on the one before it (basically, every instruction is dependent on both the value at the top of the stack AND the top-of-stack pointer). When every instruction is dependent on the one before it, the ONLY thing a microprocessor can do is execute the very next instruction. It can't "look ahead" in its instruction window to find independent instructions to execute out-of-order because there aren't any.
The upshot of this is, a stack-based microprocessor is stuck executing instructions in-order. This is very slow compared to out-of-order execution. Now, you've inadvertantly brought up a decent point: with the multi-core CPU trend upon us, and assuming software ever gets parallel enough (it's not even close right now), maybe it would be better to have 32 or 64 cheap, low-power, in-order, stack-based CPU cores on a single die. But that's 10-15 years away. For now, OoO cores kill in-order cores.
http://www.ussg.iu.edu/hypermail/linux/kernel/9906 .0/0746.html
He is, of course, referring to all the research in the '80s and '90s on microkernels and IPC-based operating systems.
The "limited commodity" model only lasts until supply catches up with demand. And in this case, the resource is not limited by some sort of natural phenomenon, only by the market. Eventually the ISPs and backbone providers will figure out how to offer fast-enough links/big-enough pipes for a reasonable cost. They did it with phone service, both local and long distance back in the 80s - eventually they built enough capacity for it. I don't see why we won't get there with broadband - eventually it will be "fast enough" to stream HD video, and that will be that.
Are you claiming that this will never happen and the supply will never catch up to the demand? That's what it seems like, so correct me if I'm misinterpreting. Maybe we'll have to endure 10 years of high prices or exorbitant per-GB fees, but they'll come down. I really don't see anything preventing it other than time.
Conroe is a next-generation architecture, built on a next-generation process. AM2 is K8. You totally missed the point I made, but that's okay, this is Slashdot.
You truly are a broken record. The K8 architecture is over two years old. Lots of things can happen in 2 years, including 1) Intel coming out with a processor with new power-saving and performance features, and 2) Intel moving to 65nm processes. Please stop comparing Intel's new processors with 2-year-old AMD processors as if AMD's were brand new as well.
I've already given the performance and performance/watt crown to Intel (and to you, in a response in a previous topic) for the next year or two. Will AMD come out with something competitive in the next 2 years? We'll have to wait and see.