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

131–140 of 165 posts

Re: Tilde, My LLVM Alternative

#131

Post by christophilus »

snowfarthing wrote: post #85
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?

I just had a random thought: perhaps it would be a good idea to have a project that doesn't do optimizations, but just focuses on fast compiling. Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... (Of course, at this point, I can't help but think "you don't need to worry about the speed of compilation" in things like Common Lisp or Smalltalk,…

Go’s internal compiler / linker is kind of like that. So is qbe[0] iirc.

https://c9x.me/compile/

Re: Tilde, My LLVM Alternative

#132

Post by lmm »

Rochus wrote: post #61
kibwen wrote: post #58

Earlier quoted context omitted.

C itself is an ultra-complex language. I do not understand the mindset of the "C is simple" crowd. Is it nostalgia or romanticism for the past? If we want to devise a truly simple language, we need to start by realizing that C is just the Javascript of its day: hacked together in a weekend by someone who wished they were using a different language and then accidentally catapulted into the future by platform effects.

What aspects do you consider "ultra-complex"? I agree that it has a very strange syntax, many features of it being unknown to most people; but besides that, it's as easy as Pascal, isn't it?

Just the integer promotion rules are more complex than many languages' entire parser. And undefined behaviour makes the language practically impossible to learn, because there's simply no way to confirm the answer to any question you have about the language (other than "submit a DR and wait a few years for the answer to be published" - even the people who wrote the standard are confidently wrong about what it says, all the time) - you can form a hypothesis about how the language works, write a program to test this hypothesis, observe that the result is what you thought it would be - and you've learnt nothing, because your program was almost certainly undefined behaviour under a strict enough reading of the standard.

Re: Tilde, My LLVM Alternative

#133

Post by lmm »

coolThingsFirst wrote: post #41

Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?

Just you. The best programmers I've known were about that age. (Hell, I'm pretty sure my own peak programming years were about that age)

Re: Tilde, My LLVM Alternative

#134

Post by Aachen »

pkal wrote: post #53
pveierland wrote: post #40

Earlier quoted context omitted.

Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.

Perhaps, but I still think it is lazy. A very nice counter example of someone with high commit standards can be seen in this repository: https://github.com/rmyorston/pdpmake/commits/master/

That doesn't have a commit history going back to what the parent said about the first 200 commits though. It starts off with basically 3 commits all called some variant of "initial public release", after which good commit messages start, so that probably skipped many intermediate WIP states

I agree that one can do good commit messages also early on though. Initial commit can be "project skeleton", then "argument parsing and start of docs", then maybe "implemented basic functionality: it now lists files when run", next "implemented -S flag to sort by size", etc. It's not as specific as "Forbid -H option in POSIX mode" and the commits are going to often be large and touch different components, but I'd say that's expected for young projects with few (concurrent) contributors

Re: Tilde, My LLVM Alternative

#135

Post by Rochus »

lmm wrote: post #132
Rochus wrote: post #61

Earlier quoted context omitted.

What aspects do you consider "ultra-complex"? I agree that it has a very strange syntax, many features of it being unknown to most people; but besides that, it's as easy as Pascal, isn't it?

