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.
Tilde, My LLVM Alternative
161–165 of 165 posts
Re: Tilde, My LLVM Alternative
#162Cool. 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.
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
#163Earlier 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.
Re: Tilde, My LLVM Alternative
#164Earlier 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.
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
#165You 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.
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?