C Is Not a Low-Level Language

Post by gh02t » Wed, May 02, 2018, 5:11 AM UTC

mattnewport wrote: post #161

gh02t wrote: post #148

Earlier quoted context omitted.

Itanium suffered performance wise initially because they had trouble with compilers, but that's not the whole story. You also have to consider that AMD launched AMD64, which was backwards compatible, at about the same time. Later on the Itanium compilers got better, but on release it became a choice of "sluggish, incompatible and expensive Itanium with potential to perform well in the future" versus "backwards compat…

> which ultimately doomed it even when a lot of the issues were resolved later on. Was there ever a point in the Itanium's history where there were Itaniums that ran mainstream software with better performance than equivalently priced x64 processors?

Post by molteanu » Wed, May 02, 2018, 5:34 AM UTC

11thEarlOfMar wrote: post #268

>403 Error - Access Forbidden We are sorry ... ... but we have temporarily restricted your access to the Digital Library. Your activity appears to be coming from some type of automated process. To ensure the availability of the Digital Library we can not allow these types of requests to continue. The restriction will be removed automatically once this activity stops. We apologize for this inconvenience. Please contac…

Post by geokon » Wed, May 02, 2018, 6:17 AM UTC

dahart wrote: post #7

> A processor designed purely for speed, not for a compromise between speed and C support, would likely support large numbers of threads, have wide vector units, and have a much simpler memory model. Sounds like a GPU? > Running C code on such a system would be problematic, so, given the large amount of legacy C code in the world, it would not likely be a commercial success. It seems like ATI & NVIDIA are doing okay,…

Post by pjmlp » Wed, May 02, 2018, 6:36 AM UTC

dnautics wrote: post #242

mattnewport wrote: post #149

Earlier quoted context omitted.

There's not that much overlap between the kind of optimizations that JITs do and the optimizations that modern CPUs do. The promise of JITs outperforming AoT compiled code has never really materialized. The performance advantages of OoO execution, speculative execution, etc. are very real and all modern high performance CPUs do them. Attempts to shift some of that work onto the compiler like Itanium and Cell have lar…

arguably the "sufficiently advanced compiler" (cue joke) has arrived (sadly, post Itanium, Cell) in the form of a popularized LLVM[0], so it's improper to claim failure based on two, aged datapoints. The flaws of OOO and SpecEx are evident with the overhead required to secure a system (spectre, meltdown) in a nondeterministic computational environment, and there is certainly a power cost to effectively JITting your c…

Post by pjmlp » Wed, May 02, 2018, 6:44 AM UTC

mattnewport wrote: post #150

lmm wrote: post #141

Earlier quoted context omitted.

> Seems to me like if, in practice, JIT provided better performance then by now people would be rewriting their C/C++ code in Java and C# for speed. It's a little bit faster, not faster by enough to matter. If you're going to rewrite C/C++ code for speed you'd go to Fortran or assembler, and even then you're unlikely to get enough of a speedup to be worth a rewrite. New projects do use Java or C# rather than C/C++ th…

> New projects do use Java or C# rather than C/C++ though. Nobody is picking Java/C# over C/C++ for performance reasons.