That was my point - this way you eat only one recursive call, not two. And in general case (or naive qsort implementation) one recursive call is enough to burn (on bad input) through all your allowed stack.

Interesting. But just as a side note: I thought that people generally stopped rolling their own linear algebra code and started to use precanned one from Intel,amd,nVidia etc. I'm sure matlab is that way.

On stack size issue - the point was about a case of malicious/pathological input.

Yes, but they are clever about what and when they put on that stack. In their case it's indeed no more than log base 2 frames (non overlapping intervals with biggest one larger than the rest combined with the "rest" following the same pattern)

Sure, but that would also mean that debug compiled code, optimized code, ported code - all would behave too differently. Which, again, not a sound engineering practice.

I would guess that that "custom stack" lives in the heap, so in that case the limitation on program's stack size does not apply.

Very deterministic. Thus, easy to screw with. Just populate sample points with that worst case pivot value and voilà. Well... it needs to be done for all consecutive rounds so it's not completely trivial but doable.

If the algorithm is made very unlucky with selection of the pivot, then it will need one stack frame per each 2 data elements. So yeah, I think it's doable (if pivot selection is stupid in some predictable way)

WTF?! We're talking about general recursion, not some stupid, easily avoidable cases. Even in the case of qsort - you need to make 2 (not one) recursive calls one for left and one for right, and you need to keep the midpoint somewhere on the stack... Basically it's easier to roll your own, totally heap based accounting than try to be clever with stack frames. Plus GP explicitly said that there is recursion and your c compiler does not do tail recursion anyway (or you can't count on it)

Recursion makes for elegant code, but in production code should be avoided. At least when you have no control of the input data. The reason is that there is a fairly tight restriction on stack size (you have to explicitly tell your OS that you need large stack). As a result you will coredump if your input is the right kind of nasty.

At least with ECC you'll get _some_ feedback (it's random so it will pop from time to time) indicating that something fishy is going on. With regular ram all corruptions are silent so you'll get random crashes that will drive you crazy...

I seriously doubt that difference in load is due to drive speed, at least not directly. Their pods are connected by slow (1Gb?) Ethernet. My guess is that there is a sort of interference effect between disk rotation speed, network data rate, buffer sizes, tcp window size etc.

Oups. Yes, I meant ZFS.

Actually, as somebody pointed out, if you put any modern copy-on-write file system (xfs, btrfs etc.) on that puppy, SMR disk will work just like any other hard drive.

My guess, is that due to the way they write data onto platter, this drive is pretty much useless for random writes (even more so than a regular hard drive). It's good only for huge sequential writes i.e. just bulk storage. Knowing this, they, allegedly, added some long term reliability features and slapped "archival" moniker.