[HN Gopher] Modernizing compiler design for Carbon's toolchain [...
___________________________________________________________________
Modernizing compiler design for Carbon's toolchain [video]
Author : Rusky
Score : 31 points
Date : 2023-08-26 18:28 UTC (4 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| isaiahg wrote:
| I find carbon and the development of a modern replacement for C++
| intriguing to watch. But for the life of me I can't understand
| why someone would want this over a more mature language like D
| pjmlp wrote:
| The problem with D is changing direction every couple of years
| regarding the next big feature that will finally bring the
| masses into the language, while not quite finishing the last
| big feature that predated it.
|
| Even Andrei Alexandrescu is back doing C++ at NVidia.
| suby wrote:
| I also don't know if the code I write in D today will compile
| 20 years from now. A few months ago there was a discussion on
| the D forums which spilled over here about constant churn due
| to breaking changes in the language.
| mhh__ wrote:
| The guy who wrote that loves controversy.
| sctb wrote:
| At least one major reason is "Interoperate with your existing
| C++ code, from inheritance to templates"
| (https://github.com/carbon-language/carbon-lang).
| [deleted]
| sctb wrote:
| Something that stands out to me from this talk is the idea of
| linearizing ASTs--I was reminded of Aaron Hsu's work on Co dfns.
| There was an excellent YouTube video from years ago (does anyone
| have the link?) where he described how his compiler, written in
| APL, manages its data in an array-friendly linear fashion.
| raphlinus wrote:
| I suspect it may be:
| https://www.youtube.com/watch?v=5I4YPkVU7mY
|
| I'm interested in this because these linearized tree
| representations lend themselves well to processing on GPU. We
| use them in Vello for representing clip and blend groups, with
| quite deep nesting level allowed. By contrast, the traditional
| pointer chasing approach to ASTs limits parallelism and has
| poor utilization of memory bandwidth.
| sctb wrote:
| Thanks for the link! I just found the one I was thinking of,
| which is older but perhaps goes into more detail: https://www
| .youtube.com/watch?v=gcUWTa16Jc0&list=PLDU0iEj6f8....
| posnet wrote:
| Also similar to the design of the Luajit IR.
|
| "Linear, pointer-free IR: The typed IR is SSA-based and highly
| orthogonal. An instruction takes up only 64 bits. It has up to
| two operands which are 16 bit references. It's implemented with
| a bidirectionally growable array. No trees, no pointers, no
| cry. Heavily optimized for minimal D-cache impact, too." [0]
|
| [0] http://lua-users.org/lists/lua-l/2009-11/msg00089.html
| fooker wrote:
| I am a compiler engineer and this is not as great as it seems
| like.
|
| If you are replacing pointer chasing with arbitrary indexes
| into arrays, you are likely going to make it orders of
| magnitude slower for large arrays. (It's barely worth it even
| if the array fits in L1)
|
| It's counterintuitive because pointers have been optimized on
| hardware for about 50 years, and array indices are just
| pointers that your hardware doesn't know about.
|
| The main things that go wrong are hardware prefetching and
| compiler optimizations taking advantage of alias analysis.
___________________________________________________________________
(page generated 2023-08-26 23:00 UTC)