6 ms·

The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself p

The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself provides traces do they take it into consideration. And even then, I think most perf optimization is in a category of don't do the obviously slow thing, or the accidentally n^2 thing. I partially agree with you though, as the penetration of Arm goes deeper into the programmer ecosystem, any mental roadblocks about deploying to Arm will disappear. It is a mindset issue, not a technical one. In the 80s and 90s there were lots of alternative architectures and it wasn't a big deal, granted the software stacks were much much smaller and more metal. Now they are huge, but more abstract and farther away from machine issues.

mhh__ 6y ago
This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.
- vinay_ys 6y ago
  Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts. Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation. AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted service, obviously) for Linux that run across a fleet of Graviton instances and help you do fleet-wide profile guided optimizations. We should also see a lot of private companies building high-performance services on AWS to contribute to highly optimized open-source libraries being ported to graviton.
  - fhrifjr 6y ago
    So far I found getting started repo for Graviton with few pointers https://github.com/aws/aws-graviton-getting-started https://github.com/aws/aws-graviton-getting-started
    - vinay_ys 6y ago
      What kind of pointers were you expecting? I found it to have quite a lot of useful pointers. Specifically –https://static.docs.arm.com/swog309707/a/Arm_Neoverse_N1_Software_Optimization_Guide.pdf https://static.docs.arm.com/swog309707/a/Arm_Neoverse_N1_Sof... https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.... - these two docs gives lot of useful information. And the repo itself contain a number of examples (like ffmpeg) that have been optimized based on these manuals.
jerf 6y ago
"The vast majority of developers never profile their code." Protip: New on the job and want to establish a reputation quickly? Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. Another bit of evidence developers rarely profile their code is that I can tell my mental model of how expensive some server process will be to run and most other developer's mental models tend to differ by at least an order of magnitude. I've had multiple conversations about the services I provide and people asking me what my hardware is, expecting it to be run on some monster boxes or something when I tell them it's really just two t3.mediums, which mostly do nothing, and I only have two for redundancy. And it's not like I go profile crazy... I really just do some spot checks on hot-path code. By no means am I doing anything amazing. It's just... as you write more code, the odds that you accidentally write something that performs stupidly badly goes up steadily, even if you're trying not to.
- nicoburns 6y ago
  > Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. I've found that a profiler isn't even needed to find significant wins in most codebases. Simple inspection of the code and removal of obviously slow or inefficient code paths can often lead to huge performance gains.
  - mattbee 6y ago
    I mean I love finding those "obvious" improvements too but how do you know you've succeeded without profiling it? ;)
  - foobiekr 6y ago
    Every piece of code I’ve looked at in my current job is filled with transformations back and forth between representations. It’s so painful to behold. Binary formats converted to JSON blobs, each bigger than my first hard drive (!), and then back again, often multiple times in the same process.

mhh__ 6y ago

This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.

vinay_ys 6y ago
Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts. Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation. AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted service, obviously) for Linux that run across a fleet of Graviton instances and help you do fleet-wide profile guided optimizations. We should also see a lot of private companies building high-performance services on AWS to contribute to highly optimized open-source libraries being ported to graviton.
- fhrifjr 6y ago
  So far I found getting started repo for Graviton with few pointers https://github.com/aws/aws-graviton-getting-started https://github.com/aws/aws-graviton-getting-started
  - vinay_ys 6y ago
    What kind of pointers were you expecting? I found it to have quite a lot of useful pointers. Specifically –https://static.docs.arm.com/swog309707/a/Arm_Neoverse_N1_Software_Optimization_Guide.pdf https://static.docs.arm.com/swog309707/a/Arm_Neoverse_N1_Sof... https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.... - these two docs gives lot of useful information. And the repo itself contain a number of examples (like ffmpeg) that have been optimized based on these manuals.

jerf 6y ago

"The vast majority of developers never profile their code." Protip: New on the job and want to establish a reputation quickly? Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. Another bit of evidence developers rarely profile their code is that I can tell my mental model of how expensive some server process will be to run and most other developer's mental models tend to differ by at least an order of magnitude. I've had multiple conversations about the services I provide and people asking me what my hardware is, expecting it to be run on some monster boxes or something when I tell them it's really just two t3.mediums, which mostly do nothing, and I only have two for redundancy. And it's not like I go profile crazy... I really just do some spot checks on hot-path code. By no means am I doing anything amazing. It's just... as you write more code, the odds that you accidentally write something that performs stupidly badly goes up steadily, even if you're trying not to.

nicoburns 6y ago
> Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. I've found that a profiler isn't even needed to find significant wins in most codebases. Simple inspection of the code and removal of obviously slow or inefficient code paths can often lead to huge performance gains.
- mattbee 6y ago
  I mean I love finding those "obvious" improvements too but how do you know you've succeeded without profiling it? ;)
- foobiekr 6y ago
  Every piece of code I’ve looked at in my current job is filled with transformations back and forth between representations. It’s so painful to behold. Binary formats converted to JSON blobs, each bigger than my first hard drive (!), and then back again, often multiple times in the same process.