9 ms·

>Is there any software that you write whose users would not be made happier if the software performed better? Any at all? I'd say security is a bigger issue th

>Is there any software that you write whose users would not be made happier if the software performed better? Any at all? I'd say security is a bigger issue than performance most of the time. And most gains are going to happen within the code itself by, e.g., not writing n^2 when there's a log(n) solution or something similar. Plus we're talking about javascript, and that's likely to be software with network concerns, so your optimizations might be a rounding error compared to performance degradation from slow network connections. >You don't need to know any hidden instructions or secrets to take advantage of the platform. You don't know what they do though. Some of those ops could be more advantageous to performance to use in some cases. You can't fully know the platform if there are secret ops. You can still make optimizations with partial knowledge, but don't pretend to know the platform when the platform manufacturer doesn't tell you everything about it. >The fixes also required no code changes outside of the firmware and the operating system, and knowing the platform is still the best way to write performant software, no matter what is going on to avoid hardware vulnerabilities. Good algorithm knowledge and practice is the most cost-effective way of writing performant code and is more than likely going to be the lion's share of issues.

kasey_junk 7y ago
> Good algorithm knowledge and practice is the most cost-effective way of writing performant code I’d love to see that common thought validated because in practice I’ve seen it to not be true at all. There are lots of cases where the complexity effects of the algorithm are swamped by cache effects. In fact basic foundational assumptions about complexity analysis are dangerously untrue on modern systems. In my experience in either high throughput or low latency systems algorithmic complexity is never the issue. It’s always cache coherence, CPU prefectching/prediction, lock contention or over copying of data.
- vsareto 7y ago
  >I’d love to see that common thought validated because in practice I’ve seen it to not be true at all. If you have Javascript devs that came out of some boot camp with no knowledge of either, do you teach algorithms 101 or low-level CPU programming 101 first? I would argue your codebase would benefit from teaching them algorithms first, then the other one. >In my experience in either high throughput or low latency systems algorithmic complexity is never the issue. Do you encounter those workloads written in Javascript often?
  - emsy 7y ago
    >If you have Javascript devs that came out of some boot camp Do you also go to a doctor that came out of a bootcamp? Is your house built by a constructor that came out of a bootcamp? Would you fly with an aviator that came out of a bootcamp? Would you run banking software made by a developer that came out of a bootcamp?
    - NotATroll 7y ago
      So how, precisely, is anyone supposed to get experience if it's unacceptable to hire them fresh out of "boot camp". Even if you go "INTERNSHIP". Well what, is everyone supposed to stick the unpaid intern on toy apps that don't give them any actual real world experience writing actual production software? Cause then the next argument will just be "Do you also go to a doctor that came out of an internship? Is you house built by a constructor that came out of an internship?". Elitism at its finest.
      - emsy 7y ago
        >Elitism at its finest. Do you think doctors in training get to do open heart surgeries by themselves fresh out of university? Do you think we train aviators that can only fly using the autopilot? Because that's the way we treat software developers. This has nothing to do with elitism and everything with professionalism. Our industry has built training wheels in form of various VMs and high level languages because it missed the opportunity to properly train its workforce.
        NotATroll 7y ago
        Again, just more insane elitism. You keep going to the "OH MY GOD, PEOPLE WOULD DIE" examples to try and make a fairly weak point. No one is going to die, because some noob made a crappy little site out of the millions of crappy little sites, and it's not performing like a demi-god. VMs and high level languages aren't "training wheels". Especially not VMs, that's just complete and utter non-sense. Unless you think literally every website on the web should have a 100% dedicated server box. VMs are good for a great many of things, both noob-friendly and not. As for high level languages, they were meant for one particular thing. To get a task done quickly. Which is largely the real reason why so much software out in the wild performs like crap. Anyone can sit down and spend years making a highly performant piece of software. But when things have to move fast, corners get cut & there's not enough time dedicated to researching to get said product to be as highly performant.
