The article is going on about how it's unimaginable to be running Windows in that environment, but I recall a few instances of military vessels running Windows in previous years/decades. Some report of US submarine(s) being dead in the water whenever NT crashes, a cruiser losing propulsion due to Windows crash, etc. I think running Windows on subs is not that uncommon.
The funny thing is that I think everyone here could have predicted those outcomes, i.e. blue screen of death and in-operational craft. You wonder what it is like to work in an environment where the obvious is not allowed to be taken into account or ignored when you build systems.
This is disappointing. We have a webapp and (small) GPU datacenter that can extract tens of billions of polygons per day from remote sensing imagery (gis.incogna.com). I felt quite happy to see SimpleGeo working on a decentralized approach to the storage component.
It's fascinating to read another company having evaluated NoSQL and come to an identical conclusion as we did internally.
I love the idea of NoSQL, but Cassandra was horrible (just look their source code or Thrift) and Mongo lost data. I guess 40 years of relational databases isn't so easy to replace.
To be clear, we are still heavy users of Cassandra. We try and objectively match the tool to the problem and in some cases, PostgreSQL was a better fit but not all. In some cases HBase was a better fit.
Also to be clear, scaling is difficult, no matter what the tool. We've had problems with Cassandra, HBase and PostgreSQL (most recently Friday), no storage option is as good as we would like under stress.
I definitely could have been more clear on that. Cassandra has so many great properties, and when we made the decision to use Postgres for the large dataset under question was shortly after 0.7 was released, and it took a while to get more stable.
Yep, I've talked to the AMD engineers who wrote it -- bunch of very smart guys.
My startup (TidePowerd : http://www.tidepowerd.com) has a product called GPU .NET which JIT-compiles CIL (.NET bytecode) directly into GPU machine code; essentially, we've extended the .NET VM onto the GPU to make GPGPU coding as seamless as we possibly could.
We'll be releasing a new version next week with a much-improved API; if you're experimenting with GPGPU coding, please give it a try -- feedback is super-helpful in shaping the API into something that's both really powerful and really easy to pick up and start coding with.
Oh, and GPU .NET is written in F# -- which we don't support just yet for writing your GPU code, but we're hard at work to add that (likely around the end of November)!
How do you deal with documenting the way the code gets mapped on to the GPU architecture? I've found that small tweaks in how things are laid out can cause huge performance gains (or losses) and if you've managed to automate that it would be really great.
Well, we've managed to automate some of it -- things like the memory allocation/transferring we've got down fairly well and the new API we'll be releasing soon will take care of any edge cases.
For some things, like how your structs are organized/laid out, we haven't automatically optimized that yet -- but one advantage of using .NET (vs. native code like CUDA or OpenCL) is that the CLR specs allows a lot of freedom in implementation; so in the future, we could pretty easily implement some code to analyze your data layout / access patterns and reorganize things under the hood for better performance. All without you needing to rewrite your code, of course ;)
As time goes by though, and solidify the rest of our codebase, we'll be able to spend more time adding optimizations to the JIT compilers to get your code running as fast as the hardware allows, as often as possible.
Kind of -- there's 3 different layouts you can use for structs in .NET: "auto", "sequential", and "explicit".
"auto" lets the JIT compiler organize the fields in any order, with any padding bytes, etc. it wants to. This is the default, and changing it is basically a tradeoff between speed now (where the JIT compiler may not recognize where it can optimize something) and speed later (when we add a new optimization and your code automatically executes faster).
"sequential" requires the JIT compiler to layout the fields in the order they're defined, but it can add any padding bytes, etc. it wants to.
"explicit" forces you to specify the offset of each field, and forbids the compiler from re-ordering the fields or padding them in any way. It's rare to use this unless it's to handle interop'ing with a C library which uses some weird data structure as a parameter. You might get a speedup from using it in your GPU code, but since you've taken everything out of the hands of the compiler, there's little room for improvement/optimization.
Very cool. I've been waiting for this sort of thing to happen for a long time. You still have to manage things by hand, but I bet in a year or two that won't be the case.
On the other hand, as CPU's get more/beter vector units what's to stop a rep add or rep mul instruction from automatically vector/parallelizing things for you?
Plenty of compilers/languages already perform autovectorization (to take advantage of SSE, for example); however, the problem in most cases is that the compiler won't (ever) be able to determine, at compile-time, how your code is going to run, so it'll have to take the safe route and not vectorize it, or only vectorize some of it.
Now, what follows is just my opinion: I think in the (relatively near) future you'll see a lot of data-crunching, high-performance code switching away from C to some of the newer functional languages, or even back to some older languages like FORTRAN -- it's easier to express certain kinds of data-parallelism in those languages, which makes less work for the developer while also making it easier for the compiler to generate optimal, vectorized code.
I compared/contrasted TinEye against Google CBIR for a bunch of images (I use TinEye a lot) and I have to say TinEye looks better than Google CBIR so far. TinEye has less "zero results" and more search results overall, I get the feeling TinEye deals with "Photoshopped images" better somehow.
