
Genomics Marks the Next Sequence for FPGA's - nkurz
http://www.nextplatform.com/2015/10/29/the-next-sequence-for-fpgas-is-in-genomics/
======
dekhn
Every time somebody has attempted to do this (for exmaple BLAST using custom
ASICs or FPGAs), the next Intel chip- its general purpose capabilities, not
any special stuff- has gotten fast enough and cheap enough to make custom
hardware irrelevant. I don't see that changing any time soon- we're not
actually blocked on any heavily CPU-bound problems in the genomics area right
now, except perhaps machine learning on variants, and that's handled by GPUs,
which are commodity hardware.

~~~
pjc50
Indeed. FPGAs only win if you have lots of integer operations that are truly
parallel but require a moderate amount of memory bandwidth. GPUs win for
floating point and CPUs tend to have far more cache than you can fit in an
FPGA.

~~~
dekhn
THat's beside my point too- the community doesn't have time to chase whatever
the custom-solution-du-jour is this year. General purpose Intel processors are
always a better investment because (IMHO) there isn't really any true CPU
bottleneck at this point. Data storage, memory bandwidth, network bandwidth
are the big three issues.

~~~
ethbro
"Doesn't have time"... yet*

*This equation changes if suddenly the pace of semiconductor process miracles starts slowing down

~~~
dekhn
Well, except that FPGAs and ASICs use the same process as general purpose
chips, so they're susceptible to the same problems.

------
noipv4
Convey computers used to sell 4U servers with lots of Virtex-6 FPGAs to
accelerate short read mapping/alignment, and assembly. They got bought over by
Micron, probably to help them port Bioinformatics applications to Micron's
Automaton computing chips.

------
amelius
I would like to see some numbers. To begin with, how many FPGAs can replace 1
Intel CPU, in terms of compute power? And what does an FPGA solution cost in
dollars, versus a CPU-based solution (including motherboard, memory,
powersupply, etc.)?

~~~
bravo22
a customized pipeline for a specific solution will always outperform a CPU,
which is designed to be pretty good at a lot of things but not great at one
single thing.

As for price... that depends on how much they want to charge for it ;)

~~~
amelius
I'm not sure that a customized pipeline is always faster than a CPU. I guess
that in a lot of cases, memory access will be the bottleneck.

Regarding the price, I'm talking about raw hardware costs (because it shows
what profit can be made by making customized solutions).

------
elij
Accelerated reference alignment (via something like an FPGA) is definitely a
way forward as the problem is now relatively well understood.

Would be interesting to see where things go with respect to de-novo and graph
alignment.

------
dharma1
has anyone used opencl to program FPGA's? How was it? What's the perf like?

~~~
gjulianm
I haven't dived deep in it, but we tried an OpenCL program in a FPGA and we
couldn't even make it work: OpenCL support is at version 1.0 (no vectors, no
barriers) without double precision numbers. And, from what I've heard, the
performance is not that good.

------
arca_vorago
"We can analyze RNA, agricultural biology, different pipelines for cancer
research—all of these have widely varying pipelines and some are just nuanced,
but they all require something different to be loaded into the FPGA before
that run.”"

Therein lies the rub. I was a sysadmin for a biotech company doing this kind
of stuff, and in the end we evaluated fpga/asic and just couldn't justify the
costs, not just hardware costs but time and barrier to entry costs, such as
having to hire more programmers. I also kept a close eye on GPUblast, but it
just wasn't keeping up with official, and due to pipeline specialties, mostly
revolving blasting against all kinds of data, it didn't fit the bill. That's
the main issue, that people doing blasting and related often have very
specialized pipelines and different types of data and would almost be required
to spend a lot of money to get such a system to work for them. It much less
about the speed of the computation than it is about moving the data around.
When you start dealing with 100Tb's of output a day...

What we did end up doing was two things, one, we wrote worker system that
basically distributed the computation to almost every computer on the network,
and two, I figured out that due to how embarrassingly parallel the computation
was, AMD's newer opteron chips actually outperformed Intel's, and I build some
beast servers, and took computation down from average of 1~3 days to ~4hrs.
(think 64 actual core's via quad cpu motherboards... truly some of my favorite
servers I have ever built.) Bottom line is that IO is the main bottleneck, so
even things like ROCKS clusters or other distributed systems don't work as
well as many of the big data people like to think.

We also had a very different than normal pipeline mostly revolving around
which data to blast against and the methods we used, which were considered the
core IP/proprietary, but the real IP was in the analysis.

As FPGA's, Asics, and GPU's make it easier to get the data, you still have to
understand it and analyze it, and that is much harder than people understand
IMHO.

I left for personal reasons, and I'm still under a non-compete, but I am very
thankful for the opportunities I had to learn the bioinformatic's side under
the eccentric genius I did, and perhaps one day I will turn some of my
knowledge into a system that is useful for those wanting to do this kind of
work. Also, I will never forget it as the first place I ever got asked to
build a petabyte system...

For example, IO limitations were mainly centered around accessing large
amounts of data that wouldn't fit in 128/256Gb of RAM setups, which ended up
usually on disks. Even on ZFS/btrfs raid0 ssd's, interface limitations were
being hit daily..(sata, backplanes, etc) and the recent PCIE-SSD revolution
would really be able to make a big dent in that particular issue.

