_ihaque

Better scientific overview of this story from In the Pipeline: http://pipeline.corante.com/archives/2015/03/20/biogens_alzh...

On page 7!

"Readers who find Figure II puzzling should recall that a diagram of an imaginary axis must, of course, itself be imaginary."

tmurray is basically right: most of the really big reported gains are artifacts of unoptimized CPU code. Except for hardware special functions on GPUs, you shouldn't be able to exceed the theoretical perf ratios between GPU and CPU, which are roughly ~30x in FLOPs and ~10x in bandwidth. Depending on whether arithmetic or memory is the algorithmic bottleneck, you'll hit one of those limits.

I wrote a paper [1] on this in one particular domain (computational chemistry) more or less as a rebuttal to a paper that claimed enormous GPU speedups; it was a consequence of slow CPU code, not especially fast GPU code.

[1] http://cs.stanford.edu/people/ihaque/papers/2dtanimoto.pdf

True -- you can use (in OpenCL) clEnqueueMapBuffer to get something that looks like memory-mapped IO, but the consistency guarantees are different from regular host-based MMIO. Specifically, if you map a GPU buffer for writes, there's no guarantee on what you'll get when you read that buffer until you unmap the region. (You can think of it as buffering up writes in host memory until you unmap the region, at which point it's DMAed over to the GPU.)

See the "Notes" section in https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/c...

It's a cool idea; as other posters have mentioned, there have been other projects mapping VRAM for swap, etc.

I'd personally be wary of putting anything too important into VRAM. About five years ago I did a bunch of work testing consumer GPU memory for reliability [1, 2]. Because until that time GPUs were primarily used for error-tolerant applications (graphics) storing only short-lived data (textures) in memory, there wasn't a whole lot of pressure to make sure the memory was as reliable as that found on the main system board. We found that indeed, there was a persistent, low level of memory errors that could be triggered depending on access pattern. I haven't followed up for recent generations, but the fact that the "professional" GPGPU boards both clock their memory slower and include hardware ECC is possible cause for concern with leaving anything too important on the GPU for a long time.

There's code [3,4], too, but I haven't actively worked on it in a few years, so no guarantees on how well it runs nowadays...

[1] http://cs.stanford.edu/people/ihaque/papers/gpuser.pdf

[2] http://cs.stanford.edu/people/ihaque/talks/gpuser_lacss_oct_...

[3] https://github.com/ihaque/memtestG80

[4] https://github.com/ihaque/memtestCL

Most modern CPUs have the memory controller integrated on-die, so you'd need a different class of CPU -- and then you're right back to buying a Xeon.

Probably from http://en.wikipedia.org/wiki/Rub'_al_Khali

Along the same vein, Andrew Dalke wrote up an interesting series of blog posts benchmarking different implementations of population count (counting the number of set bits in a word):

http://dalkescientific.com/writings/diary/archive/2008/07/03...

http://dalkescientific.com/writings/diary/archive/2008/07/05...

http://dalkescientific.com/writings/diary/archive/2011/11/02...

The Stanford Bit Hacks page linked in the original article is also very interesting reading for folks into this sort of stuff.

Yes, you have the right idea. Check out our (open-access) paper from last fall: http://www.nature.com/gim/journal/v15/n3/full/gim2012114a.ht...

The report goes to your doctor. We don't issue reports to insurance companies.

Thanks for the pointer! That's what I get for lurking for too long.

Insurers have been barred by law from discriminating based on genetic information since 2008: http://en.wikipedia.org/wiki/Genetic_Information_Nondiscrimi....

Counsyl definitely falls under the scope of HIPAA; we do tests at the request of physicians, so we're like any other lab as far as privacy is concerned. Your employer, parents, or prospective mate would only know about the results if you decide to tell them.

It's also important to note exactly what Counsyl is testing: we're look at severe single-gene disorders, things that in most cases cause severe disability or early death. Importantly, if you only have one defective copy of a gene for which we test, you won't show symptoms of the disease. This is not the kind of thing that should affect your employer or insurer. And, if you're a carrier, it's probably something you should discuss with your prospective mate: if he or she is also a carrier for the same disease, there's a 1/4 chance of your child having that severe condition.

*edit to add the last paragraph

Full disclosure: I work for Counsyl. (In fact, if you watch the video at the bottom of the article, I'm the second speaker.)

The cool thing (well, one of many) about Counsyl is that there are a lot more things going on than pure biology and bioinformatics. Making genomics truly accessible is a software challenge that goes way beyond bioinformatics. There's obviously statistics, machine learning, and robotics running the lab; however, even more problems are pure engineering tasks. For example:

- How do you design the UI/UX around presenting data on 100 genes which can cause severe illness, but which most doctors (let alone patients) have never heard of?

- How do you efficiently accept orders from clinics across the nation, using a mix of web, paper, and EMR (electronic medical records) systems? (For bonus credit: deal with EMRs shipping fresh today on Windows 3.1. For double bonus credit: figure out how to bypass that ancient cruft and bring clinics into the 21st century.)

- How do you bill insurance companies when it can be opaque to even find out which insurance company pays for a given patient's procedures?

- How can you share data with the scientific community in as open a way as possible, without compromising patient privacy?

There's a huge amount of work to be done, so if you're interested in helping out, give us a look: https://www.counsyl.com/jobs/.

(It looks like this article is getting multiply posted, so please accept my apologies for hitting this one too.)

(I guess DarkShikari's comment is nested too deeply for me to reply directly.)

In my (admittedly limited) experience [1], the compiler has actually done pretty decently at optimizing register allocation in intrinsic-heavy loops. I wrote out the assembly loop in [2] with manual allocation into all 16 XMMs and then noticed the compiler managed to optimize 1 of them out.

[1] https://github.com/simtk/IRMSD

[2] https://github.com/SimTk/IRMSD/blob/master/python/IRMSD/theo...

Full disclosure: I work for Counsyl. (In fact, if you watch the video at the bottom of the article, I'm the second speaker.)

The cool thing (well, one of many) about Counsyl is that there are a lot more things going on than pure biology and bioinformatics. Making genomics truly accessible is a software challenge that goes way beyond bioinformatics. There's obviously statistics, machine learning, and robotics running the lab; however, even more problems are pure engineering tasks. For example:

- How do you design the UI/UX around presenting data on 100 genes which can cause severe illness, but which most doctors (let alone patients) have never heard of?

- How do you efficiently accept orders from clinics across the nation, using a mix of web, paper, and EMR (electronic medical records) systems? (For bonus credit: deal with EMRs shipping fresh today on Windows 3.1. For double bonus credit: figure out how to bypass that ancient cruft and bring clinics into the 21st century.)

- How do you bill insurance companies when it can be opaque to even find out which insurance company pays for a given patient's procedures?

- How can you share data with the scientific community in as open a way as possible, without compromising patient privacy?

There's a huge amount of work to be done, so if you're interested in helping out, give us a look: https://www.counsyl.com/jobs/.