naikrovek 7y ago
> I'd say security is a bigger issue than performance most of the time. you are fucking SKILLED at dodging questions and changing the topic to suit your own needs. you would fail out of a debate class in the first week, though. I was asking about performance. You can be secure and perform well. I ask again: Is there any software that you write whose users would not be made happier if the software performed better? Any at all? > >You don't need to know any hidden instructions or secrets to take advantage of the platform. > You don't know what they do though. Some of those ops could be more advantageous to performance to use in some cases. You can't fully know the platform if there are secret ops. You don't need to know every transistor of the platform to improve performance. You appear to be taking an all or nothing approach to this, and that's just now how this works. The goal is to improve performance with a reasonable amount of effort, NOT to produce the exact perfect binary. If you want to spend hours upon hours with sandsifter[0] then feel free, but I would consider that to be wasted time in a day to day development position. > Good algorithm knowledge and practice is the most cost-effective way of writing performant code and is more than likely going to be the lion's share of issues. No. No, no no no no nonononononno no no no. Does algorithm knowledge contribute? yes. Is it the single greatest way to get performance? Absolutely not. Absolutely not. This is one of those things that everyone "knows" but is actually not true. [0]: https://github.com/xoreaxeaxeax/sandsifter https://github.com/xoreaxeaxeax/sandsifter
- vsareto 7y ago
  >you are fucking SKILLED at dodging questions and changing the topic to suit your own needs. you would fail out of a debate class in the first week, though. Look, you're trying to argue that javascript dev jobs should have this kind of knowledge on their descriptions and I'm arguing there's way more shit to worry about and this is near the bottom level of things javascript devs should know. That's why I opened with "don't increase these job requirements unnecessarily" >Is there any software that you write whose users would not be made happier if the software performed better? Any at all? Yeah, a lot of websites. It just doesn't matter after a certain point. From 10 seconds to 1 seconds? Definitely happier. From 1 second to 0.1 seconds? Happier, but not as much as the first gain. 0.1 to 0.01 or further? They might not even notice it. And this is where the network makes further gains cost ineffective. Take my arguments to C or assembly land with systems programming and I immediately lose on most fronts. Especially if you can translate fractions of a second into more money, there should be no restrictions on how much performance to go after IF speed == money. But if you're doing systems programming with javascript and want the utmost performance, this just looks silly for both of us. >This is one of those things that everyone "knows" but is actually not true. You and kasey_junk have different/better experience than I do, because those questions come up way more often in javascript jobs than what you're promoting.
heisenbit 7y ago
Exactly, usually the big mistakes are made on the macro level. Worrying too much about the micro level is taking away attention where it belongs. There is certainly worth in awareness of performance issues - the key is to recognize the - for most of us - rare instances where it matters.
SilasX 7y ago
>I'd say security is a bigger issue than performance most of the time. Yes! I mean, isn't the tradeoff exactly what got us Spectre? "Hey, let's aggressively pre-compute and cache for performance. Oh, darn, turns out that leaks information..." https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

kasey_junk 7y ago

> Good algorithm knowledge and practice is the most cost-effective way of writing performant code I’d love to see that common thought validated because in practice I’ve seen it to not be true at all. There are lots of cases where the complexity effects of the algorithm are swamped by cache effects. In fact basic foundational assumptions about complexity analysis are dangerously untrue on modern systems. In my experience in either high throughput or low latency systems algorithmic complexity is never the issue. It’s always cache coherence, CPU prefectching/prediction, lock contention or over copying of data.

