26 Jul 2007
FPGA tutorial series
This FPGA tutorial series has been needed for a long time. Hopefully there'll be enough depth for end users to evaluate the technology approach and also compare the vendors' offerings.
22 Jul 2007
Java floating point performance
OK, so it's not exactly FPGAs but we use Java a great deal for writing systems including financial models. Now many people believe that Java floating point performance still lags C++ significantly but in reality it's pretty close. Given the significant productivity differences, in general you might as well use Java, especially if the maths is not matrix based. If it is matrix based, Java's lack of support for the modern processor instruction fused multiply acc/accumulate (ie do both a multiply and an add at the same time -- added to processors specifically for matrix math since it is such an important operation), can mean a 50% drop in performance compared to an optimised C++ / C99 version.
I've been harping on about this for years (for background see here and here), but I've just noticed a Java fmac bug report that you can vote on (and a related Java maths bug report). So why not dust off that Sun Developer (or JDC or whatever) login and go vote for something that could make a huge difference to Java adoption in the numerical finance world.
I've been harping on about this for years (for background see here and here), but I've just noticed a Java fmac bug report that you can vote on (and a related Java maths bug report). So why not dust off that Sun Developer (or JDC or whatever) login and go vote for something that could make a huge difference to Java adoption in the numerical finance world.
5 Mar 2007
The CPU is getting lonely..
So it seems that the recent fashion for the CPU-knows-best is generally being re-thought; it's the return of the co-processor. While it makes sense, and at ngGrid we think it's compelling when using FPGAs in their sweet-spot, much of the coverage is somewhat lacking in depth.
In general the co-processors they speak of are GPUs (or possibly physics engines for games) but very little is mentioned of FPGAs, DSPs and the myriad of non-AMD/Intel/x86 hardware. In addition, while dropping another type of processor in a spare socket can give you a serious performance boost, I think this design shift could run into a while new architecture style. I don't think things are going to go all the way back to transputer's sea of processing elements (I think the granularity will still be quite chunky) it may finally bring some competition to the PC architecture. The PC standard is a huge hindrance to high performance computing in terms of hardware technology -- a cost which delivers amazingly cheap machines however.
Delivering the ability to innovate in architecture while remaining compatible with standard tools / binaries will be the key challenge going forward, in my opinion. Just dropping a single FPGA/GPU in a socket is not enough, you'll still want the local RAM (and lots of it) and associated IO in order to really jump ahead of homogeneous CPU architectures.
Another part of the equation missing, is real world experience and examples. While DRC and XtremeData have socket based FPGAs available today, I haven't seen much coverage of the benefits versus sitting on a PCI-foo bus. Of course, the lack of public FPGA successes in general is another matter altogether...
In general the co-processors they speak of are GPUs (or possibly physics engines for games) but very little is mentioned of FPGAs, DSPs and the myriad of non-AMD/Intel/x86 hardware. In addition, while dropping another type of processor in a spare socket can give you a serious performance boost, I think this design shift could run into a while new architecture style. I don't think things are going to go all the way back to transputer's sea of processing elements (I think the granularity will still be quite chunky) it may finally bring some competition to the PC architecture. The PC standard is a huge hindrance to high performance computing in terms of hardware technology -- a cost which delivers amazingly cheap machines however.
Delivering the ability to innovate in architecture while remaining compatible with standard tools / binaries will be the key challenge going forward, in my opinion. Just dropping a single FPGA/GPU in a socket is not enough, you'll still want the local RAM (and lots of it) and associated IO in order to really jump ahead of homogeneous CPU architectures.
Another part of the equation missing, is real world experience and examples. While DRC and XtremeData have socket based FPGAs available today, I haven't seen much coverage of the benefits versus sitting on a PCI-foo bus. Of course, the lack of public FPGA successes in general is another matter altogether...
13 Feb 2007
We're hiring...
... in London. We are looking for an FPGA engineer to join us in product development and also for consulting projects to our clients.
We are looking for an experienced reconfigurable computing engineer / developer, preferably with a mix of FPGA and software skills. We're not too fussy on specific languages or buzz words, we care more about experience, ability and attitude.
Since we're small company presently, the role will be fairly dynamic, so you can expect a mix of HDL coding (Verilog, VHDL, SystemC etc), software coding (anything from Python & Java to C++ or even assembly!), high level design, algorithm tuning, product design & client facing projects.
A "can do" attitude is the key skill to bring along, rigid roles and structures are not what we are about. Since we are targeting financial applications, a good maths background is needed but we don't expect you to know anything about the specifics of the algorithms.
If you're interested in finding out more, send an email with your CV to careers(at)nggrid.com.
We are looking for an experienced reconfigurable computing engineer / developer, preferably with a mix of FPGA and software skills. We're not too fussy on specific languages or buzz words, we care more about experience, ability and attitude.
Since we're small company presently, the role will be fairly dynamic, so you can expect a mix of HDL coding (Verilog, VHDL, SystemC etc), software coding (anything from Python & Java to C++ or even assembly!), high level design, algorithm tuning, product design & client facing projects.
A "can do" attitude is the key skill to bring along, rigid roles and structures are not what we are about. Since we are targeting financial applications, a good maths background is needed but we don't expect you to know anything about the specifics of the algorithms.
If you're interested in finding out more, send an email with your CV to careers(at)nggrid.com.
A new FPGA blog...
Well, I felt it was time to start airing a few thoughts on the whole FPGA endeavour. I intend to write about a bunch of topics, anything from financial algorithms and implementation to FPGA tools and sector gossip. I'll probably throw in the odd CPU reference as well as other tenuously related snippets, such as notes on grid computing.
Subscribe to:
Posts (Atom)