281–290 of 326 posts
Earlier quoted context omitted.
> I worded this statement carefully to exclude exotic languages like Haskell or Erlang I suspect that your definition of "exotic" is exactly "not like C".
Which is kinda true. Most popular languages are C like.
Earlier quoted context omitted.
> Sounds like a GPU? Which reminds me I'd love to see a computer running exclusively from a GPU-like CPU. And no, Xeon Phi's don't count. They are cool, but look too much like normal PCs.
Here’s one: https://en.m.wikipedia.org/wiki/Cray-1 They didn’t call it a GPU then, but the SIMD architecture is quite similar at a high level. Larrabee was going to be a GPU-like CPU. https://en.m.wikipedia.org/wiki/Larrabee_(microarchitecture) Here’s a more modern GPU based computer: https://www.nvidia.com/en-us/self-driving-cars/drive-platfor... If you meant something that sits on your desktop and runs Linux, then…
I keep telling people to get used to develop on Xeon Phi's and nobody seems to listen ;-)
Today's Xeon Phi is tomorrow's Core i9.
The points made in the article are certainly valid, but C is low-level in an abstract sense: it is approximately the intersection of all mainstream languages. I.e. if a feature exists in C, it probably exists in every language most programmers are familiar with. (I worded this statement carefully to exclude exotic languages like Haskell or Erlang). Thus C, while not low-level relative to actual hardware, is low-level…
Which languages have pointer arithmetic, longjmp , goto anywhere within a function, address-of operator, memcpy that is equivalent to assignment even for lexical variables, untagged unions, switch with fall-through in absence of explicit break and a textual/token-wise preprocessor?
Of course, some of those tricks are only allowed in SYSTEM/UNSAFE blocks on these languages.
> 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,…
I've only done a bit of GPU kernel writing, but I always found it very .. unergonomic. Its like they mashed C to work in a context it wasn't meant for. Which is understandable since you want to encourage adoption, but I'd guess it's part of the motivation behind creating SPIR-V and allowing people to target other languages to the GPU
NVIdia always allowed multiple language on CUDA via PTX, with the offerings for C, C++ and Fortran coming from them, while some third parties had Haskell, .NET and Java support as well.
Yet another reasons why many weren't so keen in being stuck with OpenCL and C99.
Earlier quoted context omitted.
OK, I guess it comes down to what you call "normal" C. I was defining it as what would run on x86 Windows or Linux.
You can look at C++ AMP too, it runs with all GPUs that support DX11 on Windows, and is a part of the Windows SDK. It's implemented by AMD ROCm on Linux, which also implements HIP/CUDA. Normal C/C++ can run fine on modern GPU architectures.
Earlier quoted context omitted.
"New projects do use Java or C# rather than C/C++ though." But not for speed reasons. Java is in no way faster than well written C/C++
Java might not be, but C# is another matter. Specially after the Midori and Singularity projects, and how it affected the design of C# 7.x low level features and UWP AOT compiler (shared with Visual C++). Also Unity is porting engine code from C++ to C# thanks to their new native code compiler for their C# subset, HPC#.
This article makes some valid points but is overall rather misleading I think. Almost all of the reasons given why C is "not a low-level language" also apply to x86/x64 assembly. Register renaming, cache hierarchies, out of order and speculative execution etc are not visible at the assembly / machine code level either on Intel or other mainstream CPU architectures like ARM or Power PC. If C is not a low level languag…
I played a little bit with gpgpu on the raspberry pi. I’d imagine it’s relativly primitive compared to whatever shaders are compiled to on modern GPUs, but it was humbling to have to manage things like separate, per core, disjoint register files which can only be read 4 cycles after write. The cores are heterogeneous, so there is special hardware for exchanging register reads between cores if necessary.
The sophistication of the compiler does not mean the language is high level. The meaning of a high level language is to do with abstraction away from the hardware. C programmers often wince at languages that are highly abstracted away from the hardware. But those are what are "high level" languages. Especially languages that remove more and more of the mechanical bookkeeping of computation. Such as garbage collection…
Basically it says that the C abstract machine has very little in common with most existing processor.
moreover it makes the point that in the last decades of research for CPUs the focus was "make C go fast" wich ultimately cause meltdown.
Makes me wonder if x86 could be extended to expose the underlying parrellelism. How much faster would my Prolog and Haskell programs run if all branches were executed simultaneously and only the successful path down my search tree returned?
Earlier quoted context omitted.
Java might not be, but C# is another matter. Specially after the Midori and Singularity projects, and how it affected the design of C# 7.x low level features and UWP AOT compiler (shared with Visual C++). Also Unity is porting engine code from C++ to C# thanks to their new native code compiler for their C# subset, HPC#.
The discussion was about JITs vs AoT compiled native code. Unity is not using a JIT runtime for their new Burst compiler but using LLVM to do AoT native compilation and getting rid of garbage collection. If you get rid of JIT and garbage collection then yes, a subset of C# can be competitive in performance with C++ for some uses.
In fact C# always supported AOT compilation, just that Microsoft never bothered to actually optimize the generated code, as NGEN usage scenario is fast startup with dynamic linking for desktop applications.
While on Midori, Singularity, Windows 8.x Store, and now .NET Native, C# is always AOT compiled to native code, using static linking in some cases.
As for GC, C# always offered a few ways to avoid allocations, it is a matter for developers to actually learn to use the tools at their disposal.
With C# 7.x language features and the new Span related classes, it is even easier to avoid triggering the GC in high performance paths.