Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

Post reply on HN
Print view View original

91–100 of 222 posts

Re: Goodbye C++, Hello C

#91

Post by the_duke »

tayistay wrote: post #11

The article makes me wonder: how much headroom do compilers of newer slow-to-compile languages such as Rust or Swift have for improving compile times?

In addition to the mentioned micro optimizations, I'll add some possibilities from the Rust angle.

Rust has really impressive incremental compilation built in already.

The first compile is annoyingly slow, but additional ones will be surprisingly fast, often finishing in a second or two , even in larger code bases. Especially if you split up your own code into multiple crates.

This could further be significantly improved by a demonized compiler that keeps everything in memory.

Additionally there could be a way to share compilation artifacts via the package registry, also making first time compiles fast.

There is also an effort to use Cranelift as a codegen backend, which can be faster than llvm for debug builds, and has the potential for JIT compiling functions on first use, which would make debug builds a lot faster again as well.

Zig also has some really cool plans in this domain.

There is lots of headroom to make compiling these static languages faster, but compilers would often need to be (re)written from scratch with these compilation strategies in mind.

Re: Goodbye C++, Hello C

#92

Post by Jweb_Guru »

skohan wrote: post #88
Jweb_Guru wrote: post #85

Earlier quoted context omitted.

I love arena allocation (which, incidentally, does entail dynamic resource destruction if you use it per-frame, and which is pretty easy to get wrong if you're just storing raw pointers everywhere--so good bye nice use after free properties), but you absolutely cannot just use arena allocation for everything. GPU resources in particular need to wait on fences and therefore can't have a neatly defined lifetime like wh…

I am speaking from experience, I have written a lot of renderers. > GPU resources in particular need to wait on fences and therefore can't have a neatly defined lifetime like what you're proposing unless you block your whole program waiting for these fences, while other GPU resources are (like I said) immutable and need to live for multiple frames. I don't quite understand why fences are a problem here. As long as yo…

Sorry, but if you think you can just get away with never deallocating any static GPU resources (as you're implying by "just use an arena"!), one of two things is going on:

(1) You are manually managing an allocator on top of the GPU resources in the arena (reintroducing the usual use after free problems). (2) You have written a highly specialized renderer that cannot be reused across programs, as it requires all GPU resources used in any scene to fit into memory at once (and for their exact quantity to be known).

Once you acknowledge that asking for dynamic GPU resource allocation, the rest of what I asked about follows; for instance, you can't reuse whatever portion of the already-allocated resources were freed at the end of the frame unless you can track used resources across frames; you can then either trace the open command buffers each frame or whatever (tracing all the live resources) or use something like reference counting and free once the fence is done (tracing all the dead resources). Hopefully you will acknowledge neither of these is the same as arena allocation.

"dynamic GPU resource application isn't needed for a useful renderer" certainly sounds good, but again does not jive with my experience with renderers (admittedly, most of this involves rendering an open world with streaming assets, but most examples I've seen that aren't super tightly constrained examples require resource reuse of some sort).

Re: Goodbye C++, Hello C

#93

Post by zozbot234 »

thechao wrote: post #3

I like to think of a compiler as a virtual machine whose instructions are the tokens in your code, and whose output is object code. Taken that way, you can for sure optimize the input program (your C++) to execute faster on the interpreter (the compiler). Understanding how the language (any language with such features) is implemented lets you stray away from the slow parts. For instance, in C, every function has a un…

> You can make your C++ code compile fast by simply not using slow paths through the compiler.

Rust is also working on making this easier, BTW. There's still quite a bit of excess monomorphization going on when using generic code, but better support for const: in generics should ultimately obviate this.

Re: Goodbye C++, Hello C

#94

Post by catblast01 »

skohan wrote: post #69
jolux wrote: post #49

Earlier quoted context omitted.

> the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. > in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. C i…

> these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple. >> but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream platforms, unless you register…

> In early PC's, the way you ran software was to copy code from a magazine and compile and run it on your workstation. Being a PC user at all meant being a tinkerer/hacker a few decades ago.

Bullshit. Except for the brief period of time when the Altair was the only thing going on in the Micro space… the Apple II, Atari 800, IBM PC and TRS-80 amongst others were marketed in the late 70s/early 80s with off the shelf, ready to run software. While copying code out of a magazine was something you could do, it wasn’t even the common case then.

> Every release makes it harder to run arbitrary code.

I have not experienced this. Yes Mac OS makes it harder to run random stuff downloaded from the internet, but Llvm, clang, cmake, python from the command line works the same as they always have (you are fetishizing code that is entered yourself after all).

Re: Goodbye C++, Hello C

#95

Post by dthul »

jcelerier wrote: post #40

I wonder what kind of hardware OP runs on, and which compiler is used. Here on my laptop (Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz), on linux, compiling an eigen example takes 0.7 seconds clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ 0,66s user 0,07s system 100% cpu 0,728 total if I put the eigen header in a PCH this drops to 0.1 seconds clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ -include-pch 0,08s…

Does it get significantly slower if you use Eigen's fixed size matrices? I have a C++ project which uses Eigen and some other templates (but nothing crazy) and it is quite slow to compile. Not complaining though because I don't compile often.

Re: Goodbye C++, Hello C

#96

Post by skohan »

Jweb_Guru wrote: post #92
skohan wrote: post #88

Earlier quoted context omitted.

I am speaking from experience, I have written a lot of renderers. > GPU resources in particular need to wait on fences and therefore can't have a neatly defined lifetime like what you're proposing unless you block your whole program waiting for these fences, while other GPU resources are (like I said) immutable and need to live for multiple frames. I don't quite understand why fences are a problem here. As long as yo…

Sorry, but if you think you can just get away with never deallocating any static GPU resources (as you're implying by "just use an arena"!), one of two things is going on: (1) You are manually managing an allocator on top of the GPU resources in the arena (reintroducing the usual use after free problems). (2) You have written a highly specialized renderer that cannot be reused across programs, as it requires all GPU…

I think you are not thinking through all the possibilities here, but you would be surprised how far you can get with this approach

Re: Goodbye C++, Hello C

#97

Post by habibur »

Jweb_Guru wrote: post #79
skohan wrote: post #74

Earlier quoted context omitted.

Why would a renderer need to deallocate memory? And when would a renderer need to deallocate memory?

Renderers need to deallocate memory all the time. For example, they often need to store per-frame data that gets dropped when the frame is over, debug strings, track temporary access to texture/buffer data, manage command buffers, etc. They also have to track resources for lots of data types external to the program (such as GPU data) which often forces them to work with external allocators, as well as having to synch…

> Renderers need to deallocate memory all the time. For example, they often need to store per-frame data that gets dropped when the frame is over

Zero the buff and reuse this same frame as the new frame.

Re: Goodbye C++, Hello C

#98

Post by skohan »

catblast01 wrote: post #94
skohan wrote: post #69

Earlier quoted context omitted.

> these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple. >> but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream platforms, unless you register…

> In early PC's, the way you ran software was to copy code from a magazine and compile and run it on your workstation. Being a PC user at all meant being a tinkerer/hacker a few decades ago. Bullshit. Except for the brief period of time when the Altair was the only thing going on in the Micro space… the Apple II, Atari 800, IBM PC and TRS-80 amongst others were marketed in the late 70s/early 80s with off the shelf, r…

The new windows does not even run on hardware which doesn't have TMP. You really don't see signs that computers are getting more closed?

Re: Goodbye C++, Hello C

#100

Post by jart »

If you want a good case study in repositories that build quickly then check out cosmopolitan libc. Typing `make -j16` it compiles 15,383 .o objects, 69 .a static libraries, and 548 executables, 297 of which are test executables, which are also run by the make command, and all that takes just 40 sec.
Post reply on HN