I just skimmed through some of those Glassdoor reviews. They were all quite positive, but I find it interesting that the vast majority were posted Feb-Mar 2016.
Yea that's fair. I was actually thinking of timer coalescing on the server OS for improved power efficiency/performance -- I'm sure IIS, MSSQL, etc. all opt-in to coalescing responsibly.
It sounds like the OSX version is more of a "forced timer coalescing" feature.
As others are saying, Microsoft is a very large company with a great deal of variance in the quality and maturity of teams. I wouldn't consider this description representative.
Azure is still a comparably new team, so I'm not surprised if it is still sorting out its processes. I've hear similar descriptions of Bing teams, and other "startup" divisions in the company.
But there are definitely some brutally effective teams there that far outshine any other non-Microsoft team I've ever seen.
At first I thought was going in a bad direction, but it actually ended up pretty cute.
Basically they asked women if they thought they were beautiful, and if they said "Yes!" they got their meal for free -- it was actually rewarding self-confidence rather than perceived physical beauty.
I like reading these analyses, although I'm afraid headlines like this oversimplify things and give off the wrong impression. There isn't anything inherently wrong with NUMA, it just isn't useful in this situation.
No technology is a 'silver bullet'. Every workload has a different set of considerations that require a different set of technology to optimize.
I agree for this one integer, they obviously should have been using 64-bit. I just take issue with the implication that Blizzard is somehow at fault or unusual for (presumably) not running a 64-bit stack.
They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.
At the time the original code was written, it wasn't possible for a 32-bit integer to overflow, which is presumably why they didn't use 64-bit. That possibility was only introduced in the patch, and no one caught the bug that came with it.
Running 64-bit would have "prevented" this bug simply by virtual of that fact that the default datatype would have been big enough to avoid overflow, but it isn't really a solution. I just find 32-bit vs. 64-bit to be inconsequential to the real mistake, which was an improper software development process.
A x64 CPU will take a single instruction to operate on a both a 64-bit and 32-bit integer, and the CPU registers are all 64-bit, so in that context you are right that it doesn't matter that much between the datatypes.
However, the physical size of the integer as stored in the CPU cache, RAM, and HDD is still going to be 2x as big for a 64-bit integer. In a hypothetical worst case, you are cutting your CPU cache and memory bandwidth in half, which is tragic.
Additionally, while most physical servers are x64, the OS, server software, and virtualization layer is still often 32-bit -- maybe for legacy, maybe for performance, maybe for a lot of reasons. Upgrading that whole stack up to 64-bits just for the luxury of having default 64-bit integers seems misguided.
I assume this was probably a server side bug, since all the accounting would never be trusted to the client side.
If you are writing highly-performant server code, the actually memory size is extremely important. You cannot (should not) abstract away the machine specifics of the datatype if you want to write optimized code.
In some cases where the underlying datatype isn't a concern (e.g. Javascript), I agree with you. But ultimately, this isn't a failure of technology, it is a failure of the software development process.
I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB.
More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).
I can say from personal experience that the customers are probably a bit of both. Engineers walk through looking for parts for their prototypes, and then once the prototypes are complete, come back and set up a contract for 1,000's more of the exact same part for the production run.
To me, that is the real benefit. In America, you can make your prototypes with parts from Digikey or Fry's, but if you actually wanted to make a production run, you have to source all your parts from scratch.
Selling debt to buy back their stock looks like a pretty safe bet. Most of the debt is starting off below ~2.5% interest -- using that to buyback the stock paying ~3% dividends is immediately saving themselves money, in addition to reducing dilution and propping up the stock price.
It seems pretty reasonable to me. If Msft makes $1 billion on 20% of the market, and Amzn makes $3.8 billion (high-end analyst estimate) with 71% of the market, the math roughly matches.
That looks pretty significant. Amazon Web Services are somewhere between $2 and $3.8 billion (depending on which analyst you believe), so Microsoft is potentially within striking distance of taking the crown.
Some of the technical analogies are a little weak, but all the quotes and anecdotes are great.