Its all child's play compared to 4x5 large-format photography. I think it will be a long time before they are able to manufacture a 4x5" CCD or CMOS sensor economically. If they do, well then it will probably slide into the back of my view camera like sheet film, polaroid holders, and roll-film holders.
However the right digitoy makes a nice light meter.
Actually I believe you are wrong here. Intel split the reorder-buffer in half, split the physical register file in half, and fetches from each thread every other cycle. If I am not mistaken, the latter point means that each thread gets equal execution resources as once instructions have been fetched and decoded, dispatch and execute don't care which thread an instruction belongs too. Like I said, I think this is the case but am not sure.
From my friends in the architecture community, Intel's SMT implementation is sort of half-assed.
On the other hand, IBM's Power5 also fetches from each thread every other cycle, however it shares a reorder buffer physically (but of course not logically).
Fr'instance, I have a Thinkpad 600 with 64 MB of RAM. The thing is just sitting in a box right now because I've been unable to find a distribution that will run gracefully on this machine.
I had no problems installing Slackware 9.1 on my Pentium166 w/ 80MB or RAM. It makes a fine X-terminal (fvwm) and MP3 player. Hell the soundcard is an ISA Turtle Beach Tropez from like 1992.
But it is a big deal. First of all, a lengthened pipeline will result in more costly branches. As a result, more transistors will be required to beef up the branch prediction + cache. And all these extra transistors will add to the power consumption and manufacturing cost of the chip. So you end up with a chip that uses far more transistors then an equivalent chip with a smarter instruction set / design (just compare transistor counts between the P4ee, Power, and Athlon64 of the same speed - the extra long pipeline of the P4ee hurts).
The micro-op cracking uses less than 5% of the transistor budget. Plus the P4 trace cache stores decoded micro-ops (not CISC instructions).
As far as branch mispredictions, you have a point. A longer pipeline can make the penalty greater. However the P4 also uses selective replay to mitigate this. This combined with the effectiveness of the trace cache makes the branch misprediction penalty much smaller than you might think.
What I find interesting is the way in which the Itanium gets around the problem of branches. We're all aware that the majority of conditional branches seem to be for loops or skipping small sections of code. By allowing for conditional execution of code, they can get rid of all the JMP three lines down instructions and make it so that there is less pipeline blocking going on.
Predication is not a new idea. ARM has been doing it since the 80s.
The x86 chips crack the CISC instructions into RISC-like micro-ops in hardware....so it burns a couple million transistors and lengthens the pipe. Big deal.
Hence there is really no major difference between a "pure" RISC chip such as Power, and a IA-32 chip such as Athlon. Both are superscaler, out-of-order processors.
Itanium's EPIC instruction set you say? Well that was just a bad idea and solves many of the problems from the 80s. The ALAT has been studied and shown to be useless. The problem nowadays is memory latency. A tricked-out ISA will not help much with memory latency on a cache miss. However very large caches do, which is why Itanic does well on SPEC benchmarks. This is also why Itanic costs so darn much as the yields are probably terrible due to the huge chip. Put a 8mb L3 cache on a Xeon and see it outperform Itanium. Of course Intel won't do that for cost and saving-face reasons.
How can netgear expect people to trust them again, is there any way to repair their reputation?
I would guess that greater than 99.999% of NetGear's customer base doesn't read Slashdot. Hence their reputation will stay intact as long as retail stores keep carrying their products.
Yes. In the early 1990s, revenue for cellular service was a fraction of what it is today. Nowadays, financing GSM in sparsely populated areas is feasible. While the U.S. was pondering the switch to GSM, the situation was different.
...that it's a very small island, just put big transmitters on mountantops and you're good to go
Actually this is not funny. The United States is, for the most part, sparsely populated compared to most of Europe and Asia. This is why the U.S. carriers hesitated to adopt GSM in the early 90s, which has a fixed number of supported users/frequency and has a maximum cell size due to being time multiplexed. On the other hand, CDMA is able to create much larger cells at the expense of a higher noise floor (hence less users). It was promised to be better suited to sparsely populated areas, yet still tuneable to suit New York City and etc. Whether or not CDMA IS-95 met those goals is debateable.
Japan is indeed under less contraints. Their cell sizes are very small meaning the required transmission power is reduced. If anybody ever saw a Japanese PDC phone from 10 years ago, and was blown away at how small it was, this is the explanation.
I just asked my brother-in-law, who is computer savvy, why he doesn't have encryption enabled on his home access point.
His answer: "unless some guy decides to enter my property and sit on my front porch with his laptop, my weak signal is all the security I need". He claims he's tested it with several laptops and the signal is too weak to be used beyond 10 feet away from his house.
Slower for single-threaded cache-bound apps, absolutely. But Sun hardware has superior multiprocessor performance, scalability, and memory bandwidth. It is also far more reliable. I point you to this anecdotal story about what happened when photo.net moved from Sun to Dell hardware.
Their OS is less feature rich, but has more bugs, and doesn't perform as well in most cases as Linux.
Oh man, Solaris has far more enterprise features than Linux. Intimate shared memory, a performance counter interface, hot-swappable CPU support, a solid device driver interface, the list goes on and on. And the future is multiprocessors...Sun has a huge advantage with Solaris as it readily scales beyond 100 processors out-of-the-box. The Linux stock kernel scales to what, 8 processors maybe, until falling flat on its face due to lock contention.
I've tried WTL. It seems great for small, stand-alone executables. However the learning curve is sort of high and you really need to know a bit about ATL. The documentation also isn't near as complete as MFC (even though MFC is ugly).
That being said, the best way to create GUIs in Windows nowadays is to use Windows Forms either in C# or C++. Compared to MFC/WTL/whatever, its a dream come true.
Of course, as many people who debug multi-threaded programs have found, using print routines to output logs can make the bug 'go away', because quite often CRT functions like printf() etc are mutex'd, which serialises code execution, and thus alters the timing, and voila, race condition begone!
Of course. A good data-logger design does not call expensive output routines in the timing sensitive threads. The routines should be low-cost and append information to some kind of shared memory block such that low-priority threads occasionally format and spit them out to your output device.
Don't trivialize the data logging approach to debugging.
In complex, multi-threaded systems where you are debugging timing events more often than programmer logic, data logging (aka print statements) is probably the only technique that works.
In fact, one of the first things we implement in embedded systems is a data logger that can spit out your print statements over RS232. Yes, we can single-step through code using in-circuit emulators and JTAG interfaces, however I found this rarely useful.
Ir ecently spoke with a Patent Attorney. A patent usually gets only 7-14 hours of review at the USPTO. This is hardly enough time to read some of these patents.
The Attorney said that of the 6.5 million patents, given enough time and money, he could narrow it down to definitely less than 1 million by invalidating the rest.
Its the way things work. A patent is nothing...it is the litigation that counts. And litigation is a multi-million dollar affair catored towards large companies.
They will slowly lose more and more to the PPC based systems and better OSes (Linux/MacOS X).
Better OSes? Solaris is arguably the best Unix OS in existance. If you think that Linux is "better", and it may be for your needs, I urge you to think again. The key to Solaris is its scalability. It scales to hundreds of processors. This is key for throughput computing, and you will see Sun come out with chips that have a dozen or so UltraSparcs on the same core in the near future.
Yes pundants, point me to the links about Linux running on 500 processors. I frankly don't beleive that a single Linux kernel image can run on 500 processors. I mean it still uses test, test-and-set spinlocks!
I totally agree that Microsoft *and Intel* have retarded the state of the art by at least 15 years. There have been so many other worthwhile, efficient CPU architectures (MIPS, Alpha, 680x0) that have gone by the wayside, while the bloated hulk of x86 keeps rolling on.
With respect to Intel, this is utter BS. Intel burns so little of their transistor budget on cracking the IA-32 instruction set to RISC-like instructions that the ISA is really meaningless. You don't need lots of registers...L1 cache accesses are a single cycle. I've read armchair architects on slashdot say "but with so few registers, the processor will always execute all those extra instructions to spill/fill". I have 2 counter arguments:
1) Studies have shown that 80% of functions, in SPEC benchmarks, use less than 8 registers
2) Nowadays, with memory systems being all that matters, the spill/fill to the stack (which nearly always hits in the cache) is peanuts. Amdahl's law baby. With a 300-cycle access penalty to DRAM, and the possibility of retiring 3 instructions per cycle on Athlon and P4 chips, a single L2 miss can result in 1000 wasted opportunities to retire an instruction.
Without having Java as an internal closed system, Sun will have nothing left that a competitor can't provide. Sun is grasping onto Java like a sailor in a wild storm; Everything Sun is planning rests on Java. I hope they can make something good out of it. Even though Sun is an old company that has only recently begun to change, it'd be sad to see them go the way of the dinosaurs. They're one of the old guard, along with Big Blue, so I for one hope they can stay afloat.
Just because Sun might be older than you, it is not "an old company"!! Sun has billions of cash and makes hardware that will always serve a niche market. Their servers are still far more reliable than Dell. Need testimony to this? Check out what photo.net is going through by switching from Sun to Dell:
As an engineer who has dealt and interviewed with numerous companies, I've seen Sun Workstations inside some pretty demanding apps such as Air Traffic Control systems and MRI machines. Granted the volume of these things are quite low, but as long as Sun is making hardware, people will buy it.
Slashdot Mirror
Well, the US didn't need GPS to surrender in Vietnam, so I guess you don't need it at all!
Troll. The U.S. never lost a single major battle in Vietnam. We lost ~ 50,000 troops compared to over a million North Vietnamese.
The U.S. policy is what failed.
Its all child's play compared to 4x5 large-format photography. I think it will be a long time before they are able to manufacture a 4x5" CCD or CMOS sensor economically. If they do, well then it will probably slide into the back of my view camera like sheet film, polaroid holders, and roll-film holders.
However the right digitoy makes a nice light meter.
2) While it's not an id game, IL2 Sturmovik is a critically-acclaimed fight simulator that was written almost entirely in Java.
Java may be used for some game logic, but the rendering engine is not Java.
Actually I believe you are wrong here. Intel split the reorder-buffer in half, split the physical register file in half, and fetches from each thread every other cycle. If I am not mistaken, the latter point means that each thread gets equal execution resources as once instructions have been fetched and decoded, dispatch and execute don't care which thread an instruction belongs too. Like I said, I think this is the case but am not sure.
From my friends in the architecture community, Intel's SMT implementation is sort of half-assed.
On the other hand, IBM's Power5 also fetches from each thread every other cycle, however it shares a reorder buffer physically (but of course not logically).
Fr'instance, I have a Thinkpad 600 with 64 MB of RAM. The thing is just sitting in a box right now because I've been unable to find a distribution that will run gracefully on this machine.
I had no problems installing Slackware 9.1 on my Pentium166 w/ 80MB or RAM. It makes a fine X-terminal (fvwm) and MP3 player. Hell the soundcard is an ISA Turtle Beach Tropez from like 1992.
But it is a big deal. First of all, a lengthened pipeline will result in more costly branches. As a result, more transistors will be required to beef up the branch prediction + cache. And all these extra transistors will add to the power consumption and manufacturing cost of the chip. So you end up with a chip that uses far more transistors then an equivalent chip with a smarter instruction set / design (just compare transistor counts between the P4ee, Power, and Athlon64 of the same speed - the extra long pipeline of the P4ee hurts).
The micro-op cracking uses less than 5% of the transistor budget. Plus the P4 trace cache stores decoded micro-ops (not CISC instructions).
As far as branch mispredictions, you have a point. A longer pipeline can make the penalty greater. However the P4 also uses selective replay to mitigate this. This combined with the effectiveness of the trace cache makes the branch misprediction penalty much smaller than you might think.
What I find interesting is the way in which the Itanium gets around the problem of branches. We're all aware that the majority of conditional branches seem to be for loops or skipping small sections of code. By allowing for conditional execution of code, they can get rid of all the JMP three lines down instructions and make it so that there is less pipeline blocking going on.
Predication is not a new idea. ARM has been doing it since the 80s.
RISC vs. CISC is mostly irrelevant.
The x86 chips crack the CISC instructions into RISC-like micro-ops in hardware....so it burns a couple million transistors and lengthens the pipe. Big deal.
Hence there is really no major difference between a "pure" RISC chip such as Power, and a IA-32 chip such as Athlon. Both are superscaler, out-of-order processors.
Itanium's EPIC instruction set you say? Well that was just a bad idea and solves many of the problems from the 80s. The ALAT has been studied and shown to be useless. The problem nowadays is memory latency. A tricked-out ISA will not help much with memory latency on a cache miss. However very large caches do, which is why Itanic does well on SPEC benchmarks. This is also why Itanic costs so darn much as the yields are probably terrible due to the huge chip. Put a 8mb L3 cache on a Xeon and see it outperform Itanium. Of course Intel won't do that for cost and saving-face reasons.
How can netgear expect people to trust them again, is there any way to repair their reputation?
I would guess that greater than 99.999% of NetGear's customer base doesn't read Slashdot. Hence their reputation will stay intact as long as retail stores keep carrying their products.
I don't see how that will guarantee it.. accidents still happen. Tape drives fail. Hard disks get dropped into tubs of jelly, etc.
There is never a guarantee. Its all about reducing probability.
Have you heard of Australia? GSM, pop'n 20mil.
Yes. In the early 1990s, revenue for cellular service was a fraction of what it is today. Nowadays, financing GSM in sparsely populated areas is feasible. While the U.S. was pondering the switch to GSM, the situation was different.
And the data rate for GSM is not 300MBs.
...that it's a very small island, just put big transmitters on mountantops and you're good to go
Actually this is not funny. The United States is, for the most part, sparsely populated compared to most of Europe and Asia. This is why the U.S. carriers hesitated to adopt GSM in the early 90s, which has a fixed number of supported users/frequency and has a maximum cell size due to being time multiplexed. On the other hand, CDMA is able to create much larger cells at the expense of a higher noise floor (hence less users). It was promised to be better suited to sparsely populated areas, yet still tuneable to suit New York City and etc. Whether or not CDMA IS-95 met those goals is debateable.
Japan is indeed under less contraints. Their cell sizes are very small meaning the required transmission power is reduced. If anybody ever saw a Japanese PDC phone from 10 years ago, and was blown away at how small it was, this is the explanation.
I just asked my brother-in-law, who is computer savvy, why he doesn't have encryption enabled on his home access point.
His answer: "unless some guy decides to enter my property and sit on my front porch with his laptop, my weak signal is all the security I need". He claims he's tested it with several laptops and the signal is too weak to be used beyond 10 feet away from his house.
MOD parent up.
Yes, the supports aren't as high but the bridge is still the highest in the world. And its made out of wood!
Their hardware is more expensive, and slower.
Slower for single-threaded cache-bound apps, absolutely. But Sun hardware has superior multiprocessor performance, scalability, and memory bandwidth. It is also far more reliable. I point you to this anecdotal story about what happened when photo.net moved from Sun to Dell hardware.
Their OS is less feature rich, but has more bugs, and doesn't perform as well in most cases as Linux.
Oh man, Solaris has far more enterprise features than Linux. Intimate shared memory, a performance counter interface, hot-swappable CPU support, a solid device driver interface, the list goes on and on. And the future is multiprocessors...Sun has a huge advantage with Solaris as it readily scales beyond 100 processors out-of-the-box. The Linux stock kernel scales to what, 8 processors maybe, until falling flat on its face due to lock contention.
Hmmm... I like the qt widgets from Troll Tech.
One API, many platforms. What's not to like?
Microsoft Visual Studio is cheaper than buying a QT license.
I've tried WTL. It seems great for small, stand-alone executables. However the learning curve is sort of high and you really need to know a bit about ATL. The documentation also isn't near as complete as MFC (even though MFC is ugly).
That being said, the best way to create GUIs in Windows nowadays is to use Windows Forms either in C# or C++. Compared to MFC/WTL/whatever, its a dream come true.
Of course, as many people who debug multi-threaded programs have found, using print routines to output logs can make the bug 'go away', because quite often CRT functions like printf() etc are mutex'd, which serialises code execution, and thus alters the timing, and voila, race condition begone!
Of course. A good data-logger design does not call expensive output routines in the timing sensitive threads. The routines should be low-cost and append information to some kind of shared memory block such that low-priority threads occasionally format and spit them out to your output device.
Don't trivialize the data logging approach to debugging.
In complex, multi-threaded systems where you are debugging timing events more often than programmer logic, data logging (aka print statements) is probably the only technique that works.
In fact, one of the first things we implement in embedded systems is a data logger that can spit out your print statements over RS232. Yes, we can single-step through code using in-circuit emulators and JTAG interfaces, however I found this rarely useful.
Ir ecently spoke with a Patent Attorney. A patent usually gets only 7-14 hours of review at the USPTO. This is hardly enough time to read some of these patents.
The Attorney said that of the 6.5 million patents, given enough time and money, he could narrow it down to definitely less than 1 million by invalidating the rest.
Its the way things work. A patent is nothing...it is the litigation that counts. And litigation is a multi-million dollar affair catored towards large companies.
Nice theory. Except that it is well-known that Google is already profitable and that the two founders are billionaires.
They will slowly lose more and more to the PPC based systems and better OSes (Linux/MacOS X).
Better OSes? Solaris is arguably the best Unix OS in existance. If you think that Linux is "better", and it may be for your needs, I urge you to think again. The key to Solaris is its scalability. It scales to hundreds of processors. This is key for throughput computing, and you will see Sun come out with chips that have a dozen or so UltraSparcs on the same core in the near future.
Yes pundants, point me to the links about Linux running on 500 processors. I frankly don't beleive that a single Linux kernel image can run on 500 processors. I mean it still uses test, test-and-set spinlocks!
There's more than one way to do it!
Its why Perl is so damn confusing.
I totally agree that Microsoft *and Intel* have retarded the state of the art by at least 15 years. There have been so many other worthwhile, efficient CPU architectures (MIPS, Alpha, 680x0) that have gone by the wayside, while the bloated hulk of x86 keeps rolling on.
With respect to Intel, this is utter BS. Intel burns so little of their transistor budget on cracking the IA-32 instruction set to RISC-like instructions that the ISA is really meaningless. You don't need lots of registers...L1 cache accesses are a single cycle. I've read armchair architects on slashdot say "but with so few registers, the processor will always execute all those extra instructions to spill/fill". I have 2 counter arguments:
1) Studies have shown that 80% of functions, in SPEC benchmarks, use less than 8 registers
2) Nowadays, with memory systems being all that matters, the spill/fill to the stack (which nearly always hits in the cache) is peanuts. Amdahl's law baby. With a 300-cycle access penalty to DRAM, and the possibility of retiring 3 instructions per cycle on Athlon and P4 chips, a single L2 miss can result in 1000 wasted opportunities to retire an instruction.
Without having Java as an internal closed system, Sun will have nothing left that a competitor can't provide. Sun is grasping onto Java like a sailor in a wild storm; Everything Sun is planning rests on Java. I hope they can make something good out of it. Even though Sun is an old company that has only recently begun to change, it'd be sad to see them go the way of the dinosaurs. They're one of the old guard, along with Big Blue, so I for one hope they can stay afloat.
_ id=007gj8
Just because Sun might be older than you, it is not "an old company"!! Sun has billions of cash and makes hardware that will always serve a niche market. Their servers are still far more reliable than Dell. Need testimony to this? Check out what photo.net is going through by switching from Sun to Dell:
http://www.photo.net/bboard/q-and-a-fetch-msg?msg
As an engineer who has dealt and interviewed with numerous companies, I've seen Sun Workstations inside some pretty demanding apps such as Air Traffic Control systems and MRI machines. Granted the volume of these things are quite low, but as long as Sun is making hardware, people will buy it.