5 ms·

I love how it's always the native code developers who worry the most about performance implications, when they often have the least to gain from doing so. It m

by Joeri 10y ago

I love how it's always the native code developers who worry the most about performance implications, when they often have the least to gain from doing so. It must be something about being close enough to the metal to realize and care about what happens.

Rusky 10y ago
They're often using native code because they have much stricter performance requirements, which means they have everything to gain by doing so. (Though yes, there is an aspect of your last sentence as well)
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
perfmode 10y ago
The last time I wrote production C++ was at Google. There, when requests are coming in at a torrential rate, every instruction counts. In cases like that, it's perfectly reasonable to sweat the details when selecting a data structure.
- deleted 10y ago
  [deleted]
khedoros1 10y ago
Hopefully if you're using C++, it's because the performance implications matter. And hopefully, you're nitpicking on the implementation of the mapping algorithm for the same reason. Third, that's that only good reason to be close to the metal anymore: that there's a requirement for some particular speed target, and none of the "good enough" solutions are good enough. Otherwise, why wouldn't I build my program in Python or something? If selecting the right data structure just based on Big-O notation will get me to a good enough solution, digging down is just a waste of time, like saving microseconds when network latency is 1000 times the problem.
- pklausler 10y ago
  There are other reasons to use C++ besides performance, and other reasons to not use Python besides performance.
  - khedoros1 10y ago
    Sure, but it's one of the biggest go/no-go reasons. Preexisting codebase, available libraries suitable to the problem domain, platform limitations, desire to obfuscate code, developer experience, desire for speed of development, and whatever else I'm forgetting would be other reasons to choose a particular set of technologies. But the comment I was responding to was about performance implications, and whether or not development was "close to the metal", so my response was too (using C++ and Python as examples of lower-abstraction and higher-abstraction languages).
  - harry8 10y ago
    There are other reasons that are at least 9 times in 10 (probably more) completely dominated by a performance justification on occasions where people actually have the choice rather than having it made for them.
emmelaich 10y ago
There's a element of that but like @khedoros1 says you have it backwards. By comparison, Java programmers typically have very little mechanical sympathy. Just yesterday one suggested to me that he could add a Kafka instance on our machine (rather than a new topic queue on the existing Kafka) to speed up things. I pointed out it would probably make little difference as it would be hitting the same disk. And it would complicate their code because they'd have to switch connection details depending on the topic.
- deleted 10y ago
  [deleted]

by Joeri 10y ago

Rusky 10y ago

They're often using native code because they have much stricter performance requirements, which means they have everything to gain by doing so. (Though yes, there is an aspect of your last sentence as well)

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

perfmode 10y ago

The last time I wrote production C++ was at Google. There, when requests are coming in at a torrential rate, every instruction counts. In cases like that, it's perfectly reasonable to sweat the details when selecting a data structure.

deleted 10y ago
[deleted]

khedoros1 10y ago

Hopefully if you're using C++, it's because the performance implications matter. And hopefully, you're nitpicking on the implementation of the mapping algorithm for the same reason. Third, that's that only good reason to be close to the metal anymore: that there's a requirement for some particular speed target, and none of the "good enough" solutions are good enough. Otherwise, why wouldn't I build my program in Python or something? If selecting the right data structure just based on Big-O notation will get me to a good enough solution, digging down is just a waste of time, like saving microseconds when network latency is 1000 times the problem.

pklausler 10y ago
There are other reasons to use C++ besides performance, and other reasons to not use Python besides performance.
- khedoros1 10y ago
  Sure, but it's one of the biggest go/no-go reasons. Preexisting codebase, available libraries suitable to the problem domain, platform limitations, desire to obfuscate code, developer experience, desire for speed of development, and whatever else I'm forgetting would be other reasons to choose a particular set of technologies. But the comment I was responding to was about performance implications, and whether or not development was "close to the metal", so my response was too (using C++ and Python as examples of lower-abstraction and higher-abstraction languages).
- harry8 10y ago
  There are other reasons that are at least 9 times in 10 (probably more) completely dominated by a performance justification on occasions where people actually have the choice rather than having it made for them.

emmelaich 10y ago

There's a element of that but like @khedoros1 says you have it backwards. By comparison, Java programmers typically have very little mechanical sympathy. Just yesterday one suggested to me that he could add a Kafka instance on our machine (rather than a new topic queue on the existing Kafka) to speed up things. I pointed out it would probably make little difference as it would be hitting the same disk. And it would complicate their code because they'd have to switch connection details depending on the topic.

deleted 10y ago
[deleted]