6 ms·

>It is important to understand your platform all the way down to the CPU, including things like branch prediction and caches if you want to have performant soft

>It is important to understand your platform all the way down to the CPU, including things like branch prediction and caches if you want to have performant software. Let's not drastically increase job requirements for no good reason. >It's time to learn your platforms, software people. Many of these platforms have undocumented CPU instructions, so until you get a full accounting of that, what's the point? You can't learn the platform fully if they keep that a secret. Secondly, we've had CPU-level issues like spectre and meltdown introduced that affected performance in some cases. We can't even trust the platform makers to get it right!

naikrovek 7y ago
> Let's not drastically increase job requirements for no good reason. Well, I would say that it's a very good reason, and that learning about branch prediction and caches is not a "drastic" step by any means. Is there any software that you write whose users would not be made happier if the software performed better? Any at all? > Many of these platforms have undocumented CPU instructions You don't need to know the secrets of a platform to understand branch prediction and caches, or to use that knowledge to produce software that performs far better than software written without that knowledge. You don't need to know the platform on a logic gate level, you need to understand how the platform executes your code, so that you can take advantage of the strengths of the platform. You don't need to know any hidden instructions or secrets to take advantage of the platform. > we've had CPU-level issues like spectre and meltdown introduced that affected performance in some cases those things didn't affect performance, the fixes for those things did. 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.
- vsareto 7y ago
  >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
>Let's not drastically increase job requirements for no good reason. If anything, job requirements for programming are way too low. I wouldn't let a mechanic anywhere near my car if I knew s/he didn't understand the basics of an Otto engine. I'm the first to admit I don't know as much about modern CPUs as I should, but I don't live in a fantasy world where I convince myself that I don't need to know it. >Many of these platforms have undocumented CPU instructions So we should get the vendors to publish a proper documentation. This doesn't change anything about software developers responsibilities. >CPU-level issues Perfectly answered in a sibling comment so I'll just leave it at that.
- vsareto 7y ago
  >I wouldn't let a mechanic anywhere near my car if I knew s/he didn't understand the basics of an Otto engine. That's hilarious because most of the electronics of cars are utter shit and it has nothing to do with how well those developers knew the CPU. >So we should get the vendors to publish a proper documentation. This doesn't change anything about software developers responsibilities. Most responsibilities are not concerned with low-level optimizations when javascript in particular typically deals with network connections
  - emsy 7y ago
    >That's hilarious because most of the electronics That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional education in programming. >Most responsibilities are not concerned with low-level optimizations when javascript in particular typically deals with network connections I have yet to encounter a javascript program that doesn't run on a CPU. Also, javascript is one of the most versatile and widely used languages. It runs on clients, servers, high end machines and embedded systems. So of course performance matters. If it didn't we wouldn't need WASM, asm.js and countless ridiculous JS engine optimizations. The time "saved" having to learn proper programming by using JS is dwarfed by the time wasted in CPU and end user time.
    - vsareto 7y ago
imtringued 7y ago
>what's the point? You can't learn the platform fully if they keep that a secret. By that logic we should never learn anything.
- vsareto 7y ago
  You can still learn it and use it and make performance adjustments at low level, just don't claim to know it fully. Subtle differences, kind of like low level code. Those ops could be better in some cases, and until you know what they do, you can't answer that.
toast0 7y ago
> Let's not drastically increase job requirements for no good reason. Here's the short version of branch predictor awareness. If you can write your inner loop with fewer conditionals, it will probably perform better. Is it relevant and worth doing? At some level, only if your loop is frequent and fairly tight -- otherwise the difference is likely to be in the noise. On the other hand, writing your code to avoid branches in general can be a reasonable style and get you in the right place by default. Everybody is claiming to be a 'Full Stack' developer these days, but apparently that doesn't include much of the stack.

naikrovek 7y ago

> Let's not drastically increase job requirements for no good reason. Well, I would say that it's a very good reason, and that learning about branch prediction and caches is not a "drastic" step by any means. Is there any software that you write whose users would not be made happier if the software performed better? Any at all? > Many of these platforms have undocumented CPU instructions You don't need to know the secrets of a platform to understand branch prediction and caches, or to use that knowledge to produce software that performs far better than software written without that knowledge. You don't need to know the platform on a logic gate level, you need to understand how the platform executes your code, so that you can take advantage of the strengths of the platform. You don't need to know any hidden instructions or secrets to take advantage of the platform. > we've had CPU-level issues like spectre and meltdown introduced that affected performance in some cases those things didn't affect performance, the fixes for those things did. 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.

vsareto 7y ago
>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

>Let's not drastically increase job requirements for no good reason. If anything, job requirements for programming are way too low. I wouldn't let a mechanic anywhere near my car if I knew s/he didn't understand the basics of an Otto engine. I'm the first to admit I don't know as much about modern CPUs as I should, but I don't live in a fantasy world where I convince myself that I don't need to know it. >Many of these platforms have undocumented CPU instructions So we should get the vendors to publish a proper documentation. This doesn't change anything about software developers responsibilities. >CPU-level issues Perfectly answered in a sibling comment so I'll just leave it at that.

vsareto 7y ago
>I wouldn't let a mechanic anywhere near my car if I knew s/he didn't understand the basics of an Otto engine. That's hilarious because most of the electronics of cars are utter shit and it has nothing to do with how well those developers knew the CPU. >So we should get the vendors to publish a proper documentation. This doesn't change anything about software developers responsibilities. Most responsibilities are not concerned with low-level optimizations when javascript in particular typically deals with network connections
- emsy 7y ago
  >That's hilarious because most of the electronics That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional education in programming. >Most responsibilities are not concerned with low-level optimizations when javascript in particular typically deals with network connections I have yet to encounter a javascript program that doesn't run on a CPU. Also, javascript is one of the most versatile and widely used languages. It runs on clients, servers, high end machines and embedded systems. So of course performance matters. If it didn't we wouldn't need WASM, asm.js and countless ridiculous JS engine optimizations. The time "saved" having to learn proper programming by using JS is dwarfed by the time wasted in CPU and end user time.
  - vsareto 7y ago

imtringued 7y ago

>what's the point? You can't learn the platform fully if they keep that a secret. By that logic we should never learn anything.

vsareto 7y ago
You can still learn it and use it and make performance adjustments at low level, just don't claim to know it fully. Subtle differences, kind of like low level code. Those ops could be better in some cases, and until you know what they do, you can't answer that.

toast0 7y ago

> Let's not drastically increase job requirements for no good reason. Here's the short version of branch predictor awareness. If you can write your inner loop with fewer conditionals, it will probably perform better. Is it relevant and worth doing? At some level, only if your loop is frequent and fairly tight -- otherwise the difference is likely to be in the noise. On the other hand, writing your code to avoid branches in general can be a reasonable style and get you in the right place by default. Everybody is claiming to be a 'Full Stack' developer these days, but apparently that doesn't include much of the stack.