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

Tilde, My LLVM Alternative

yasserarg.com

Post reply on HN
Print view View original

151–160 of 165 posts

Re: Tilde, My LLVM Alternative

#151

Post by gergo_barany »

negate32 wrote: post #118
mungaihaha wrote: post #4

> I believe it's (LLVM) far too slow at compiling and far too big to be fixed from the inside What are you doing to make sure Tilde does not end up like this?

One of the big things which makes LLVM very slow is the abundance of passes, I believe I last counted 75 for an unoptimized function? My solution for this is writing more combined passes, due to the SoN design I'm combining a lot of things which are traditionally separate passes. For instance, my equivalent to "SimplifyCFG" "GVNPass", "InstCombine", "EarlyCSEPass" and "JumpThreadingPass" is one combined peephole solv…

If this is one of the main things you want to demonstrate, wouldn't it be better to focus on this one goal first, instead of the whole pipeline from a C preprocessor to directly linked executables?

Essentially, if you say that LLVM's mid-end in particular is slow, I would expect you to present a drop-in replacement for LLVM's mid-end opt tool. You could leave C-to-LLVM-bitcode to Clang. You could leave LLVM-bitcode-to-machine-code to llc. Just like opt, take unoptimized LLVM bitcode as input and produce optimized LLVM bitcode as output. You would get a much fairer apples to apples comparison of both code quality and mid-end compiler speed (your website already mentions that you aren't measuring apples-to-apples times), and you would duplicate much less work.

Alternatively, look into existing Sea of Nodes compilers and see if you can build your demonstrator into them. LibFIRM is such a C compiler: https://libfirm.github.io/ There may be others.

It just seems like you are mixing two things: On the one hand, you are making some very concrete technical statements that integrated optimizations are good and the Sea of Nodes is a great way to get there. A credible demonstrator for this would be very welcome and of great interest to the wider compiler community. On the other hand, you are doing a rite-of-passage project of writing a self-hosting C compiler. I don't mean this unkindly, but that part is less interesting for anyone besides yourself.

EDIT: I also wanted to mention that the approach I suggest is exactly how LLVM became well-known and popular. It was not because of Clang; Clang did not even exist for the first eight years or so of LLVM's existence. Instead, LLVM focused on what it wanted to demonstrate: a different approach to mid-end optimizations compared to the state of the art at the time. Parsing C code was not part of that, so LLVM left that to an external component (which happened to be GCC).

Re: Tilde, My LLVM Alternative

#152

Post by tester756 »

teleforce wrote: post #136
tester756 wrote: post #114

You want to create LLVM alternative and you write it in C? I'm saying this as someone who uses LLVM daily and wishes that it was written in anything else than C/CPP, those languages bring so many cons that it is unreal. Slow compilation, mediocre tooling (cmake), terrible error messages, etc, etc. What's the point of starting with tech debt?

It will be so much refreshing if someone write LLVM alternative in D language, its compilation speed is much faster than many compiled languages. Having said that perhaps Tilde can be a good compiler addition for D in addition to the existing GDC (GCC), LCD (LLVM) and the reference compiler DMD. It's interesting to note that Odin is implementing its compiler alternative in Tilde maybe due to some unresolved issues an…

Why not in Go/C#/Rust/Java or Kotlin/etc?

Re: Tilde, My LLVM Alternative

#153

Post by negate32 »

o11c wrote: post #67
muizelaar wrote: post #31

I thought the sea-of-nodes choice was interesting. V8 has been moving away from sea-of-nodes. Here's a video where Ben Titzer is talking about V8's reasons for moving away from sea-of-nodes: https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s . Yasser, the author of Tilde, is is also in the video.

TL;DW version: sea of nodes requires a scheduling pass, which was taking 20% of their compilation time. But it sounds like there's a lot of legacy baggage, so ...

My GCM doesn't take 20% of my compile times last I checked but even so, V8 is gonna be in a special camp because they're comparing against a compiler that doesn't do much code motion. LLVM does a lot of code motion so that "20%" is still being paid by LLVM during their hoisting and local scheduling passes.

Re: Tilde, My LLVM Alternative

#154

Post by LunaCircuit »

DannyBee wrote: post #141
rendaw wrote: post #137

Earlier quoted context omitted.

Critical responses from people in the industry are what I come here to read. I have no doubt of your credentials and I'm not at all qualified to judge the technical details here, but your reply comes off as an emotional kneejerk. I read it a few times and as best I can get this is what you're saying: - You came up with a similar combined replacement pass for LLVM based on years of personal and external research. - It…

" but your reply comes off as an emotional kneejerk." Lots of these come by, it gets tiring to try to provide detailed critiques of all of them. Feel free to go through comment history and see the last one of these to come along and the detailed critiques there :) Meanwhile, let me try to help more: First, the stuff i'm talking about is released. It's been released for years. It is included in LLVM releases. None of…

