C Is Not a Low-Level Language • Hacker News Board

Re: C Is Not a Low-Level Language

#321

Post by zengid » Fri, May 04, 2018, 6:10 AM UTC

munificent wrote: post #93

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing? I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance co…

I agree that this article hits pretty hard against a lot of assumptions about how our machines are working.

I also feel like the author is trying to say something about how imperative scalar (meaning 'operates on one datum at a time') languages are causing more trouble than they're worth. Sophie Wilson said something similar in her talk about the future of microprocessors [1]. This implies that declarative and functional semantics would be more amenable to parallelization, as the author mentions in the article, as well as allowing the compiler more freedom to deduce a suitable 'reordering' of operations that would better fit the memory access heuristics the machine is using.

[1] https://youtu.be/_9mzmvhwMqw?t=26m30s

Re: C Is Not a Low-Level Language

#322

Post by kartickv » Sun, May 13, 2018, 4:45 AM UTC

Tobba_ wrote: post #176

marshray wrote: post #140

Earlier quoted context omitted.

This argument has been made since the introduction of the JVM in the early mid-90's. 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 might still be possible. The JVM and .NET both have their speed annihilated by their awful choice of memory model.

What are some languages that have a better memory model and work faster with a JIT rather than an AOT compiler?

For that matter, does Java code execute faster or slower with an AOT compiler than with HotSpot? I did a quick Google search but couldn't find an answer, except for JEP 295 saying that AOT is sometimes slower and sometimes faster :(

Re: C Is Not a Low-Level Language

#323

Post by kartickv » Sun, May 13, 2018, 4:48 AM UTC

pjmlp wrote: post #290

mattnewport wrote: post #286

Earlier quoted context omitted.

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.

JIT vs AOT is an implementation detail, nothing to do with a programming language as such, unless we are speaking about dynamic languages, traditionally very hard to AOT. 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…

For someone who doesn't develop for the MS stack but is still curious, what are these ways to avoid allocations and GC in performance-critical paths?

Re: C Is Not a Low-Level Language

#324

Post by kartickv » Sun, May 13, 2018, 6:06 AM UTC

skybrian wrote: post #174

munificent wrote: post #93

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing? I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance co…

It seems like the article is mostly useful for inspiring research; that is, most of us aren't the target audience. I'm wondering what will happen as GPU's become more general-purpose. What's next after machine learning? Would it be possible to make a machine where all code runs on a GPU? How would GPU's have to change to make that possible, and would it result in losing what makes them so useful? What would the OS an…

Or, conversely, could the iPhone 11 have 20 cores that are optimised not for latency but for power-efficient execution, such as how much you can do before the device runs out of battery? These would still be ARM, and backward-compatible with mainstream languages like Swift, so will have a low barrier to entry.

Maybe apps will be allowed to run longer in the background, if there are always extra CPU cores available that don't consume much power.

Re: C Is Not a Low-Level Language

#325

Post by kartickv » Sun, May 13, 2018, 6:10 AM UTC

robochat wrote: post #223

munificent wrote: post #93

I really really liked this article, and reading the comments here is blowing my mind. Did we read the same thing? I think it's a strong insight that insight that chip designers and compiler vendors have spent person-millenia maintaining the illusion that we are targeting a PDP-11-like platform even while the platform has grown less and less like that. And, it turns out, with things like Spectre and the performance co…

I also really liked the article and found it thought provoking. This is all way above my pay grade but I like to think that there is a more optimal cpu design and language pairing that we will eventually reach and it's fun to imagine what that might look like. Obviously, it would be very hard to shift the incumbent model in reality. We just have to look at the lack of prosperity for the Itanium and Cell processors to…

It'll be an interesting exercise to ask the Clang folks to relax backward compatibility, this designing a new language, if it makes their compiler go faster.

That could be deployed as a new language, or adding features to existing ones, like value types in Java, or even compiler switches that relax some C rules for faster speed. Imagine -fpointers_cant_be_cast_to_ints or -freorder_struct_fields.

Re: C Is Not a Low-Level Language

#326

Post by kartickv » Sun, May 13, 2018, 6:45 AM UTC

PeterisP wrote: post #110

jackhack wrote: post #9

Earlier quoted context omitted.

Thanks for the TLDR. But if that's the argument, then not even assembly is sufficient, as control over speculative branching and prefetch is only accessible via microcode in the CPU. I think the argument is improperly framed. This is a discussion over public and private interface. The CPU is treated as a black box with a public interface (the x86+ instruction set). Precisely how those instructions are implemented (on…

The argument implied in the article is that choosing a different public interface (breaking "C compatibility" and the imposted limitations) could bring a serious performance improvement. While precisely how those instructions are implemented (on chip microcode) is a private matter for the chip design team, we do care how much resources it takes to implement these instructions, since if we can enable a more efficient…

Is there any evidence in favor of the argument that breaking C compatibility will increase execution speed without shifting the optimisation burden to programmers or compilers?

For example, have research CPUs been built that optimise for Erlang rather than C that provide better efficiency for the same amount of programmer effort than an X86 CPU running C?