6 ms·
Many absolutely fall into the trap of "don't optimise because premature optimisation etc., compiler is smarter than you, and library authors are definitely smar
by Pannoniae 3y ago
Many absolutely fall into the trap of "don't optimise because premature optimisation etc., compiler is smarter than you, and library authors are definitely smarter than you". The result of that approach is that in 2023, our desktop is worse in usability and performance than what is was in 1998.
With SIMD, you always have to check what the compiler generates, you can't just write something and expect it to be vectorised. Similar to other optimisations such as de-virtualisation - it might happen or it might not. If it doesn't, you have to do it yourself by hand, or somehow convince the compiler to do it.
- saagarjha 3y agoMachines aren’t slow because people don’t use SIMD.
- Pannoniae 3y agoOf course, that was a jab at the lack of optimisation in general, not SIMD specifically.
- galkk 3y agoYou don’t even get information/ diagnostics about copy elision / return value optimization in c++, if that happened or not in particular place in the code. Only by looking into assembler :(
- leni536 3y agoNote that RVO is mandatory when returning a prvalue since C++17. IME NRVO happens pretty reliably in the simple case, even on low optimisation levels. There is a proposal for mandatory NRVO in some cases. It would be pretty great, but the proposal didn't move forward for quite a while.
- mlazos 3y agoNah that’s not lack of premature optimization, that’s just electron apps and everyone learning JavaScript.
- wredue 3y agoJavaScript can be quite “fast” if you’re not copying an array 30 times to get one number out of it. Yeah. It’s still slow, as it were. But the JavaScript community also very much aligns with various functional programming ideals like immutability, which takes “kind of slow” to “immensely slow”.
- DarkNova6 3y ago> The result of that approach is that in 2023, our desktop is worse in usability and performance than what is was in 1998. No. This is undoubtedly because every UI nowadays is using JavaScript. This is problem is way waaaaay larger than any premature optimization considerations.
- papruapap 3y agoTypical HN take that is nothing but a lie. Worst experience I ever had in a desktop app were from Java UI applications (jdownloader), python (caliber, pgadmin) or the win 11 super laggy ui (native). Meanwhile now we have a lot of web application with much better performance that their "native" counterpart (For ex: Email clients, Text/Code editors).
- Cthulhu_ 3y agoIs windows 11's UI laggy because of the UI library, or because of fetching things from the internet?
- MrPatan 3y agoNot because of JS in any case. JS is the whipping boy of desktop performance because its ascendance happened at the same time as what you say: interfaces that update on the fly and need data from the net to do anything at all. So now download times get blamed on JS and Electron by the haters. Ah, well.
- DarkNova6 3y agoI'm not sure about this. There are simple JS applications like Postman which can be unbearably slow (try closing tabs in fast succession, you will know what I mean). And this is for local-only data.
- The_Colonel 3y agoJavaScript is the fastest scripting language in existence and it's not close. It's strange that people automatically suspect it has to be the culprit as opposed to e. g. bad application programmers or (more likely) product owners putting more focus on features at the cost of optimization.
- benterix 3y ago> The result of that approach is that in 2023, our desktop is worse in usability and performance than what is was in 1998. I believe there are many more causes, some of them far more significant. Off the top of my head: * the Web and the related delays: people started to accept the fact that there is a small delay in everything they do related to network latency * the general "what Andy giveth Bill taketh away" mindset, and not just among MS developers: "if I have a powerful machine, I should use its full potential, and other people should do it, too" * the notion that programmer's time is more expensive than machine time * the notion that in order to win we need to be first, therefore there is no time to optimize things resource-wise * the belief that users only want features and don't care about speed * the lack of high-quality, developer-friendly, modern cross-platform UI framework resulting in many companies using Electron with its overhead
- wiz21c 3y ago> the notion that programmer's time is more expensive than machine time I do this computation each time I want to code something: time_to_develop + time_to_optimize + time_running and get the solution that minimizes that. Most of the time the optimize part is not worth it (although it'd be so much funnier to do it).
- vladvasiliu 3y agoI thin it's important to think about the context of "machine time". If "machine time" is some computer somewhere that only runs your code, then sure. Even as a customer, it might be cheaper to just pay more for a beefier machine than to pay more for optimizing the software. But when you're building human user-facing apps, you can't always just get a faster computer. As others have said, many instances of lag in windows can be traced to network calls. A 64-core monster would probably wait around just as long as my ultra-low voltage, several year-old lazy ultrabook.
- gbin 3y agoYou should work in the gaming industry or robotics where if time_running > some constant you have no product.
- Cthulhu_ 3y agoI'm not working on anything close to bare metal hardware though; I rely on the libraries, frameworks and runtimes I use for the majority of performance, and have to watch out for expensive re-renders and the like myself. That said, I'm sad that we're building apps in React Native; I tried to advocate for native apps which are much more mechanically sympathetic, but they weren't having it. In hindsight, it was probably the best call since we spend nearly no time on anything device specific and developing features is much faster than it would be if it were native, but it still sucks.
- deleted 3y ago[deleted]
- waysa 3y agoThey don't say you shouldn't optimize at all. But before you do, check what your performance bottlenecks are, take measurements and start from there.
- anonymoushn 3y agoin current_year we've invented programming paradigms that can slow down all parts of the program equally
- dahfizz 3y agoThe issue is different people mean different things when they say "optimization". For some developers, giving any consideration to the performance of your chosen architecture and data structures is "premature optimization"
- tmpX7dMeXU 3y ago[flagged]
- mhh__ 3y agoThe real optimizations are those that deal with memory anyway, which the compiler usually can't and almost always won't do
- 3cats-in-a-coat 3y agoIt's not a trap, the compiler can do micro-optimizations better than any human can because it considers thousands of variables, per target, than you don't even know about. The problem is not realizing what's the scope of micro-optimization. And ignoring architecture and design in general. But that reflects an industry that largely doesn't know and doesn't care. As long as it ships and barely works, it's good enough. Bad software is a victim of excellent hardware.
- RetpolineDrama 3y ago>As long as it ships and barely works, it's good enough. Rails in a nutshell.
- 3cats-in-a-coat 3y agoRails was at one point advertised as the web platform where the CEO can directly type, almost in English, their app, and he never has to pay a programmer anymore. Programmers are obsolete. So... I guess the culture that formed around it, no wonder, wasn't of the brightest people.
- ElectricalUnion 3y ago> COBOL was at one point advertised as the platform where the CEO can directly type, almost in English, their app, and he never has to pay a programmer anymore. Programmers are obsolete. So... I guess the culture that formed around it, no wonder, wasn't of the brightest people. FTFY. Where you can have great things such as: a IS GREATER THAN b a IS GREATER THAN b AND c OR EQ TO d MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE \s It's as old as dirt.
- freilanzer 3y ago> "don't optimise because premature optimisation etc., compiler is smarter than you, and library authors are definitely smarter than you" Everything about that is quite okay if you add "don't optimise prematurely ...". At some point you still need to optimise.
- dahfizz 3y agoThat advice is only for micro optimizations. It doesn't make sense to spend a week aggressively optimizing one function unless you know that function is a bottleneck and the optimization is worth it. But many developers take that to mean "don't pay attention to performance at all". They have bad architecture, bad data structures, sloppy code that copies data all over the place, etc. Then, even if they do go back and micro-optimize that one hot function, the whole app still sucks.
- CyberDildonics 3y agoWith SIMD, you always have to check what the compiler generates, you can't just write something and expect it to be vectorised. You are right about this but everything else is far off. Modern software that runs slow on modern hardware has to be wildly inefficient to make a visible slow down. Even 'OO' programs that are doing lots of small allocations and skipping around in memory are lightning fast on 20 year old computers. Modern hardware is incredible. It's a testament to just how bad some software is that it runs slow. Most software can be sped up by 10x-100x by going from a scripting language to C++. Most software can be sped up 7x-100x after it is in C++ by weeding out excessive allocations and paying attention to memory access patterns. That's all before SIMD and multi-threading.
- intelVISA 3y agoSo, using i++ instead of ++i is why this 400mb Electron app is laggy?
- WalterBright 3y ago> With SIMD, you always have to check what the compiler generates, you can't just write something and expect it to be vectorised. This is indeed a serious problem, and not just because the autovectorizer implementations vary. The SIMD instructions also vary quite a bit between CPUs and CPU architectures. D solves it in a novel way. First off, D does not autovectorize conventional code. D includes an array language, and array operations are converted to vector instructions, if those instructions exist. So, if you try to use an operation that does not exist on the target CPU, the compiler issues an error. The error enables the programmer to select the appropriate action - emulate the behavior, or use another set of operations or algorithms that are equivalent and are supported by the SIMD instructions. This avoids the problem of the compiler silently inserting emulation instructions that may be dramatically slower than alternatives. It saves the programmer the need to do asm dumps of the code to see if it was vectorized or not. Frankly, the whole autovectorization approach bothers me. A compiler is designed to convert high level code into low level instructions. The autovectorizor converts low level code into higher level instructions. It's just fundamentally wrong.
- the8472 3y agoIt would be possible to make iterators more SIMD-friendly than they are today but that would come at the cost of interpreting what the user might have intended and then dropping or introducing additional side-effects (e.g. by skipping things or grabbing a few more items than needed). Without an effects system that makes purity available on the type level libraries can't even conservatively apply those optimizations on pure lambdas because they have no way to tell the pure and impure ones apart.
- 2OEH8eoCRo0 3y agoPremature optimization is more about not home-growing some bespoke fancy data structure before you've even ran the application for example. If it's a bottleneck you can optimize those pieces later. Requirements can also change. Now you've spent a ton of time building something fancy and are less likely to throw it out because you're attached to the big fancy work you put in because we are human.
- pjmlp 3y agoHardly matters when everyone is shipping Electron junk.