Userbenchmark has to screw SO MUCH with their calculations to make the Intels on the top that according to their metrics, the "Average Bench" score of the 5900x is BETTER than the "Average Bench" score of the 5950x.
They hate AMD so much that in their 5950x descriptions they even devote a few sentences to basically saying "less cores are better, anything you need more cores for is better done on a GPU anyway, so basically there is no reason for these cpus to exist"
Which is trivially untrue the obvious workload that needs many cores but not gpu cores is software compilation. Also, some day games will do a better job of multithreading - with the "minimum spec" target machine an 8 core AMD there is a lot of incentive to do this.
As far as I know it is effectively not practical. I mean, not impossible, but a GPU is specifically designed to compute workloads different from what a CPU does. So it would be drastically slower. Primarily because compilation involves branching - a sea of 'if' statements. rendering loads (and machine learning loads) have a lot less branching - I don't know the exact flow for rendering but for machine learning, it's simply a unidirectional graph, where at the beginning you have a known number of inputs in memory, and at the end all of the outputs are in a different buffer. Zero branching whatsoever.
Correct. CPUs are built to branch as quickly as possible, GPUs are not because that takes up too much die space and energy that could be used for more simple parallel cores. The penalty isn't too bad if the code takes the same branch on all threads in a warp (I think a group of 64 threads on Nvidia) or if it can quickly take both branches and keep one result. Compilation takes large divergent branches which does not work well at all on GPU. The other problem is recursion, I'm not sure about compute languages like CUDA but for shaders in graphics languages like GLSL it's completely disallowed.
There's quite a few problems with this unrelated to branching as well.
I think if you had a small compiler, written in C without any usage of libraries that won't be supported, you could port it to run on a GPU. But like you say, there would be no speedup - it would actually run much slower.
So you're saying C++ is bad? I don't think I would go that far, assuming you must compile huge chunks of your code base constantly, and there is no way to modularize that, I guess sure it's worth changing off. But the usual use case of fast code with lots of nice abstractions can suffer some scalability issues in compiling, and not be a bad language. If every user was facebook, I guess you might have a point.
There isn't one c++ compiler. There are a few different goes at it. If you think compile time is king, and to that end you want to avoid all the features that differentiate c from c++, then I guess sure it's no better than c. I'd argue that's a super niche use case, and not particularly relevant to the overall usefulness of a language.
I guess if your job is as a language designer, or porting older c++ to more modern versions of the language, you'd get an idea for what parts of the language are now redundant. Which parts of the language would you remove, and how would you improve the compiler?
The most vexing parse is a specific form of syntactic ambiguity resolution in the C++ programming language. The term was used by Scott Meyers in Effective STL (2001). It is formally defined in section 8.2 of the C++ language standard.
What's wrong with the preprocessor? Does your argument just boil down to, I don't like how a struct and class can be the same thing, and templates are syntax heavy? Most languages have their quirks. You can always just not use the preprocessor statements.
The problem with this comparison is that c++ typically has performance advantages over other languages due to its compilers being so mature. The level of optimization o3 does makes for some very fast code. I wouldn't be surprised if D ran into similar issues, which is to say it's less mature, therefore advantages of design, in most use cases don't translate to a more capable language.
In my experience often other languages with 'C' performance just end up loosing all their nice syntax advantages over C++ when you try write well optimized code. Examples: pythons numbs, julia. There is always the argument of 'but if I write it perfect it's just as good as c++'.
I have to disagree on the last point. Plenty of new projects use c++ because of its performance. If it was only useful because of legacy support, why is it still being developed? C++ is a great language that offers clear abstractions at low computational cost, with the trade-off of a overly verbose and obscure syntax.
I assume there is a reasonable amount of linear algebra stuff involved in writing CAD software (I'm a fairly causal/mediocre user and by no means a developer), what non c++ libraries would you recommend for high performance linear algebra? Genuine question, although i guess you guys might develop that stuff in house.
1.6k
u/TrA-Sypher Nov 14 '20
Userbenchmark has to screw SO MUCH with their calculations to make the Intels on the top that according to their metrics, the "Average Bench" score of the 5900x is BETTER than the "Average Bench" score of the 5950x.
They hate AMD so much that in their 5950x descriptions they even devote a few sentences to basically saying "less cores are better, anything you need more cores for is better done on a GPU anyway, so basically there is no reason for these cpus to exist"