[flagged]

Re: Tilde, My LLVM Alternative

#155

Post by kccqzy »

dzaima wrote: post #139
kccqzy wrote: post #55

Earlier quoted context omitted.

None of the above. My objection is the lack of explanation. Churn is okay. Prototypes are okay. Toying with ideas is okay. They should all be in the source tree. But I would want an explanation for the benefit of future readers, including the future author. Earlier in my life I have more than once run blame on a piece of code to find myself writing a line of code where the commit message does not explain it adequatel…

For single-author quickly-changing projects I'd guess that it's quite likely for only like 1% of the commits to be looked at to such extent that the commit message is meaningfully useful. And if each good commit message takes 1 minute to write (incl. overhead from the mental context switching), each of those uses better save 100 minutes compared to just looking at the diff.

I suspect you have never worked on single-author projects where you fastidiously write good commit messages. If you never got into the habit of writing good commit message, you won't find them valuable at all when you are debugging something or just wondering why something is written in a certain way. Once you consistently write good commit messages you begin to rely on them all the time.

Re: Tilde, My LLVM Alternative

#156

Post by account42 »

dzaima wrote: post #139
kccqzy wrote: post #55

Earlier quoted context omitted.

None of the above. My objection is the lack of explanation. Churn is okay. Prototypes are okay. Toying with ideas is okay. They should all be in the source tree. But I would want an explanation for the benefit of future readers, including the future author. Earlier in my life I have more than once run blame on a piece of code to find myself writing a line of code where the commit message does not explain it adequatel…

For single-author quickly-changing projects I'd guess that it's quite likely for only like 1% of the commits to be looked at to such extent that the commit message is meaningfully useful. And if each good commit message takes 1 minute to write (incl. overhead from the mental context switching), each of those uses better save 100 minutes compared to just looking at the diff.

And for your average backup system it's only like 1% of backups you need to be able to restore, probably much fewer. Trouble is, your won't know which ones ahead of time - same for commits.

Re: Tilde, My LLVM Alternative

#157

Post by account42 »

Rochus wrote: post #94
shipp02 wrote: post #88

Earlier quoted context omitted.

Given how long it takes for compilers to mature, by the time it's ready I didn't think anyone will care about x86. Similarly for c++11 vs 17. No?

Well, for all applications which don't require to addres more than 4 GB memory, a 64 bit machine is overkill. This especially applies to embedded systems (which make up the majority of all systems). This is unlikely to change for the next fifty years.

Overkill doesn't mean that it won't be the norm. Overspeccing can be much cheaper than keeping niche architectures alive.

Re: Tilde, My LLVM Alternative

#158

Post by lerno »

Rochus wrote: post #2

Cool. The author has set himself a huge task if he wants to build something like LLVM. An alternative would be to participate in a project with similar goals that is already quite progressed, such as QBE or Eigen ( https://github.com/EigenCompilerSuite/ ) ; both so far lack of optimizers. I consider Eigen very attractive because it supports much more targets and includes assemblers and linkers for all targets. I see…

The QBE author has said that good compilation speed was not a design goal. It also outputs asm which then has to be run through GCC or Clang, which nullifies any benefit of being a standalone backend.

Re: Tilde, My LLVM Alternative

#160

Post by lerno »

tester756 wrote: post #114

You want to create LLVM alternative and you write it in C? I'm saying this as someone who uses LLVM daily and wishes that it was written in anything else than C/CPP, those languages bring so many cons that it is unreal. Slow compilation, mediocre tooling (cmake), terrible error messages, etc, etc. What's the point of starting with tech debt?

1. C is universal, any other language is a dependency.

2. If you're using something like C# or Kotlin or whatever, then you're not serious about compilation speed.

3. You will need to provide a C API anyway.

Post reply on HN