4 ms·

Because old habits die hard. Using 'unmanaged' languages for 'performance' reasons is no longer a good reason, because the likes of C# have shown multiple time

• iopq 10y ago
  The difference is not negligible: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Sure, it's silly benchmarks, so I wouldn't take the results as gospel. But the fact is, nobody who writes C# managed to produce a benchmark yet that beats a C++ program. Fast languages like Rust have managed to at least match the performance of C in some benchmarks (and even beat it in others).
  • hvidgaard 10y ago
    Properly unmanaged code will probably always be faster than managed code. But the point still stands. Code in a managed language, identify the hot spots and inject highly performant unmanaged code there. There is no need to go full C++ for 99.999% of all projects.
    • igouy 10y ago
      Like this? http://benchmarksgame.alioth.debian.org/u64q/program.php?test=knucleotide&lang=csharpcore&id=5#log http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... How should /unsafe be set with .Net CORE csproj ?
      • igouy 10y ago
        I only knew the command line option which no longer worked. Once I found the project.json "buildOptions": { "allowUnsafe": true } I was able to fake something for dotnet migrate and find the needed setting: <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <AllowUnsafeBlocks>true</AllowUnsafeBlocks> </PropertyGroup> </Project>
  • willtim 10y ago
    It's worth pointing out that the majority of large C++ projects contain non-deterministic memory management (reference counting) and cache-inefficient object structures like C#.
    • iopq 10y ago
      Absolutely. But note that if you don't have cycles, reference counting of SOME objects is faster than having a GC for everything. The RAII idiom when used in C++ helps with statically determining that some objects can be released at defined points without having to reference count them.
  • NKCSS 10y ago
    If they were properly written, I'd accept that, but just take a look at how vastly different things these two are doing: http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=csharpcore&id=8 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
    • iopq 10y ago
      Nobody stops you from submitting a different version that's faster.
    • igouy 10y ago
      Isn't that the usual explanation for why some program is faster than some other program? They do things differently.
  • lmm 10y ago
    > nobody who writes C# managed to produce a benchmark yet that beats a C++ program No, but I've seen Haskell programs that were much faster than the C++ program they replaced, which is what matters in the real world. Microbenchmarks measure what happens if you have the time to polish every single line to perfection. If you have infinite developer time then C++ will be faster than most languages. But infinite developer time is a negligible use case.
    • igouy 10y ago
      Did the Haskell programs implement the same algorithm?
      • lmm 10y ago
        It implemented the same business requirements. I don't know or care what algorithm was involved (indeed I wouldn't really say there was one).
        • igouy 10y ago
          "Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" :-)