A third-option that I would like to see is extending the latter to an Electron alternative (aka using Servo as a cross-platform GUI). There's definitely positives to Electron, but it would be nice to see a more performant, less memory hungry, and more battery friendly alternative.
Servo last time I checked used the same if not more memory (100MB) for basic pages. There doesn't appear to be major differences for that application yet.
Rust makes it much easier to do complex performance optimizations safely, particularly those involving concurrency. The canonical example is the multi-threading of Servo’s CSS processor.
It’s not an automatic magic bullet, but in a world where humans are still writing the code, Rust’s feature set makes many performance optimizations much more practical.
Hypothetically there should be possibilities for significant memory reduction by being able to deploy only what you need from the runtime instead of having everything loaded at once.
The memory usage part isn't really apart of rust or C, but rather that projects like chromium require significant hoops to jump through if you wanted to compile electron with only what you need.
I expect that servo will be tackling this issue, the browser works standalone and that's a hefty achievement in itself.
I'm not personally a rust zealot, but I know that rust builds on LLVM and therefore benefits from some of that very same engineering effort that was built to optimize C and C++.
it's not so much that gcc does anything specific so much as LLVM is just really really inefficient—they don't track compilation time at all so it's easy for releases to regress, half the stuff in there is academics implementing their PhD thesis aiming for algorithmic accuracy with little regard for efficiency, and LLVM's design itself is somewhat inefficient (multiple IRs, lots and lots of pointers in IR representation, etc)
that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it
The rust compiler team now tracks LLVM performance, see [0]. They are able to spot regressions as soon as they get merged, and petition to get the change reverted or performance fixed when the impact is large. This has been fairly successful so far, but obviously needs sustained efforts if we are to ever dream of ever getting halfway decent compilation times.
Not answering your question but in my experience reading assembly output of the two compilers the unoptimized output of Clang is atrocious while GCC is closer of what a human could have wrote. Clang seems to have to do better in optimization passes to archive similar results. Usually Clang was a faster compiler in O1 but I don’t think it’s true anymore.
Hey, please don't be a jerk in HN comments. If you know more than others, that's great, but the thing to do is to share some of what you know so the rest of us can learn something. If you don't want to do that, not posting anything is always an option. But please don't post unsubstantive comments and especially not nasty unsubstantive comments.
I didn't mean that all of your posts were that way, only some of them.
Can I try my luck at persuading you a little? The reason we moderate like this is not because of morality or taste. It's because of the dynamics of a community of HN's size. The goal is simply to have a community that doesn't suck. That is in all our interests, including yours, as you're participating here.
There are other internet communities, smaller and more cohesive ones, and usually with a specific technical focus, that have a culture of shaming people for being wrong or knowing less. Arguably this can help to keep signal/noise ratio high by punishing low-quality, low-effort posts, demanding that people do their homework first, and so on. Some of these communities have functioned pretty well for many years.
But it's not an option for HN—this community is too large and incohesive. If we were to allow it, such tactics would soon spread, not in service of technical accuracy, signal/noise ratio, or anything like that, but just general douchery. Ignorant users would see knowledgeable users treating others that way and would follow the worst part of their example—not the becoming-knowledgeable part (that would require an effort!) — just the being-a-jerk part.
Then we'd see an exodus of users who don't want to be surrounded by that kind of thing. Then general douchery would comprise a higher percentage of what remained, making the next exodus even bigger. For a community like HN, this is how you get catastrophic decline.
In order to keep HN worth participating in, we have to have a culture that is on the good side of these nonlinear effects—i.e. we need interactions that raise overall quality rather than damaging it. Situations when a user posts something wrong or ignorant are a classic example. Correcting misinformation is good, but some ways of doing it harm the ecosystem while others benefit it. You have to consider not only the local (comment-to-comment) interaction but the systemic effect of such interactions as they compound.
That's why, in situations like this, we ask people who know more to share some of what they know, so others can learn. That way you're not just executing a local destroy operation on some mistake, you're helping to raise the level of knowledge of the community and the quality of the thread. These actions have systemically beneficial effects instead of toxic ones. If you (i.e. we all) do that repeatedly, you end up with a community that you actually want to be part of.
Holy shit, Dan! I just gained so much respect for you as a moderator (and therefore participant) in this community.
Taking the time to write out this very thoughtful, insightful reply to someone who may be knowledgeable but was throwing out hostile one-liners, that is impressive and gives such a great deal of credibility to the work you're doing here -- work that largely goes unseen, of course.
Amazing.
(I actually put down the piece of food I was eating, mid-bite, to write this out. You made my day!)
