5 ms·
I'm not saying that D is defined by that. I'm simply saying that if you're comparing to C or C++, you are talking about use cases that are defined by performanc
by quicknir 7y ago
I'm not saying that D is defined by that. I'm simply saying that if you're comparing to C or C++, you are talking about use cases that are defined by performance and/or memory management (or else, they are being used for legacy reasons). If you have a green field project that doesn't have massive performance concerns, and doesn't have to be specifically in C or C++ for other reasons (toolchain availability, available developer resources, etc), you probably aren't using C or C++.
Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.
- WalterBright 7y agoThere are people who specifically use D for writing high performance applications. They find it faster than C++ for a rather subtle reason - D code is more plastic, meaning it is easier to refactor D code trying out different algorithms looking for a faster one.
- quicknir 7y agoI'm sure these people exist but they're the exception rather than the rule. The two biggest industries in SG14, the C++ low latency study group, are games and HFT. In both these areas, D penetration is pretty much zero. And in HFT at least while many features would be nice (especially reflection), I can't imagine it would be anything but a performance hit. Just the fact that the best D implementation for performance is llvm based, and most people do not find that llvm produces assembly as good as gcc or icc, is already an instant global hit.
- WalterBright 7y agoD reflection is at compile time, not runtime, so no performance hit.
- quicknir 7y agoI didn't intend to imply otherwise but I see my wording was unclear. I meant that D generally would be a hit, though it's only really speculation either way.
- p0nce 7y agoIf you use the same backend... no. They are both native languages with "no room below". llvm vs icc could be a hit, but that's all really.
- WalterBright 7y agoThere is no inherent reason that D code would be slower than C++ code. I should know, I've written a C++ compiler and know where the bloat is buried, and designed D to eschew features that would be inherently slower than the C++ counterparts. You can even turn off the runtime array bounds checking.
- pjmlp 7y agoBoth of which use their own C++ subset, while ignoring the standard library. So even C++ isn't good enough for them. Yet a few vocal anti-C++ devs in the game world, from Insiomatic Games are now at Unity driving HPC# efforts, so there's that.
- quicknir 7y agoHFT doesn't subset C++ nor does it ignore the standard library. Given you're totally wrong about one I'm not inclined to believe you on the other, and I have an examples from the standard library used in game dev eg atomics.
- WalterBright 7y agoThe people I know using C++ for games wrote their own atomics library :-)
- quicknir 7y agoWell you can certainly elect to torture yourself if you really want to. Atomics in C++ compile to assembly in very straightforward ways and there isn't really an enormous design space there. Preshing certainly makes it seem like Ubisoft is using C++ atomics; if it makes sense for them with so many developers and creating AAA games... I'd be curious to know the motivation for writing their own.
- jcelerier 7y ago> Atomics in C++ compile to assembly in very straightforward ways in release mode.
- pjmlp 7y agoDisabling RTTI and exceptions is subseting C++, as it is outside of ISO C++ requirements, even if is common support among C++ compilers. As for game developers, you don't have to look any further than Unreal, CryEngine or EASTL, or a couple of talks at GDC Vault. So who's right?
- mhh__ 7y agoLLVM and GCC are so close together these days that it makes almost no difference practically, and when it does you should start optimizing based around your code not your compiler. Root of all evil etc. etc.
- quicknir 7y agoDude I mean the context in which I'm discussing this is a large organization operating on timescales shorter than microseconds with numerous people involved in optimizing every single part of the pipeline. We are waaaaaaaaaaay past the point of "premature" optimization. This is just optimization, and optimization where a few percent difference between compilers is huge. Your comments read like you're explaining optimization to a beginner, it's a bit bad faith tbh.
- mhh__ 7y agohttps://www.phoronix.com/scan.php?page=article&item=gcc-clang-2019&num=1 https://www.phoronix.com/scan.php?page=article&item=gcc-clan... GCC and LLVM have broadly similar performance characteristics(i.e. for any arch/uBenchmark combo there is another that puts the other one faster). If GCC is appreciably faster for your purpose, then fair enough but LLVM is not drastically slow by any means (Especially when you consider that any "Anything you can do..." Between LLVM and GCC moves much faster on the LLVM side due to a much saner codebase)
- erk__ 7y agoYou are talking about it like comparing a Ford to a VW they are pretty much the same, but what the poster above talks about is more like comparing formula 1 cars where a single percent of engine power can win or lose you the race. The difference may be small enough for by far the most purposes, but this one is where the small difference can cost a lot.
- GoblinSlayer 7y agoHmm... the thread started with GC, are you sure you want to allocate memory while struggling for the last percent of performance?
- GoblinSlayer 7y agohttps://www.phoronix.com/scan.php?page=news_item&px=GCC-9.1-Compiler-Released https://www.phoronix.com/scan.php?page=news_item&px=GCC-9.1-...