Live data from Hacker News

Tilde, My LLVM Alternative

yasserarg.com

161–165 of 165 posts

Re: Tilde, My LLVM Alternative

#161
post #94

Earlier quoted context omitted.

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.

Well, if the consumer market thinks that 64 bit architectures are a core benefit (for whatever irrational reason) and are willing to pay for it, industry will/does deliver. It's still overkill for all but a few applications. But I never saw in my more than thrity years in embedded systems that a company did well on a long term when wasting money for non-essential capabilities.

Re: Tilde, My LLVM Alternative

#162
post #158
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.

> that good compilation speed was not a design goal

Not sure how this relates to my statement. I was talking about an optimizer, not about compilation speed. I'm neither using QBE, but Eigen, for good reasons.

Re: Tilde, My LLVM Alternative

#163
post #139

Earlier quoted context omitted.

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.

Difference being that if you automate backups they're, well, fully automatic, whereas writing good commit messages always continues to take time.

Re: Tilde, My LLVM Alternative

#164
post #155
post #139

Earlier quoted context omitted.

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.

"why something is written in a certain way" most likely doesn't even have an answer while a project is still in the rewrite-large-parts-frequently stage. Sure, you could spend some time conjuring up an explanation, but that's quite possibly gonna end up useless when the code is ruthlessly rewritten anyway.

That said, specific fixes or similar can definitely do with good messaging. Though I'd say such belongs in comments, not commit messages, where it won't get shadowed over time by unrelated changes.

Re: Tilde, My LLVM Alternative

#165
post #160

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.

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

Executable is executable, there's no magic in C code, it's just frontend for LLVM IR.

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

Do you have any good benchmarks about how big the difference is?

Post reply on HN