I can understand not wanting them to plop $80 on an expensive calculator but there's no reason they shouldn't be able to adapt to using a $5 cheapo calculator. They're physics students for god sakes. If they can figure out a programmable TI-89, they can figure out what the x,/, + and - signs do.
Suggest that in order to practice for the exam, they use the calculator and not their graphing ones during homework. And -- this is the most important part -- make sure the test *resembles* the homework in format. As in, "ya, I've done this type of problem using nothing but the four functions before, it's just presented differently here".
Just assign a lot of "suggested" problems such that they have enough source material to practice from. It's easy to say "well you should be able to figure it out if you grasp the concept" but often, professors don't realize how big a leap it is (years of doing that type of problem) to go from concept to answering a realistic question.
ARM just announced a 40-bit extended addressing mode and their roadmap is for a 64-bit extension in 2012. I'm not sure how useful traps are in this day and age.
No, what happened was that the most FP intensive tasks (rendering, 3D modeling for games) moved to another dedicated chip (the GPU). Bigger and better compute capacity there has not stopped being in demand ever since and shows no signs of slowing down.
The only thing left that were really compute intensive on the CPU were things like video transcoding and precise (production quality) 3D rendering due to the lack of double-precision support in GPU's as well as the difficulty of using them for compute (i.e. writing back to memory) purposes. For the vast majority of common consumer tasks, there really wasn't much demand for ever beefier FPU's.
Also, just as what may eventually be true for GPU's, there are advantages performance-wise of moving the FPU closer to the CPU. In the case of the FPU, it was much easier to tie in FP intensive tasks with control structures the CPU provided. I would suspect that in the case of the GPU, it will be removing the latency of the PCI bus and the need to copy memory between main and GPU memory, potentially allowing a lot more interaction between the physics and AI with the rendering process.
I believe Bobcat's 2 FPU paths are 64-bits wide. For a total of 128-bits. It initially will not support the 256-bit AVX instructions that are coming with Sandy Bridge and Bulldozer.
Its ALU's also appear to be significantly different than Bulldozer. With only one of the integer units can support multiplies and only two of them can support arithmetics. Two others (using a different scheduler) are load/store units. Bulldozer doubles the ALU resources (but not the number of schedulers) compared to Bobcat. So each scheduler has access to two AGU's, one ADD/DIV ALU and one ADD/Mult.
I was never a big fan of the 3x symmetric ALU's in the Athlons. When it comes to integer intensive code, having a ton of independent ADDs or MULs that I'd need that kind of parallelism for was rare. And the latency (compared to a sane design like Core at least) were significantly higher due to the units being multi-purpose. In either case, with the introduction of SSE2, one could use SIMD if one had a throughput heavy workload anyway.
Bobcat and Bulldozer appears to have moved in the right direction here. I really do like Bulldozer's approach to multi-core and think that with some extension, this could make into very interesting CPU/GPU hybrids as well. Although you could argue it's just another version of SMT similar to Hyperthreading, only with a wider back-end intended specifically for multi-threaded processes.
The quote you were fanboy-blasting said nothing about price. Technically minded people are concerned about technical features, such as performance and power consumption. And in that, the quote is exactly right. AMD is a generation behind.
I fail to see what the pricing structure for consumer sales has to do with that.
There are plenty of things to learn from Itanium, specifically, what not to do if you want a good general purpose processor. For one, you don't make processor performance so incredibly reliant on instruction scheduling that the biggest compiler team on Earth (Intel's compiler group) couldn't make it run fast on anything except a small subsection of problems.
Secondly, when attempting to gain ISA adoption, making it an exclusive ISA that only you have control and rights to use is a big no no. Sure, it'd be heaven for Intel to be the sole supplier.
And lastly, process and iterations mean more for performance than any fancy ISA. Itanium is consistently one or two process generations behind its x86 counterparts and consistently one or two micro-architectural iterations slower (it takes 2 revisions of the Core micro-arch before Itanium comes out with one).
You can have as clean and fancy of an ISA (which IA-64 was not, btw) as you'd like but implementation matters far far more.
In the end, it wasn't fast enough (the best it ever did was match its x86 counterparts) and it didn't have any other advantages to warrant the switch.
From the paper, it appears they are using 8 states per signal and custom built a Bayesian NAND gate. I have to question whether or not this could've been better achieved (and is being better achieved) with a fully custom 8-bit Bayesian NAND cell.
No but an analog mixer is very much a multiplication unit. Which is what these guys seem like they're trying to improve; a faster math unit to perform probability calculations on fixed-point (with the binary point always at the msb) numbers.
Control systems were analog long before they were digital. But transistors got smaller and smaller and faster and faster (and lower power to boot!) to the point where even today's sub-mW microcontrollers are fast enough to do the calculations in real time (while running an RTOS even!) such that it's not necessary to use an analog circuit. There are just so many advantages (easier maintenance, upgrading, troubleshooting, consistency, configurability) that even if the A/D -> microcontroller -> D/A chain is slower than its analog equivalent, most people choose the former.
Even today's fastest control systems (F-22 fighter flight computer) is an embedded computer hooked up to high-speed ADC's and DAC's.
Forgot your introductory digital design courses already?
I think you forgot your analog circuit class. Functionally speaking, an inverter is no different than a high-gain, rail-to-rail voltage controlled op-amp. It's just far more susceptible to noise and has a very distorted IV curve. The reason digital has taken on so much popularity is that since you're either railing the amplifier to its VDD rail or GND rail and don't care about the in-betweens, you can use very small, very fast and sometimes lower power transistors and not care about how well the transistor performs when amplifying anything in between.
Analog circuits have to have very precise shaping of Vin-to-Vout, Vin-to-Iout, Iin-Vout, or Iin-Iout. Hence they're usually a lot bigger, and a lot more power hungry (if you want speed) or a lot slower (if you want low power).
That being said, for certain types of applications (for instance, statistical convolution) it may be faster in the end to use a slower, larger analog transistor and use fewer of them at lower speeds to do the same thing as a lot of smaller, faster digital transistors.
But it takes more time to design and is difficult to change and scale to smaller geometries.
In microprocessor design, "architecture" is generally the name for the instruction set, that is, what is software visible. When you speak about implementation details, that would be the "micro-architecture".
Because nowadays, the ISA is really very little impact on resulting performance. The total die space devoted to translating x86 instructions on a modern Nehalem is tiny compared to the rest of the chip. The only time the ISA decode logic matters if for very low power chips (smartphones). This is part of the reason why ARM is so far ahead of Intel's x86 offerings in that area.
Modern x86, with SSE and x86-64, is actually not that bad of an ISA and there aren't too many ugly workarounds necessary anymore that justify a big push to change.
Actually, it's pretty common practice to put spare arrays and spare cells in the design that aren't connected in the metal layers. When a chip is found defective, the upper metal layers can be cut and fused to form new connections and use the spare cells/arrays instead of the ones that failed by use of a focused ion beam.
But that still adds time and cost. Decreasing die area is pretty much always preferable. Also, larger dies means even more of the chip's metal interconnects have to be devoted to power distribution.
People have been proposing circuits for regenerative switching (mainly for clocking) for a long long time. The problem always being that if you add an inductance to your circuit to store and feedback the energy, you will significantly decrease how fast you can switch.
Also, you think transistors are difficult to build in small sizes? Try building tiny inductors.
They may very well alias into the bird's vision range. But I imagine that with all the EM going around, their visual processing center most likely filters that out.
There's just very little reason to do it. Consider the modern PC. Consider that it won't boot if you don't have an archaic PCI bus and legacy peripherals. Consider that well before the 4GB memory limit was hit, the 4GB addressing limit was really hampering the OS due to the fact so many memory address spaces are "reserved" for peripherals that may or may not be there.
There is a lot of waste in the PC from a hardware/software standpoint all in the name of conforming to this "standard way of doing it" that dates back 30 years. I doubt you want this in your cell phone.
ARM has been able to evolve significantly due to this level of flexibility. The AMBA system bus itself has almost kept pace with the rate of CPU speed increases. Not only that but a lot of SoC vendors use their own proprietary bus architecture depending on the application. A company named Sonics provides packet-style memory access IP for SoC vendors that allows highly efficient memory bandwidth sharing amongst multiple heterogeneous cores. You'll never see this in a PC.
In this case, time is from a computational standpoint, not real time. The running program, for the most part, has no concept of actual time. It has an idea of event sequences and what should happen before something else happens. This is true of multi-threaded applications as well (shared memory model). They still rely on events being synchronized at some point or other and that at any point in their run, the memory model they expect remains the same.
At the end of the day, the biggest issue we have is that memory and computation are so separate. You have data and you have instructions; you have functions and you have pointers. This means that programs aren't atomic and they rely on some external state (memory) to remain consistent in order to function correctly.
One of the things about the brain is that memory is built in to the structure. The motor system doesn't need to go all the way to the hippocampus to retrieve spatial data every time it does something.
Slashdot Mirror
I can understand not wanting them to plop $80 on an expensive calculator but there's no reason they shouldn't be able to adapt to using a $5 cheapo calculator. They're physics students for god sakes. If they can figure out a programmable TI-89, they can figure out what the x, /, + and - signs do.
Suggest that in order to practice for the exam, they use the calculator and not their graphing ones during homework. And -- this is the most important part -- make sure the test *resembles* the homework in format. As in, "ya, I've done this type of problem using nothing but the four functions before, it's just presented differently here".
Just assign a lot of "suggested" problems such that they have enough source material to practice from. It's easy to say "well you should be able to figure it out if you grasp the concept" but often, professors don't realize how big a leap it is (years of doing that type of problem) to go from concept to answering a realistic question.
ARM just announced a 40-bit extended addressing mode and their roadmap is for a 64-bit extension in 2012. I'm not sure how useful traps are in this day and age.
No, what happened was that the most FP intensive tasks (rendering, 3D modeling for games) moved to another dedicated chip (the GPU). Bigger and better compute capacity there has not stopped being in demand ever since and shows no signs of slowing down.
The only thing left that were really compute intensive on the CPU were things like video transcoding and precise (production quality) 3D rendering due to the lack of double-precision support in GPU's as well as the difficulty of using them for compute (i.e. writing back to memory) purposes. For the vast majority of common consumer tasks, there really wasn't much demand for ever beefier FPU's.
Also, just as what may eventually be true for GPU's, there are advantages performance-wise of moving the FPU closer to the CPU. In the case of the FPU, it was much easier to tie in FP intensive tasks with control structures the CPU provided. I would suspect that in the case of the GPU, it will be removing the latency of the PCI bus and the need to copy memory between main and GPU memory, potentially allowing a lot more interaction between the physics and AI with the rendering process.
I believe Bobcat's 2 FPU paths are 64-bits wide. For a total of 128-bits. It initially will not support the 256-bit AVX instructions that are coming with Sandy Bridge and Bulldozer.
Its ALU's also appear to be significantly different than Bulldozer. With only one of the integer units can support multiplies and only two of them can support arithmetics. Two others (using a different scheduler) are load/store units. Bulldozer doubles the ALU resources (but not the number of schedulers) compared to Bobcat. So each scheduler has access to two AGU's, one ADD/DIV ALU and one ADD/Mult.
I was never a big fan of the 3x symmetric ALU's in the Athlons. When it comes to integer intensive code, having a ton of independent ADDs or MULs that I'd need that kind of parallelism for was rare. And the latency (compared to a sane design like Core at least) were significantly higher due to the units being multi-purpose. In either case, with the introduction of SSE2, one could use SIMD if one had a throughput heavy workload anyway.
Bobcat and Bulldozer appears to have moved in the right direction here. I really do like Bulldozer's approach to multi-core and think that with some extension, this could make into very interesting CPU/GPU hybrids as well. Although you could argue it's just another version of SMT similar to Hyperthreading, only with a wider back-end intended specifically for multi-threaded processes.
The next iteration of the XBox 360 will have an SoC that integrates both the GPU and CPU on a single die.
I think we're at a point where only a small niche (well, more so than before) pushes for the $600 behemoth video cards and $900 CPU's.
People are moving towards "just enough" machines that are light on price and power consumption.
The quote you were fanboy-blasting said nothing about price. Technically minded people are concerned about technical features, such as performance and power consumption. And in that, the quote is exactly right. AMD is a generation behind.
I fail to see what the pricing structure for consumer sales has to do with that.
There are plenty of things to learn from Itanium, specifically, what not to do if you want a good general purpose processor. For one, you don't make processor performance so incredibly reliant on instruction scheduling that the biggest compiler team on Earth (Intel's compiler group) couldn't make it run fast on anything except a small subsection of problems.
Secondly, when attempting to gain ISA adoption, making it an exclusive ISA that only you have control and rights to use is a big no no. Sure, it'd be heaven for Intel to be the sole supplier.
And lastly, process and iterations mean more for performance than any fancy ISA. Itanium is consistently one or two process generations behind its x86 counterparts and consistently one or two micro-architectural iterations slower (it takes 2 revisions of the Core micro-arch before Itanium comes out with one).
You can have as clean and fancy of an ISA (which IA-64 was not, btw) as you'd like but implementation matters far far more.
In the end, it wasn't fast enough (the best it ever did was match its x86 counterparts) and it didn't have any other advantages to warrant the switch.
Now, ARM on the other hand....
From the paper, it appears they are using 8 states per signal and custom built a Bayesian NAND gate. I have to question whether or not this could've been better achieved (and is being better achieved) with a fully custom 8-bit Bayesian NAND cell.
How exactly can't IEEE FP represent 0.1?
0 0111_1110 000_0000_0000_0000_0000_0000
No but an analog mixer is very much a multiplication unit. Which is what these guys seem like they're trying to improve; a faster math unit to perform probability calculations on fixed-point (with the binary point always at the msb) numbers.
Control systems were analog long before they were digital. But transistors got smaller and smaller and faster and faster (and lower power to boot!) to the point where even today's sub-mW microcontrollers are fast enough to do the calculations in real time (while running an RTOS even!) such that it's not necessary to use an analog circuit. There are just so many advantages (easier maintenance, upgrading, troubleshooting, consistency, configurability) that even if the A/D -> microcontroller -> D/A chain is slower than its analog equivalent, most people choose the former.
Even today's fastest control systems (F-22 fighter flight computer) is an embedded computer hooked up to high-speed ADC's and DAC's.
Logic is when you're operating on 1's an 0's (hence the term: logic). When you're operating on a continuous scale of voltage values, it's analog.
Forgot your introductory digital design courses already?
I think you forgot your analog circuit class. Functionally speaking, an inverter is no different than a high-gain, rail-to-rail voltage controlled op-amp. It's just far more susceptible to noise and has a very distorted IV curve. The reason digital has taken on so much popularity is that since you're either railing the amplifier to its VDD rail or GND rail and don't care about the in-betweens, you can use very small, very fast and sometimes lower power transistors and not care about how well the transistor performs when amplifying anything in between.
Analog circuits have to have very precise shaping of Vin-to-Vout, Vin-to-Iout, Iin-Vout, or Iin-Iout. Hence they're usually a lot bigger, and a lot more power hungry (if you want speed) or a lot slower (if you want low power).
That being said, for certain types of applications (for instance, statistical convolution) it may be faster in the end to use a slower, larger analog transistor and use fewer of them at lower speeds to do the same thing as a lot of smaller, faster digital transistors.
But it takes more time to design and is difficult to change and scale to smaller geometries.
In microprocessor design, "architecture" is generally the name for the instruction set, that is, what is software visible. When you speak about implementation details, that would be the "micro-architecture".
Because nowadays, the ISA is really very little impact on resulting performance. The total die space devoted to translating x86 instructions on a modern Nehalem is tiny compared to the rest of the chip. The only time the ISA decode logic matters if for very low power chips (smartphones). This is part of the reason why ARM is so far ahead of Intel's x86 offerings in that area.
Modern x86, with SSE and x86-64, is actually not that bad of an ISA and there aren't too many ugly workarounds necessary anymore that justify a big push to change.
Actually, it's pretty common practice to put spare arrays and spare cells in the design that aren't connected in the metal layers. When a chip is found defective, the upper metal layers can be cut and fused to form new connections and use the spare cells/arrays instead of the ones that failed by use of a focused ion beam.
But that still adds time and cost. Decreasing die area is pretty much always preferable. Also, larger dies means even more of the chip's metal interconnects have to be devoted to power distribution.
People have been proposing circuits for regenerative switching (mainly for clocking) for a long long time. The problem always being that if you add an inductance to your circuit to store and feedback the energy, you will significantly decrease how fast you can switch.
Also, you think transistors are difficult to build in small sizes? Try building tiny inductors.
*For classical computation
You could get it subsidized through T-Mobile for $199. Same as any other smartphone.
They may very well alias into the bird's vision range. But I imagine that with all the EM going around, their visual processing center most likely filters that out.
Every time you are near?
Just like me, they long to be
inducted to you.
I mean, surely if cockfighting or dogfighting is illegal...
There's just very little reason to do it. Consider the modern PC. Consider that it won't boot if you don't have an archaic PCI bus and legacy peripherals. Consider that well before the 4GB memory limit was hit, the 4GB addressing limit was really hampering the OS due to the fact so many memory address spaces are "reserved" for peripherals that may or may not be there.
There is a lot of waste in the PC from a hardware/software standpoint all in the name of conforming to this "standard way of doing it" that dates back 30 years. I doubt you want this in your cell phone.
ARM has been able to evolve significantly due to this level of flexibility. The AMBA system bus itself has almost kept pace with the rate of CPU speed increases. Not only that but a lot of SoC vendors use their own proprietary bus architecture depending on the application. A company named Sonics provides packet-style memory access IP for SoC vendors that allows highly efficient memory bandwidth sharing amongst multiple heterogeneous cores. You'll never see this in a PC.
In this case, time is from a computational standpoint, not real time. The running program, for the most part, has no concept of actual time. It has an idea of event sequences and what should happen before something else happens. This is true of multi-threaded applications as well (shared memory model). They still rely on events being synchronized at some point or other and that at any point in their run, the memory model they expect remains the same.
At the end of the day, the biggest issue we have is that memory and computation are so separate. You have data and you have instructions; you have functions and you have pointers. This means that programs aren't atomic and they rely on some external state (memory) to remain consistent in order to function correctly.
One of the things about the brain is that memory is built in to the structure. The motor system doesn't need to go all the way to the hippocampus to retrieve spatial data every time it does something.
Adobe Flash?