Just the integer promotion rules are more complex than many languages' entire parser. And undefined behaviour makes the language practically impossible to learn, because there's simply no way to confirm the answer to any question you have about the language (other than "submit a DR and wait a few years for the answer to be published" - even the people who wrote the standard are confidently wrong about what it says, a…

I wasn't aware that it is that critical. I have been doing C projects of all sizes and on different platforms and with different toolchains for forty years, including many where the same code runs on different platforms and is built with different toolchains, and I have never come across an undefined behavior for which there was no practical work-around in reasonable time. I have also never seen a language specification that answers all questions, not even Pascal or Ada. I agree that implicit conversions are an unfortunate feature of C, but I think the same about all languages where you can easily assign floating point to integer variables (or vice versa), for example. Cross-toolchain and cross-platform experiments are a constant activity with all the programming languages I use.

Re: Tilde, My LLVM Alternative

#136

Post by teleforce »

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 and bugs in LLVM [1],[2].

[1] A review of the Odin programming language (2022):

https://graphitemaster.github.io/odin_review/

[2] Understanding the Odin Programming Language (97 comments):

https://news.ycombinator.com/item?id=42348655

Re: Tilde, My LLVM Alternative

#137

Post by rendaw »

DannyBee wrote: post #129
negate32 wrote: post #118

Earlier quoted context omitted.

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…

I'm very confused what magic you believe will achieve what has not so far been achieved. I'm also confused why you believe LLVM didn't start out the exact same way? I say this as one of the main people responsible for working on combined pass replacements in both GCC and LLVM for things that were reasonable to be combined. I actually love destroying lots of passes in favor of better combined ones. In that sense, i'm…

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's faster and has more functionality.

- It's very complex and you're not comfortable that it's possible to achieve various reliability guarantees, so it is unreleased

- Therefore (?) you think the Tilde author also couldn't possibly succeed

AFAICT you also believe that the Tilde author hasn't completed their replacement pass. From their post my take was that it was already done. The part that will mature is additional passes, or maybe optimizations/bugfixes, but not the MVP development.

Your main arguments seem to be probability and appeal to authority (external research, assigned responsibility, industry association). Pretty much all projects and startups fail, but it's because people attempt them that some succeed.

Is the author betting their career on this? Why do their expectations need to be tempered?

I'd be interested in hearing concrete criticisms of their algorithms (have you looked at the code?) or oversights in the design. Maybe the author would too! If you let the author know, maybe you could think of a solution to reduce the complexity or improve the guarantees together.

Re: Tilde, My LLVM Alternative

#138

Post by lmm »

Rochus wrote: post #135
lmm wrote: post #132

Earlier quoted context omitted.

Just the integer promotion rules are more complex than many languages' entire parser. And undefined behaviour makes the language practically impossible to learn, because there's simply no way to confirm the answer to any question you have about the language (other than "submit a DR and wait a few years for the answer to be published" - even the people who wrote the standard are confidently wrong about what it says, a…

I wasn't aware that it is that critical. I have been doing C projects of all sizes and on different platforms and with different toolchains for forty years, including many where the same code runs on different platforms and is built with different toolchains, and I have never come across an undefined behavior for which there was no practical work-around in reasonable time. I have also never seen a language specificat…

> I have never come across an undefined behavior for which there was no practical work-around in reasonable time.

How would you know? You don't generally find out until a newer compiler release breaks your code.

> I have also never seen a language specification that answers all questions, not even Pascal or Ada.

Maybe, but I haven't see "upgrade your compiler, get a new security bug" be defended so aggressively in other languages. Probably more cultural than legalistic - obviously "the implementation is the spec" has its problems, but most languages commit to not breaking behaviour that most code relies on, even if that behaviour isn't actually written in the spec, which means that in practice the language (the social artifact) is possible to learn in a way that C isn't.

> I agree that implicit conversions are an unfortunate feature of C, but I think the same about all languages where you can easily assign floating point to integer variables (or vice versa), for example.

So don't use those languages either then?

> Cross-toolchain and cross-platform experiments are a constant activity with all the programming languages I use.

Sounds pretty unpleasant, I practically never need to do that.

Re: Tilde, My LLVM Alternative

#139

Post by dzaima »

kccqzy wrote: post #55
torstenvl wrote: post #49

Earlier quoted context omitted.

Is your objection to the inevitable fact that requirements churn early on (regardless whether you're doing agile or waterfall)? Or is your objection that solo devs code up prototypes and toy with ideas in live code instead of just in their mental VM in grooming sessions? Or is your objection that you don't think early prototypes and demos should be available in the source tree?

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.

Re: Tilde, My LLVM Alternative

#140

Post by s1gsegv »

pjmlp wrote: post #12
ksec wrote: post #8

>I'm calling it Tilde (or TB for tilde backend) and the reasons are pretty simple, i believe it's far too slow at compiling and far too big to be fixed from the inside. It's been 20 years and cruft has built up, time for a "redo". That put a smile on my face because I remember that was how LLVM was born out of frustration with GCC. I dont know how the modern GCC and LLVM compares, I remember LLVM was fast but resulti…

It is pretty much Visual Studion on Windows and XBox, Nintendo and Sony have clang forks. Embarcadero owns Borland, unfortunely stuff like C++ Builder doesn't seem to get much people outside big corps wanting to use it, which is a shame given its RAD capabilities and GUI design tooling for C++. Also has a standard ABI between Delphi and C++ Builder, which allows to similar development workflows that .NET offered late…

Borland as of a few years ago also ships a clang fork for C++ Builder, interestingly enough. It unfortunately does not solve all of the problems you encounter using C++ Builder in the modern age.

I’ve personally watched the enshittification of too many proprietary tools to ever build something I care about on top of one today, especially something which becomes so fundamental to the design of your application like a GUI toolkit.

I know it sounds crazy, like you’d never bother forking your GUI framework anyway even when it’s open source. But I worked on an application built in C++ Builder, at a company with enough engineering talent and willpower that we would’ve forked the compiler internally to fix its problems and limitations had we been granted access to the source. Instead, I got to watch the product get held back by it year after year, hoping that Borland would care.

Post reply on HN