Suffering ceepie-geepies! Do we need a new processor architecture? Do we need a new processor architecture? Graphcore says that machine learning computation is different from existing computational types, and will be broad enough in its usage for – as well as accelerated significantly by – a dedicated processor architecture. If UK-based Graphcore is right, then its IPU will join CPU and GPU …
Well, what about inspirations, sudden flashes of novel insight that seem to come out of nowhere? Like say Einstein and General Relativity? Or just happening to figure out that taking process A, putting it into another, unrelated, process B, then combining them into a C somehow makes something never seen before yet extremely useful?
Yes, but it MIGHT be nice for it to consider that, with cars bumper-to-bumper on the one side blocking that exit, that it may be preferable to try to ram the guardrail on the other side or navigate the otherwise-illegal "emergency opening" in the median, even if it was never taught this before. Perhaps, as a last resort, intentionally put itself on its side to present less cross-section to the oncoming truck and focus the meat towards the median. IOW, to think outside the box and find a third option through which the driver may be better able to escape with his/her life.
"
Even when the situation is FAR from predictable or typical?
"
Humans are very poor in that situation, and are more likely to make a situation worse than better. It's why airline pilots use an emergency checklist which attempts to include every eventuality rather than making it up as they go along.
"Humans are very poor in that situation, and are more likely to make a situation worse than better. It's why airline pilots use an emergency checklist which attempts to include every eventuality rather than making it up as they go along."
So you're saying there's a section on losing both engine soon after takeoff and you only have seconds to find someplace to land? I don't think "ditch in the Hudson River" would've been in the book that day. Sometimes, you have no choice but to wing it.
"[...] but FPGA design is fixed once expressed as hardware and thereby inflexible, [...]"
Since the Xilinx developments of the mid-1980s - SRAM FPGAs have been reprogrammable on the fly. That was a revolution compared to the one-off fused PROM types from Actel.
One of the earliest Xilinx reference designs was reloading the FPGA between transmit and receive phases of a serial line. Later developments allowed for partial reloads to reconfigure only parts of a running system's function.
It has always been possible to reconfigure FPGAs on the fly in PCs so as to adapt calculation algorithms during data processing.
It has always been possible to reconfigure FPGAs on the fly in PCs so as to adapt calculation algorithms during data processing.
I agree.
However I'm not convinced how useful it is compared to a program running on a CPU. An FPGA is designed by humans. It's not simple (I've done it). It's essentially like designing a PCB full of digital ICs. I'd expect that most adaptation is either an alternate pre-defined design, or different parameters (to get round lack of on-board RAM). An FPGA has some dedicated multipliers and loads of RAM based cells, implementing logic functions using a look up table. You can inefficiently implement an actual CPU core, or get ones with dedicated actual CPUs built in, but otherwise an FPGA is just a table defined TTL logic board in an expensive power hungry chip to avoid ASIC NRE. It can only "run" a program in sense of GPU, CPU or "Graph" processor by first having the design of one of those implemented in it.
You could at "run" time switch a soft defined CPU from say an x86 to an ARM, or 6502 to Z80. But I'm not sure why you would!
"However I'm not convinced how useful it is compared to a program running on a CPU."
A reprogrammable FPGA gives you the parallel processing capability of logic chips in a denser, less power hungry, physical form.
In the late 1980s there was a tendency for network products to use faster, and much more expensive, microprocessors to avoid the upgrade problems of ASICs or hard-wired TTL chips. They were limited by the rate at which a serial processor can handle what are effectively parallel signals. Our company used a much cheaper microprocessor combined with a reprogrammable FPGA and CAMs. We warehoused at a fraction of the market price set by our competitors.
A product that I developed was designed to interface to the customer's multi-function printer via the printer's auxilliary port. The problem was that almost every printer model (even from the same manufacturer) had a completely different way of implementing the interface. Some were pretty complex such as one that was a raw CPU bus where we had to provide it with I/O port decoding on certain addresses, while others were simple synchronous or non-synchronous serial ports of one sort or another (SIO, I2S, Manchester etc)
The solution I adopted was to have a multi-way connector on my device that went to a small Xilinx, and the Xilinx would be loaded by the CPU at boot time with the appropriate configuration for the printer make & model as selected by the customer. We then had to stock only one hardware board plus a range of interface cables (some of which incorporated simple level changing circuits) that could be quickly made to order if necessary.
Not a CPU/Processor type
FPGAs can be specifically designed, but FPGA design is fixed once expressed as hardware and thereby inflexible, Graphcore says, which adds that they are also difficult to program, power-hungry and have relatively low performance.
FPGA is primarily an implementation method for prototypes or low volume production, where power consumption and die size (per chip production cost less important than ASIC NRE costs).
In theory an FPGA "could" be reconfigured at run time, rather than as a field upgrade. That's not a processor type either. Does anyone have any example of such a product in production?
"In theory an FPGA "could" be reconfigured at run time, rather than as a field upgrade."
Xilinx reprogrammable SRAM FPGAs had reference designs when they came out in the mid-1980s. One was revolutionary as it reloaded between the transmit and receive phases on a serial line.
A networking product in the late 1980s had several possible Xilinx FPGA download images available in the box - each one expressed particular options that the management station selected. This made it very efficient as the FPGA didn't have unused modes taking up space that would have required a more expensive chip.
A piece of test gear in the late 1980s overcame the limitations of the then Xilinx maximum gate counts by run-time "compiling" of the FPGA download image to modify certain preset features. That set up user configurable timing counters and test conditions etc.
Those examples were in the infancy of the reprogrammable FPGA. Over the last 30 years FPGAs' capabilities have grown enormously as the gate counts have increased by several magnitudes. They now have partial reloads while running - and enough gates to include an embedded cpu function as part of the on-board capability.
The challenge has been to describe a language that allows an FPGA function to be expressed as dynamic changes to algorithms when doing data processing in a main processor.
FPGA reconfiguration at runtime: It's being researched in academia, see scholar.google.com "partially reconfigurable FPGA"
Some state-of-the-art FPGA by the big vendors can already do this, support in their design suites is less-documented and incomplete, by my last information (1 year old).
"Some state-of-the-art FPGA by the big vendors can already do this, "
AFAIK almost all can. Years ago.
The bigger issue is doing it in a useful fashion. You can do a SDR where so as to avoid wasting internal resources, the filters, noise blankers, demodulation type etc are different designs loaded from external Flash at "run" time as a result of signal conditions or operator selection, using a separate CPU even to control the JTAG.
It doesn't sound like this company has told us the extent to which their processor can be reconfigured at run-time, so it is entirely possible that they are no better placed than someone using a clever FPGA on one of the chips that Intel and AMD have (both?) promised that will include an FPGA on the die.
If they aren't doing something distinctly different from that, I'd bet on Intel's manufacturing abilities rather than a small start-up's cleverness. Of course, this may be *why* they aren't saying anything yet; they want a head start!
So how many FP processors can you put in an FPGA?
How many FPGA's can you put on a board.
I think it was interesting when the EFF built their DES cracker (to finally prove DES was FUBAR) they looked at this and went with ASIC's because it was a more affordable solution.
Those numbers mean either 2^25 or 2^27 elements are being processed. So either those PE's have to be very simple (how much smaller a floating point range can you get away with) or you'll need a lot of chips.
This looks quite sensible, although I'd wish the graphic at the top could be blown up. It's pretty useless at that size.
BTW has anyone else noted someone has been fiddling with the outlining code for icons?
This post has been deleted by its author
Large array probabilistic problems are what quantum computers are supposed to do in a few steps, run many times to determine outcome probabilities. Looks like this solution is trying to speed up the brute force classical method by tailoring the chip architecture.
Yep, I was thinking the same thing; this is dovetailing with quantum computing in a interesting, and hopefully fruitful way, once some chips start to be deployed and the performance is up to the task. Whereas quantum computers will have high levels of accuracy and do the TIP (training, inference, prediction) tasks with blinding speeds, this type of processor architecture is fascinating in that the needs are for massively parallel cores with low-precision floating point capabilities. Something we can build today, and can get the 'bleeding edge' software developers coding to it and perhaps having something useful to port to real QCs, when they are more widely available. Great stuff, very interesting article!
Here's something that looks similar from those wacky IBM folks:
https://en.wikipedia.org/wiki/TrueNorth
FPGAs are wondrous devices, but can you build a 4096 core specialized CPU out of one and have it perform as well as a dedicated, purpose-built device?
So let me see if my tiny mind understands this,
Simultaneously multiple programs will run determining answers however these are all connected at another level and the outcomes of each answer influences all the other answers and the final answer?
So in theory without having to determine every question and answer if you feed enough already answered questions the program would be able to determine answers on it's own?
Am I close with that?
I was thinking more of the Japanese "Fifth Generation" which was intended to run Logic Programming because that was the bees-knees of AI back in the 1980s.
The inevitable Wikipedia article
https://en.wikipedia.org/wiki/Fifth_generation_computer
- although that me grit my teeth because it presents "argument" that there were "parallel generations of programming languages" because they've fallen hook, line and sinker for the "4GL" marketing twaddle that came out because of misreading the line "Prolog is the language of the Fifth Generation" as "Prolog is a fifth generation language" so we can call our database language "fourth generation" and then retrofitting "SQL is 4GL" to the claim here that "TeX is 4GL".
</rant_to_get_lots_of_downvotes>
As a grab-bag response to a number of the posts above
It's now possible to do "High Level Synthesis" for FPGAs, compiling C-code to logic structures. Both big vendors have HLS products (OK Altera's is OpenCL). In essence the HLS compiler identifies the data flow in the C code and builds a dataflow machine that has the same behaviour.
FPGAs currently available come with up to 1500 floating point DSP blocks. So plenty of parallel processing power available.
Main pain point is the long compile times (hours) especially for HLS.
I can believe that a machine-learning optimised processor would beat out the CPU, GPU, FPGA alteratives for machine learning applications.
FPGA will always suffer in comparison with purpose-designed hardware; however with specialised hardware there is always the risk of new techniques coming out that aren't suited to the hardware. With FPGAs you can implement completely different techniques if desired (and you have enough time!).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
