3 ms·

On the otherhand for many applications memory latency isnt an issue. If network and disk io is your bottelneck investing time in optimising that part of the co

On the otherhand for many applications memory latency isnt an issue. If network and disk io is your bottelneck investing time in optimising that part of the code.

umanwizard 7y ago
Very true, which is why I said "many real-world contexts" and not "always", and "CPU performance" and not "network-bound performance". Anyway, a candidate who mentioned all (or even some) of this to me and then went on to write a linked-list solution after explaining the tradeoffs would be well ahead of the curve, for me, relative to someone who has just grinded Leetcode and not thought much about what is going on under the hood.
- maxheadroom 7y ago
  >...and not thought much about what is going on under the hood. This doesn't make sense to me, the way you've worded this. A person needn't have ever been exposed to linked lists to understand "what's going on under the hood" - which is a far bigger picture than you're trying to get something as confined as linked lists to fill. You're seemingly saying, "You don't know fruit because you know fuck-all about dragonfruit," and that - to me - is a pretty myopic take on things; especially, in a growing cloud-centric world. For example, I would expect that someone who could tell me how the debugger knows where their exception handler is (to be able to handle their exception) would be a better caliber for determining whether they've "thought much about what is going on under the hood" than someone who could just tell me how performant a linked list is, yeah? In the former, it's actually having had to understand what it's doing. In the latter, it's just 'x' type that - maybe - you get exposure to because of uni settings. ...but, to give credit, maybe I'm misunderstanding your intentions, as you've worded them?
  - oblio 7y ago
    How does the debugger know that?
    - maxheadroom 7y ago
      Short-answer: The debugger (in Windows) sits between the first and second and chances, if I recall correctly, to "help" the user by displaying a dialogue notifying them that 'x' is unhandled. Anything in second chance has reached the kernel for handling and is no longer in the user space. You'll often see this (second chance) as exception entries in the Windows Event Log for things like kernelbase.dll, which points to the offending instruction set. The handler in this space typically invokes Watson to generate Watson reports because it was unhandled elsewhere. The debugger prevents all of that. Of course, in JIT, you have things like read-ahead for first-chance exceptions... A good book, in the Windows space, that cannot recommend enough, is Windows Internals[0]. They include how the managed and user spaces interact and coincide with the native and kernel spaces and how all of that transpires, such as how an exception in user mode transitions to kernel before Watson report is created. There's other in-depth resources[1], as well, if books aren't your thing. [0] - https://docs.microsoft.com/en-us/sysinternals/learn/windows-internals https://docs.microsoft.com/en-us/sysinternals/learn/windows-... [1] - https://doar-e.github.io/blog/2013/10/12/having-a-look-at-the-windows-userkernel-exceptions-dispatcher/#lights-on-ntdllkiuserexceptiondispatcher https://doar-e.github.io/blog/2013/10/12/having-a-look-at-th...
flukus 7y ago
Cache is also an extremely limited resource and the more you waste the less other programs have to work with, slowing them down too, some of what your program pushes out of the cache could be slowing down disk and network processing. There's a tragedy of the commons effect happening in our CPU's. That doesn't mean it's always worth otimising for, but it's worth remembering yours isn't the only process running.

On the otherhand for many applications memory latency isnt an issue. If network and disk io is your bottelneck investing time in optimising that part of the code.

umanwizard 7y ago

Very true, which is why I said "many real-world contexts" and not "always", and "CPU performance" and not "network-bound performance". Anyway, a candidate who mentioned all (or even some) of this to me and then went on to write a linked-list solution after explaining the tradeoffs would be well ahead of the curve, for me, relative to someone who has just grinded Leetcode and not thought much about what is going on under the hood.

maxheadroom 7y ago
>...and not thought much about what is going on under the hood. This doesn't make sense to me, the way you've worded this. A person needn't have ever been exposed to linked lists to understand "what's going on under the hood" - which is a far bigger picture than you're trying to get something as confined as linked lists to fill. You're seemingly saying, "You don't know fruit because you know fuck-all about dragonfruit," and that - to me - is a pretty myopic take on things; especially, in a growing cloud-centric world. For example, I would expect that someone who could tell me how the debugger knows where their exception handler is (to be able to handle their exception) would be a better caliber for determining whether they've "thought much about what is going on under the hood" than someone who could just tell me how performant a linked list is, yeah? In the former, it's actually having had to understand what it's doing. In the latter, it's just 'x' type that - maybe - you get exposure to because of uni settings. ...but, to give credit, maybe I'm misunderstanding your intentions, as you've worded them?
- oblio 7y ago
  How does the debugger know that?
  - maxheadroom 7y ago
    Short-answer: The debugger (in Windows) sits between the first and second and chances, if I recall correctly, to "help" the user by displaying a dialogue notifying them that 'x' is unhandled. Anything in second chance has reached the kernel for handling and is no longer in the user space. You'll often see this (second chance) as exception entries in the Windows Event Log for things like kernelbase.dll, which points to the offending instruction set. The handler in this space typically invokes Watson to generate Watson reports because it was unhandled elsewhere. The debugger prevents all of that. Of course, in JIT, you have things like read-ahead for first-chance exceptions... A good book, in the Windows space, that cannot recommend enough, is Windows Internals[0]. They include how the managed and user spaces interact and coincide with the native and kernel spaces and how all of that transpires, such as how an exception in user mode transitions to kernel before Watson report is created. There's other in-depth resources[1], as well, if books aren't your thing. [0] - https://docs.microsoft.com/en-us/sysinternals/learn/windows-internals https://docs.microsoft.com/en-us/sysinternals/learn/windows-... [1] - https://doar-e.github.io/blog/2013/10/12/having-a-look-at-the-windows-userkernel-exceptions-dispatcher/#lights-on-ntdllkiuserexceptiondispatcher https://doar-e.github.io/blog/2013/10/12/having-a-look-at-th...

flukus 7y ago

Cache is also an extremely limited resource and the more you waste the less other programs have to work with, slowing them down too, some of what your program pushes out of the cache could be slowing down disk and network processing. There's a tragedy of the commons effect happening in our CPU's. That doesn't mean it's always worth otimising for, but it's worth remembering yours isn't the only process running.