vsareto 7y ago
>I’d love to see that common thought validated because in practice I’ve seen it to not be true at all. If you have Javascript devs that came out of some boot camp with no knowledge of either, do you teach algorithms 101 or low-level CPU programming 101 first? I would argue your codebase would benefit from teaching them algorithms first, then the other one. >In my experience in either high throughput or low latency systems algorithmic complexity is never the issue. Do you encounter those workloads written in Javascript often?
- emsy 7y ago
  >If you have Javascript devs that came out of some boot camp Do you also go to a doctor that came out of a bootcamp? Is your house built by a constructor that came out of a bootcamp? Would you fly with an aviator that came out of a bootcamp? Would you run banking software made by a developer that came out of a bootcamp?
  - NotATroll 7y ago
    So how, precisely, is anyone supposed to get experience if it's unacceptable to hire them fresh out of "boot camp". Even if you go "INTERNSHIP". Well what, is everyone supposed to stick the unpaid intern on toy apps that don't give them any actual real world experience writing actual production software? Cause then the next argument will just be "Do you also go to a doctor that came out of an internship? Is you house built by a constructor that came out of an internship?". Elitism at its finest.
    - emsy 7y ago
      >Elitism at its finest. Do you think doctors in training get to do open heart surgeries by themselves fresh out of university? Do you think we train aviators that can only fly using the autopilot? Because that's the way we treat software developers. This has nothing to do with elitism and everything with professionalism. Our industry has built training wheels in form of various VMs and high level languages because it missed the opportunity to properly train its workforce.
      - NotATroll 7y ago
        Again, just more insane elitism. You keep going to the "OH MY GOD, PEOPLE WOULD DIE" examples to try and make a fairly weak point. No one is going to die, because some noob made a crappy little site out of the millions of crappy little sites, and it's not performing like a demi-god. VMs and high level languages aren't "training wheels". Especially not VMs, that's just complete and utter non-sense. Unless you think literally every website on the web should have a 100% dedicated server box. VMs are good for a great many of things, both noob-friendly and not. As for high level languages, they were meant for one particular thing. To get a task done quickly. Which is largely the real reason why so much software out in the wild performs like crap. Anyone can sit down and spend years making a highly performant piece of software. But when things have to move fast, corners get cut & there's not enough time dedicated to researching to get said product to be as highly performant.

naikrovek 7y ago

> I'd say security is a bigger issue than performance most of the time. you are fucking SKILLED at dodging questions and changing the topic to suit your own needs. you would fail out of a debate class in the first week, though. I was asking about performance. You can be secure and perform well. I ask again: Is there any software that you write whose users would not be made happier if the software performed better? Any at all? > >You don't need to know any hidden instructions or secrets to take advantage of the platform. > You don't know what they do though. Some of those ops could be more advantageous to performance to use in some cases. You can't fully know the platform if there are secret ops. You don't need to know every transistor of the platform to improve performance. You appear to be taking an all or nothing approach to this, and that's just now how this works. The goal is to improve performance with a reasonable amount of effort, NOT to produce the exact perfect binary. If you want to spend hours upon hours with sandsifter[0] then feel free, but I would consider that to be wasted time in a day to day development position. > Good algorithm knowledge and practice is the most cost-effective way of writing performant code and is more than likely going to be the lion's share of issues. No. No, no no no no nonononononno no no no. Does algorithm knowledge contribute? yes. Is it the single greatest way to get performance? Absolutely not. Absolutely not. This is one of those things that everyone "knows" but is actually not true. [0]: https://github.com/xoreaxeaxeax/sandsifter https://github.com/xoreaxeaxeax/sandsifter

vsareto 7y ago
>you are fucking SKILLED at dodging questions and changing the topic to suit your own needs. you would fail out of a debate class in the first week, though. Look, you're trying to argue that javascript dev jobs should have this kind of knowledge on their descriptions and I'm arguing there's way more shit to worry about and this is near the bottom level of things javascript devs should know. That's why I opened with "don't increase these job requirements unnecessarily" >Is there any software that you write whose users would not be made happier if the software performed better? Any at all? Yeah, a lot of websites. It just doesn't matter after a certain point. From 10 seconds to 1 seconds? Definitely happier. From 1 second to 0.1 seconds? Happier, but not as much as the first gain. 0.1 to 0.01 or further? They might not even notice it. And this is where the network makes further gains cost ineffective. Take my arguments to C or assembly land with systems programming and I immediately lose on most fronts. Especially if you can translate fractions of a second into more money, there should be no restrictions on how much performance to go after IF speed == money. But if you're doing systems programming with javascript and want the utmost performance, this just looks silly for both of us. >This is one of those things that everyone "knows" but is actually not true. You and kasey_junk have different/better experience than I do, because those questions come up way more often in javascript jobs than what you're promoting.

heisenbit 7y ago

Exactly, usually the big mistakes are made on the macro level. Worrying too much about the micro level is taking away attention where it belongs. There is certainly worth in awareness of performance issues - the key is to recognize the - for most of us - rare instances where it matters.

SilasX 7y ago

>I'd say security is a bigger issue than performance most of the time. Yes! I mean, isn't the tradeoff exactly what got us Spectre? "Hey, let's aggressively pre-compute and cache for performance. Oh, darn, turns out that leaks information..." https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...