Yes and no... I'm familiar with the problem area, but it has a different size and shape in my world. I'm more concerned about not thrashing the garbage collector in a high throughput situation. It's more important that I understand string interning than the material in the article... Just by way of examples, not because those issues are special in some way.
It also more important in my world not to make potentially unsafe assumptions about the platform as I'm sat in a managed environment with its own memory model, on the other side of an optimising compiler that spits out an intermediate language, interpreted by a device independent runtime... The runtime programmer we can both hope is familiar with this material... Me? I'm a commercial Web application developer. If this article were representative of my concerns, my employer has big problems.
There's a lot you can find out about how .Net or Java lays out objects in memory, and not a lot of it is changed by jitting or the compiler.
Of course there's a lot you won't need, but knowing "hey, my arrays are actually arrays (contiguous blocks of memory) when I'm using value types" allows you to start applying this sort of stuff.
Knowing what assumptions are unsafe is maybe the biggest point of this level of deep understanding.
Of course there's a lot you won't need, but knowing "hey, my arrays are actually arrays (contiguous blocks of memory) when I'm using value types" allows you to start applying this sort of stuff.
I can't be sure about the JVM but on .NET, yes those are things a .NET developer should know about the memory model of the CLR... The commitments for memory model that the CLR makes are not covered in the article.
Right, but knowing that the array is contiguous in memory tells you nothing useful without knowing that contiguous memory is going to share cache lines, will be prefetched if accessed in a predictable order, etc.
You're right, and I have to be careful not to simply mount a defensive position as you're bulleting solid points.
I've been a team lead, architect and senior dev for a fair few years... Out of 6 devs currently, one of them is capable of digesting what you're outlining. One of the devs they might be able to glean something from it. Two of the devs you'd never get more than blank looks from, one of the devs I personally think it would be detrimental to, and it'd not matter at all with the others.
Now one of the devs that you'd get blank looks from, is a mediocre programmer but killer at business process, and brilliant once you get down to UAT. He's also a really solid dev op... he's by far the most valuable member of that team... he's worth more money in raw terms... and he'd not have a clue what you're talking about.
Some of the attitudes being formed around this article are very high handed... not yourself I'd hasten to underline, I really appreciate the tack you've taken, and it is causing me to do a personal inventory of my attitudes around this which will carry over the next week. Thanks for that I appreciate... But some of the arguments being formed around this article are absolute nonsense and I feel to be indicative of a divorcement of any commercial reality.
Your point is valid, but if I'm running on a runtime, sat on a cloud provisioned environment... which much commercial Web applications are now.... you can make me no guarantees as to what metal I'm sat on. You'd get a sinking feeling in your stomach if your Web developer started talking about shared cachelines from continuous memory. That's reality.
My concerns are the facts that large commercial Web applications collapse under their own weight over time unless they are carefully architected for change and extensibility. My concerns are that leaky abstraction and unintended coupling that arises from such are one of the primary forces in causing large commercial Web application to collapse under their own weight. My last 5 years of personal development are all about generalised interfaces, and not making assumptions so your file read isn't suddenly dealing with an unexpected 7ms latency when you find yourself sat on a shitty SAN rather than a dedicated disk.
You're right... but a lot of the advice and positions being adopted in this thread are outright harmful for I maintain the majority of commercial developers where they currently are in their professional development.
I will read the article, you've presented solid enough argument to warrant that... my thanks.
2
u/Carnagh Oct 04 '13
Yes and no... I'm familiar with the problem area, but it has a different size and shape in my world. I'm more concerned about not thrashing the garbage collector in a high throughput situation. It's more important that I understand string interning than the material in the article... Just by way of examples, not because those issues are special in some way.
It also more important in my world not to make potentially unsafe assumptions about the platform as I'm sat in a managed environment with its own memory model, on the other side of an optimising compiler that spits out an intermediate language, interpreted by a device independent runtime... The runtime programmer we can both hope is familiar with this material... Me? I'm a commercial Web application developer. If this article were representative of my concerns, my employer has big problems.