Slashdot Mirror
Start-up Could Kick Opteron into Overdrive
An anonymous reader writes "The Register is reporting that a new start-up, DRC Computer, has created a reprogrammable co-processor that can slot directly into Opteron sockets. This new product has the potential to boost the Opteron chips well ahead of their Xeon-based competition. From the article: 'Customers can then offload a wide variety of software jobs to the co-processor running in a standard server, instead of buying unique, more expensive types of accelerators from third parties as they have in the past.'"
I thougt they had done this out at Berkeley a while back. Is it really a new thing ?
Rendering comes to mind, but I'm biased. But I'm sure that a glorified graphics card isn't the most interesting use...
If these become popular enough, will we be seeing a back-end to GCC for this FPGA?
Wikileaks, no DNS
A specialist co processor for processing your spyware and spam would be double plus good.
I actually like the idea of a co processor sitting there, but I wonder why you wouldn't just stick another opteron in and write custom code?
liqbase
This could really be an interesting way to boost real time soft synths... Even with top of the line processors the more complex ones will bring a CPU to it's knees. Seems like a more sensible option compared to a DSP-filled expansion card. Too bad this thing is still a little on the expensive side for a viable market on the music software side.
.: Max Romantschuk
when you can just read about it on the company's website?
http://www.drccomputer.com/pages/products.html
The Register in "press release run as News Item" shock.
Yup, seems like a pretty neat piece of hardware. The only thing I'd be worried about is quality. All of these alternative processors usually seem to good to be true, until you use them. At work, we ended up buying 15 computers with a similiar item, and they have been nothing but trouble. They underperform, they break, etc. Granted, this may be a high quality product, but I sure won't buy one right away.
Register the editry.
Wikileaks, no DNS
They basically made a FPGA (field programmable gate array) that can plug directly into HyperTransport (the Opteron CPU bus). FPGAs let you efficiently solve many problems that a general purpose processor can't. This has been done with PCI cards before, but the PCI is too slow for many uses. Giving it direct access to HT solves that problem.
That's a pretty cool niche.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
That'll be sure to get the team stats up!
Now, who do I call for a free demo?
previously I'd decided I was willing to pay a hunnert bucks per free slot on my machine for boards that could process boinc faster..
(they'd need fans though)
I'm in the top 3% worldwide.. and so are the 18,055 people above me.
And I don't believe I'll ever see top 1%
every day http://en.wikipedia.org/wiki/Special:Random
"DRC's flagship product is the DRC Coprocessor Module that plugs directly into an open processor socket in a multi-way Opteron system," the company notes on its web site.
If you have an open Opteron socket on your multi-way box, wouldn't you probably achieve better performance by shoving another Opteron into there?
I mean, sure, I can see the benefit of having a co-processor customized to handle your specific workload. But another Opteron would likely run at multiples of the clockspeed of that thing, and it would also be able to offload work from the *othewr* Opterons, such as disk I/O etc, giving your overall application more performance.
There are plenty of others that have tried this, and plenty of them failed. A FGPA does have a significantly slower clockspeed and you need to have fairly sophisticated software that can make most of the flexible design. Before this thing came out in most instances it turned out to be cheaper to buy more horsepower and staying on a regular hardwareprogramming path than to risk it with special hard and software.
These guys claim their stuff is cheaper than more horsepower and that you get the extra speedboost from the hypertransport (over pci).
It clearly is a pr-release that has been regurgitated by a lazy journalist, as I found no or few critical notes, something this product might deserve. for one thing I don't see how they have solved the special software & programmers problem or how they really have taclked the economics of scale: this thing costs a couple of grands, vs a couple of hundres for a amd top notch processor. the regular processor has double cores and runs an order of magnitude faster than the fpga. The scarecity of programmers that can write software for this thing adds another order of magnitude to the wrong side of the equation.
Roughly, the fgpa solution must be a thousand times quicker/better than the regular-proc-with-lots-of-horsepower solution. I don't see that happen soon.
OTOH, the rosy images of a computer that can render a pixar animation in a few minutes the next mintes be used as a realtime sound-processing thing or simulate a neural net with as much neurons in it as in the human brain, that makes the geek in me drool. Computer, tell me it isn't so!
This space is intentionally staring blankly at you
Even though I only know of 3 people that use 940 socket machines for gameing (2 of them dual cpu rigs) I believe an ageia physX processor modded to the socket would be a good idea. The combination of extremely fast cpu-ppu bus combined with being able to use stock (well, reg ecc ram is kinda stock) ram to feed it would help to make multi socket opterons a very viable gameing platform, although as those 3 peeps (and me after seeing the BoM) know, it would not be a cheap one.
...
I'm not a fan of java, but imagine JVM programmed into such co-processor on the hardware level (just as it is capable to). I bet it will be a very interesting option for some people. Servers running on java, anyone?
But I'm a fan of neural networks, and I imagine that if such coprocessor was programmed exactly to perform NN tasks it could bring "brain simulation" a few steps closer - especially if many such coprocessors were put into the system.
#
#\ @ ? Colonize Mars
#
I had never thought about using a hypertransport connection to get an fpga connected to a cpu, but I had often wondered about fitting an fpga into an sdram socket. You just write your block of data out to memory and read the results back.
How about programming it as an x86 processor and then booting from it? That would be pretty interesting.
Also, power consumption matters if you've got a rack of these things in a small space and need to keep them cool. Five times as many systems might need a larger server room.
Wikileaks, no DNS
The Tao of math: The numbers you can count are not the real numbers.
The sweet spot for plug in like this, IMO, would be similar to what you see a few board manufacturers doing now -- digital signal processing routines like Fourier transforms and other general calculus functions that are used in all kinds of data analysis where raw data comes in as analog variations, or where the moment by moment changes in state need to be modeled for engineering applications like fluid dynamics and harmonics.
I'd imagine you'll need to have the application compiled in such a way that it is aware of the additional processing capability, so its not likely to be a plug-n-pray solution to your general game player's graphical wet dreams.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
I have to say, I'm surprised it has taken so long. Seems a few years past-due, IMHO.
One of first signs that PCs needed an FPGA or similar was hardware MPEG capture cards... They could do the job so much faster, and so much cheaper than your primary CPU, that the alternative is disappearing.
High-end graphics cards have been the most telling development. It's not that OpenGL is something magical, it's just that an ASIC can do many things so much better than a CPU that transfering much, much more raw data over the bus was still cheaper than actually processing it (despite the fact that interrupts are rather costly themselves).
PS2 clusters, Crypto cards, Hardware-accelerated NICs, SLI, all are a symptom of almost excatly the same problem...
The rising popularity of GPU programming made it extremely clear that there is a vaccuum here. Using the videocard isn't a very good method to accomplish this, just a stop-gap necessity. I thought from the beginning that FPGAs would become like the old math-coprocessors, and have their own motherboard socket, but neither AMD nor Intel were stepping up to fill this clear need. Installing it into a normal CPU socket, to get around this appathy, is a very clever hack I hadn't thought of.
I expect, with popularity, it will be cheaper to put a custom FPGA socket on motherboards, rather than building a full-fledged SMP motherboard for the purpose. After that, who knows... Maybe FPGAs will go the way of the math-coprocessors and get itegrated into future CPUs.
I know if I was running ATI or NVidia (or Hauppauge, or Level5), I'd be very worried about this thing eating the most profitable segment of my market.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Another nice approach was the "swinging gate" RAM method in which you had two blocks of physical RAM in the same memory space. The main CPU filled one block with data, then flicked the switch so the co-processor could read that data while the CPU read the results from the other block, then put in new data for processing in the next cycle. Very easy to implement, much cheaper than FIFOs. It meant you could use a cheap DSP (from TI) in a system using a cheaper 8086 series processor for which you could get cheap tools and an embedded OS.
Pining for the fjords
On opteron motherboards each processor manages its own bank of memory and makes it availble to the other processors via the hypertransport. Since this FPGA replaces one of the processors, how does it manage the associated memory bank?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
yes this has been done before (different socket for sure). Most of them have failed. But this is getting picked up by others lately and seems to have legs (technologically speaking).
http://www.cray.com/products/xd1/index.html
oh BTW a single 3U is around $45k. For certain memory bound calculations and some sequential algorithms, HFFPGA work well (high frequency FPGA).
a reprogrammable co-processor
In Soviet Russia, co-processor reprograms you!
As for why they hyphenated it, I can't answer that one...
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Does anyone remember the gool ol' days?
I still have my 386/40MHz + coprocessor.
And yes, AMD have called me to come in to their lab with my ancient relic about a year ago.
Do you remember the Weitek math co-processor (i386-era stuff). It disappeared quite completely.
Also there is a big fear of specialized hardware accelerators because they could be rigged in silicon, which you will never find out. With the functionality implemented in software on generic purpose CPU you at least have a chance to audit the code to find out if the SSL handling has some NSA backdoor added or so. You buy a Chrysalis Luna VPN booster PCI card and assuredly know Mossad reads whatever you transaction. Never ever use hardware accelerators, they are salted to suit the secret services' taste. General purpose CPU and open source code is the only true safe way of wisdom.
I think why they implement it as an Opetron is that besides the hypertransport thing, they have their own exclusive set of memory. The co-processor don't have to share this with the system, making algorithm a lot easier (a big continuous chunk of memory for matrix operation!) and design would be much simplier, no MMU whatsoever.
Is it just me, or did that whole article seem like one big ad?
/.
That was a blatant marketing ploy.
There is nothing really 'new' about this technology, the only thing this product claims to do is improve performance by offloading specific tasks, so how is this any different then the GinSu Knives claiming to cut bread easier(or shoe) all for the low price of $30!@?#$$!@
No digg... oh wait, this is
"but imagine JVM programmed into such co-processor on the hardware level"
.. or just any FPGA ..
Sounds familiar, this idea, it was proposed to speed up LISP to, and we know it didn't make LISP more popular. One probably would do better in finding out whether RISC or CISC and whether many registers or few registers were more efficient for JAVA+JVM to work with.
"I imagine that if such coprocessor was programmed exactly to perform NN tasks"
Or you could just get one of those NN cards that are commonly available
But then, I doubted that pigs can fly too up until the day somehow did it.
Lots of other comments have made clear the point that it's not easy to program this kind of hardware. Typical software programs run in a very sequential manner. In fact, trying to get cooperative parallel execution of threads is known to be a major sticking point in the average programmer's education.
Hardware, on the other hand, is massively parallel. All the "gates" (*) are all running all the time. It's like multi-threading a program, taken to the limit of infinity. However, if designed correctly, this thing can scale beyond belief, since it's all parallel.
It's also important to note that it's a Virtex4 on that card. That's one hell of an FPGA, they sure aren't cutting any corners. I'm not sure which one they're using, but some Virtex4 chips have PowerPC processors at 450 MHz.
This is definitely a niche product for now, due mainly to the lack of people who can write code in Hardware Description Languages (HDLs). But if you can figure it out, and you have an application that works on a massive scale, this may be for you.
Oh, and for all you detractors who are saying "that thing only runs at 500 MHz! How is it supposed to be faster than my 2 GHz AMD chip?" You're forgetting one very important factor. Your AMD chip executes one instruction at a time, and the important instructions are surrounded by instructions whose sole purpose is to control program flow or move data back and forth. However, the XtremeDSP slices of a Virtex4 can each execute a multiply and an add in a single cycle, and there are up to 512 of them in the most hardcore Virtex4 chip, and other logic executing in parallel can control the "program flow" and ferry data back and forth across the bus.
*: Modern FPGAs are actually built out of SRAMs that can implement arbitrary logic functions. They're no longer arrays of gates, so to speak.
:(){
But what I find really exciting about this idea is that once the GPU is in the motherboard, I'm sure programmers would find an easy way to use all that logic to do calculations - say, media encoding. Heck, I know they are trying to do this with GPU's on cards, but this would be a much lower latency connection.
I wonder how this would affect total system cost. I mean, I know multi-socket mobos will always cost more, but then again, when the GPU is a chip instead of a card, that should bring costs down. Also, they could ditch all that PCI-e logic and those slots. Upgrading would definitely be cheaper, and can you imagine two socketed GPUs on the mobo running a Hypertransport version of SLi? That might be the fastest, quietest gaming rig ever!
Who needs PCI-X and the like, when you could just plug your graphics coprocessor (and other things like that) into Hypertransport? Maybe some day we'll all be using motherboards with lots of socket 940s instead of traditional expansion slots.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Btw, it should be noted that Cray has something very similar in their Cray XD1 - http://www.cray.com/products/xd1/acceleration.html But the virtex is connected via their proprietary interconnect.
A dedicated co-processor with enough registers to perform a complex calculation without having to constantly ferry register values between memory and the processor, combined with the ability to run several calculations simultaneously will blow the socks off a general purpose CPU for *very specifically designed algorithms*.
There's a market for GPU's on video cards running $1,200+... People that buy them won't be satisfied with standard GPU's no matter how fast their main processors run... The custom acceleration of graphics calculation makes it worthwhile.
Now, imagine doing massive calculations (think three blackboards filled with quantum physics equations) -- and you can see how some scientific/industrial applications would go ga-ga over this stuff...
See earlier postings and blog entries on this concept:
s sors.html
http://www.fpgacpu.org/usenet/fpgas_as_pc_coproce
http://www.fpgacpu.org/log/aug01.html#010821-dimm
The latency to the FPGA fabric largely determines what kinds of coprocessing workloads are feasible.
When hypertransport came out, we (FCCM'ers) knew a HT-based lower latency interconnect should be possible. (Though I wouldn't call 75 ns +/- "low" latency -- that's a couple of hundred instruction issue slots, or a bit more than 1 full cache miss.) But DRC has gone and done it. I love the way it (apparently) just drops in and can even use that socket's DRAM DIMMs. Congrats to Steve Casselman and co.
Another requirement then would probably be to have a second bank of ram slots for "Video" ram ... though this could be a great thing if the gpu becomes generally available as a co-processor as presumably your faster video ram could be used for aonther level of caching? It would also mean you could upgrade your gpu and video ram seperately. The only downside I think I can see is that your video output's are likely to be tied to your motherboard though perhaps that's where pci-* steps back in (so you can pop in a video or audio card which is no more then inputs/outputs using the onboard dsp/ram)? Only thing is this starts to sound like winmodems so getting it all working solidly could be a challenge.
Never underestimate the dark side of the Source
As a cranky engineer, I find this ... sweet.
The best phrase to help the system design effort is data flow.
How does the machine chop up the task for the most performance?
The major problem in design is finding where to place the dotted line that says "cut here". Software mavens know this as refactoring, or partitioning.
The gotcha in development would be to ignore the internal architecture of the FPGA.
As a word of advice to the beginner, look carefully at the FPGA data flow, and try to decompose the algorithm ( or find a similar one) so that the data manipulation and movement fits the part as best as possible.
Just having an HDL is not enough, the neophyte hardware designer can easily write code that cannot be synthesised to work, let alone fit the part. A sensitivity to the underlying hardware is needed.
As an example of this, using hand crafted hardware design, Chuck Moore wrung several times the expected clock performance for a hardware Forth engine. A starting point for reading might be:
http://www.ultratechnology.com/cowboys.html
Using hand-crafting, you can get enormous processing gains, but the hardware and system designs have to be well understood.
Perhaps the GNU uber-geeks could handle the translation efforts to make a tool for the average application programmer, but until then the brave soul who tackles these efforts should be prepared to learn a lot of the edges of computer science, hardware, and system design. It's not a horrible job, just long. And the problem should be worthy of the efforts needed.
This is progress?
Probably not, because only expensive server processors like the Opteron and Xeon can be used in multi-CPU systems. While there are a few gamers who use the Opteron- probably they just like to spend money- they don't have the volume to justify producing such a thing. It would cost $5000 like the FPGA in the article, and probably not be updated as often as regular GPU's.
Now, a programmable co-processor on a PCIe x16 card... I'd like to be able to encode a movie in five minutes.
Give a man fire, and you warm him for the night. Set a man on fire, and you warm him for the rest of his life.
I just want to use the FPGA to add an insane amount of memory and present this to the other cores over HT. It seems some most people missed out on this possibility.
New polyphonic software instruments rely on CPU cycles. More cycles sound not only better but much different. Musicians are at a tipping point at this moment in time. Old fashioned instruments which are standards on stage and tour are becoming brittle and expensive. Collectors are snapping up the old instruments at prices north of $5K USD reducing the availability of instruments for playing professionals. The Hammond B3's are going as high as $16K. Selmer Mk6 saxes $6K.
Software instruments are a necessity going forward. Its imperative to find a scalable system that is state-less and transparent to the performance.
Now I'm confused. This sounds about like someone saying: "Now that they've got hybrid technology in cars, they should put it in trucks. Then we can take the trucks and make them smaller by removing the truck bed, and put more seats in. Maybe even put a car body on it..."
What do you think this FPGA is for, exactly??? It's designed to do exactly those kinds of calculations you want to do with a repurposed GPU... Except, of course, you're raising the difficulty level significantly by doing that.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Might as well make it an HTX card rather than suck up a CPU socket that could otherwise be driving more memory (picture implies no attached memory). Most upcoming 940 platforms have HTX slots now for the equivalent performance/latency with a left over hypertransport links.
XML is like violence. If it doesn't solve the problem, use more.
Yet a different startup has created a similar product. The XD1000 from XtremeData Inc. also plugs into an Opteron 940 socket and has an FPGA on it, but an Altera Stratix II instead. Again, the openness of Hypertransport allows full speed access to the other Opteron and also to memories, etc.
See http://www.xtremedatainc.com/Products.html
I imagine there will be a patent battle in the future, or one will take over the other....
Not an employee of XtremeData...
I think the parent was suggesting that CPU-socket devices could be produced that were marketed as GPUs but could be used to assist other CPU-bound processes. Whether or not said devices are designed as graphics chips or general-purpose logic devices is another question.
WRT your vehicular analogy, there are people who buy cars and want to use them as trucks occasionally, and people who buy trucks but sometimes just use them as cars. It's no big deal.
The advantage of pcie is that the specification will likely stick around for 6-7 more years, and will be used on both intel and AMD systems, as well as some of the more obscure architectures. You can design your graphics card and know that just about anyone will be able to throw is into their box. It gives you a very large addressable market. putting the GPU into a processor socket cuts your addressable market down to only AMD boards.
Furthermore, GPU's do require a fair amount of bandwidth, but are a lot more latency tolerant than a processor. PCIe is really suited to the job, I don't see why you'd want to supplant a slot designed for I/O boards with a socket designed for something else.
To query the intellect of one of the highest qualified experts on Security of computing sysmtes: What Would Theo de Ratd Say?
without prejudice
http://www.xtremedatainc.com/Products.html
Shows a product very similar to the drccomputers product. I'm untechnical and as such not able to supply any valuable comments. But i'd be glad to hear from you.
free dom(inion) - free energy - free your mind - whee!
While you're right about the "programming" problem (lack of standard tools, many fewer skilled HDL programmers), the capabilities are there today. I saw a demonstration of a $50 FPGA that took and image from a CCD camera, ran an edge-detection algorithm on it, mapped the image onto the faces of a cube, and displayed that cube rotating in 3-D space. The FPGA was being clocked at 50MHz.
The same algorithm was being done on a 1.6 GHz Pentium M and the result was a significantly slower rotation/update rate.
Up-clock the FPGA to 200 MHz (even the low-cost FPGAs can do this) and replacate the design to do eight cubes (cut & paste the HDL), and you've got your three orders of magnitude performance advantage.
An HTX Card? How do you get 30 Watts of power to it? How do you cool the FPGA? Where do you put the 8GBytes of DRAM available to the Opteron socket? How do build a single board that will fit in the form factor available in most Opteron systems? Tough questions. And then there are places like ATCA systems that have no plug in slots at all. XtremeData's XD1000 fits in all dual Opteron systems. Gary Hardware Architect XtremeData Inc www.xtremedatainc.com
30 Watts could be clunkily done via a direct attach cable from PSU. Cooling probably is a fair issue, most accelerators in the market today don't have that much heat to dissipate, therefore meeting PCI-spec like requirements with a cooler is an issue for 1U systems that don't allow multi-width cards at all. Conjecture had been that the DIMM sockets were not being utilized, and that was my chief concern about a device sitting in that spot and crippling the memory capacity. HTX slot is fairly standardized and becoming more prevalent in the market, so building a single board isn't that much of a challenge, though some 940 platforms admittedly do not have that slot.
The other issue is how does it deal with other devices that may be connected via hypertransport to the socket it occupies? For example one strategy I see pursued to get more inter-node IO is to have, for example, a four socket opteron where each socket has two links to two processors and the third brought out for inter-node IO via PCI-E chips or HTX.
It could be interesting compared to clearspeed offerings, but the platforms I work with have moved on to AM2 for the future...
XML is like violence. If it doesn't solve the problem, use more.
The DRAM is actually the most important issue. We use all the available DRAM DIMMs on the motherboard, so no system resources are wasted. This is a very nasty problem for plug boards to deal with.