3 ms·
I don't have a reference now, but I recall reading a paper discussing this myth de C/C++ will always be faster then higher level languages like, say, OCaml. If
by alberich 14y ago
I don't have a reference now, but I recall reading a paper discussing this myth de C/C++ will always be faster then higher level languages like, say, OCaml. If I'm not mistaken, the article presented a scenario where C would be beaten easily because the compiler couldn't safely optimize some parts of the program (due to the use of pointers and manual memory allocation it was not possible to tell what parts of memory was being used where, or something like that), while the OCaml's compiler could.
It is always a matter of using the right tool for the job, after all.
- bunderbunder 14y agoMemory allocation is one spot where C# and other languages that use generational garbage collection very well. Since the heap stays compacted there's no need to spend time hunting around for a sufficiently-sized chunk of free memory. You just throw the new object right on top of the heap. The same characteristic also tends to automatically produce pretty good locality of reference without any special intervention on the part of the programmer. On modern computers the impact of both of these can be significant. For example, in the series I linked above, the thing that motivated the optimization that let Chen finally produce something faster than the C# version was the observation that his program was spending 60% of its CPU time on the 'new' operator. And the cornerstone of the optimization was taking a cue from the way that C# handles memory allocation and implementing a sort of low-fi mimic of generational garbage collection.