well I wont expand on that one.

but anyway I haven't done any kind of comparison between c++ and c-sharp , but I have read plenty of forum comparison related threads around the internet and they basically always end up agreeing that there is no real performance difference worthy of any discussion , well some agree some disagree , I personally love c# its the darn beezkneez , its like multi supportable language for other languages , it is beautiful .

I also love c++ so I wont choose sides here but onward to other points :

with any of those 2 languages you would have much better array's and lists to choose from for your arrays and stuff , you should be able to improve on your code in some ways by making use of some great functionality offerd by any of the 2 language's.

and I just want to say that , you can thread your functions in lite-c by using windows api too , as long as you keep it thread safe and avoid engine functions , you should be able to thread those complex functions and simply wait (1) untill the thread is done .

C++ is compiled to assembler instructions interpreted by the CPU while C# is compiled to virtual instructions interpreted by a VM.
Guess whats faster

well some say c++ because of the many optimizations you can make , plus the fact that it is pre-compiled , orhers disagree to the point that the jit is fast enough to keep up with c++ and others will say no , its the memory where the real difference comes in .

I simply say , it doesn't matter either way if you cannot comfortably code efficient code , if your code is inefficient then no language will safe your behind .

Actually C++ is compiled to machine code, just like Assembler is. There might be some assembler in the intermediate output, but there might also not be, it's all up to the compiler.

And if you want to go down this route, the CPU does not actually execute any of these instructions directly but instead transform them into μops, so if you want, you can see the CPU as one large VM that interprets x86_64 instructions.

In any case though, C# is without a doubt slower, mostly because of all the high level affordances it gives you, whereas C++ is designed with completely different goals in mind. What is better is up to you, at the end of the day though, C# is most likely not your performance bottle neck. Not with todays CPUs, where you are most likely to get IO bound.

Oh, and by the way, C# is compiled to byte code, yes, but that is actually compiled on the target machine to machine code. So actually the CIL compiler has the option to perform platform specific optimizations that a general C++ compiler targeting multiple different platforms can't do. It's the same idea behind Apple's bitcode, where the binary contains LLVM IR which is then optimized for the different platforms. That doesn't mean Objective-C is suddenly an interpreted language running in a VM.

All of that being said, I do like me my C++ and it does have its performance benefits over high level languages like C#. However, if you want to milk the most out of C++ in terms of performance, you will have to pass up on a lot of very nice abstractions that you could otherwise benefit from. However the case though, even hand knitted assembler tuned for one CPU micro-arch only will not perform 6000 times faster than C#, especially _NOT_ for an IO bound operation like reading files, unless gross incompetence is at play.

From what I've read about file I/O in C#, there indeed seem to be some rather slow methods depending on what you do - "5 hours" however is nowhere near that. My assumption is there was something else done in an improper way...

In some cases i also had the impression that CLR code (C#, ...) runs actually faster than a fully optimized C++ program. I can't remember exactly what it was, but it was about a simple algorithm.

If you have an allocation-heavy program that runs rather short, a CLR program will outperform the C++ variant, because garbage collector is trimmed on allocating a really huge bunch of small and large memory.
(The above is an assumption i make based on my knowledge about memory allocation)

Also i don't remember I/O beeing slow in C#. If you always read a single byte and convert it to hex, then print it to another file, this will be slow indeed....

I know I'm not exactly going into what you said, but it's still important and tangentially related to simple algorithms: The thing most people forget is that CPUs are insanely fast because they make assumptions about your code and fancy algorithms are only really good for big values of n! An array will most likely outperform a hash table for even up to a hundred entries simply because a linear search through array is much friendlier to the cache and branch predictor. A lookup in a hash table may very well be O(1), but that doesn't offer you much if it means that the CPU can't predict what's going to happen and can't effectively utilize the pre-fetcher.

Yes, RAM access is fast on a human scale, but it's incredibly slow on the CPU level and stalling on RAM access can easily blow your performance budget right out of the window. On the other hand, CPU caches are insanely fast, the closer they are to the actual core the faster. And if you play by the CPUs rules and effectively utilize the cache, the performance will be through the roof.

As a very real example might be this, now famous, StackOverflow question and answer: http://stackoverflow.com/questions/11227...-unsorted-array

Anyway, since we are already walking down this rabbit hole, here is another thing:



That is true, but, threads are expensive! We are talking ridiculous amounts of expensive here, since the OS has to allocate resources for the thread and initialize it, which are both non trivial. So whatever work you want to perform in the new thread has to be more expensive than that right out of the gate or you will spend more time twiddling thumbs while the new thread is spawned.

On top of that, you introduce a lot of complexity in your code because most of the time you don't want to just create a thread that then just fucks around, but you want to do something with the performed work, so you'll have to work on synchronization of two or more threads. And that is a whole bag of pain you are getting yourself into.

Next up is the issue that not everything is actually threadable! There is a category of problems called 'embarrassingly parallel workload' which is so trivially easy to multithread that there almost always is no reason not to do it. One example would be calculating the histogram of a picture, you can trivially divide the picture up into pieces, let each thread crunch on one piece and then in a last step just combine all the results together. This is so trivial to multithread because each piece of work isn't depending on any other step of the work pieces, ie there is nothing stopping them from being done in parallel. On the other hand, you have things like cryptographic hashes where each step of the work depends on the result of the previous, so you can't parallelize that work.

Now, most of the time you will find some work that is somewhere inbetween, and for those you'll have to test and see if doing them in parallel is actually worthwhile.

A way to help out with that is to employ a thread pool, so instead of creating n threads, assigning them work and then joining those n threads, you have a thread pool which maintains its own set of worker threads and which you can give a bunch of tasks which the thread pool then divides amongst those threads. Now in theory that's simple, in practice not so much. I spend a good month working on a new thread pool system for an unannounced 2nd version of a certain game engine and it's very trivial to end up with a system where scheduling jobs and dividing those jobs between the threads is more expensive than actually performing the work.

Oh, and it's quite easy to blow the CPU cache even harder when having multiple threads contend for the same data.