This is what I meant. I am using .Net extensively for the same reasons including C#. The only advice I have to people who want to be proficient programmers is to get some exposure to C++ to know where things came from. And there is added benefit of being able to implement some procedures using GPU or C++ AMP for some specific needs. Another important thing to remember is that programming requires to be multilingual because of constantly changing technology.
I can understand if this was C# vs Java, but why are we having a language war between C++ and C#? There are several nice features about C++, e.g. resource management vs C# IDisposable, templates vs C# generics, compiler support and platform neutrality; almost everything has C++ bindings, much cleaner way to access a wide range of tools as opposed to .NET interoperability and C# marshaling. vicirek's point has some credit - it boils down to the fact that 'faster' aspects of the .NET framework class library simply mean better, more heavily-optimized implementations than the C++ standard library (e.g. System.IO). Then I'd much rather build GUIs with C# than C++. C# .NET development is a much more centralized experience, since there's one really, really good IDE and a few pariah IDEs mostly for Mono development. Finally, there's always variability in user experiences - I can probably write a production implementation in Fortran 90 faster than C#, but that doesn't mean anything about the two languages besides give possible hints of my age and working background. Moral of the story: (1) C# vs C++ for your financial applications is usually a business cost-benefit decision; (2) you generally speak of faster implementations, not faster languages. (3) Good programmers are usually indifferent to the language choice, as I've said in page 4. So if you need to ask what language you are using, or find yourself participating in language wars, chances are that you're better off using the one you're most familiar with. Now can we go back on topic and I hear more about what you guys are doing with C?
Nvidia Cuda (Gpu Computing). To make it simpler rest of it (non-cuda parts) is written in C++. But on the other hand there are ways of using Cuda and .Net and close competitor is C++ AMP but that code cannot be directly compiled in CLR mode.
I see. I don't really buy into the GPGPU paradigm. I could see uses for it in sell-side pricing, but I haven't found use for it in buy-side trading. If I really grasp for ideas, I could think of a few large matrix operations but I am guessing off the tip of my fingers that there are faster (and more portable) CPU implementations than their GPGPU counterparts after bus overhead. Is there any particular use for it that you can shed light on?
GPUs (Cuda- or OpenCL-based) aren't just plug 'n' go supercomputers. They only shine in applications where you're accelerating an algorithm that lends itself to parallelism. For example, Bitcoin mining and password cracking come to mind.
Ditto - figure you'd be need something embarrassingly parallel to take advantage. How about this: can you take advantage of GPUs to do a single matrix inverse or svd? Cause then I can think of at least some benefit. But I'm not up to the state of the art when it comes to industrial strength numerical implementations.
Nobody jumps with both feet directly to GPU parallelizm without exhausting CPU capabilities first. For GPU bus and memory transfer overhead is exagerrated. I do not have exact timing now but it takes split second to tranfer 1 Gig of data and very often what you need is already sitting on GPU side and only small chunks of data go back and forth. Parallel programming is an art and seemingly non-parallel algorithm can still be parallelized on both CPU and GPU side. It requires experimentation to arrive to best algorithm and sometimes it is hardware dependent especially in case of GPU. Matrix operations are what GPU is made for and most parallel examples start with showing matrix operations.
Well, yes, I know this - since matrix multiplication is the meat of 3d transformations. BUT, my question in particular has to do with factoring large matrices - whether that can be handled in parallel well. Do you have thoughts on this?
By definition GPU processing is parallel and asynchronous unless you schedule 1 block with 1 thread doing for i loop. Modern Gpu gives you enough of "indexing" power to address any large data sets. One can schedule up to 1024 threads in 3 dimensional blocks of about 65000 in each dimension (newer Keppler even more but is weaker in compute loads than previous Fermi) and memory sizes are from 2 to 4 - 6 Giga. Speedup varies depending on data types being processed, kernel scheduling, code etc. and might be from single digits to about 50x that of CPU algorithm (roughly). Factorization is being done on GPU and there are examples/papers posted on this subject.
You aren't a friendly guy are you? What does this have to do with parallel factorization algorithms and their relatively efficiency compared to CPU-only implementations? It does appear you like to throw jargon around, however irrelevant. Okay - now we are getting to what I actually asked. And there are indeed plenty of papers on this subject. I take it you haven't read them? In that case, your contribution of "you can go google that" is noted and thanked. I'm going to to go read those papers now.