jasin

In simplistic terms, at supersonic speeds the air particles do not have sufficient time to "get out of the way" of the body moving in the air. This causes the air particles to be compressed into a dense "shock wave", which can cause separation of the air flow from the surface of the airfoil, leading to a stall. The properties of a wing that handles supersonic airflow well are often at odds with a subsonic wing.

While I've always appreciated some music due to some amazing specific technical aspect, such as Jacob Collier's harmonies or Steve Vai's guitar skills, the records I'd take with me on a desert island tend to consist of very simple elements combined and executed just perfectly. And by "perfectly" I mean with all their imperfections and unquantifiable emotional appeal, which has very little to do with the level of technical prowess. I guess what I'm saying is that for me, taste matters more than skill in music.

After years of waiting, it's hard to believe it's finally fixed. Will try this out immediately.

Due to his heart transplant, he was sometimes dubbed as the only man in Wall Street with a heart. Rest in peace.

In my case, CPU usage goes to the roof if I use a scaled resolution instead of the default one. If that is the case with all macOS users with non-default resolution, I wouldn't call it low prevalence.

It certainly does seem to work better with default resolution.

Me too, and as it happens, I'm running on retina with "more space" enabled. Firefox is unusably slow, to the point where I'm probably abandoning it after a few weeks of really trying to get into it. Which is a shame, because I love the idea of multi-account containers and other privacy features.

This is spot on, because often we prepare by wearing a mouth guard, while in reality their protection against getting knocked out basically zero.

I wonder what he thinks of computer science.

Quality debugger integration and easy navigation in code.

Well, of course you don't _need_ it. You can always go and parse the extension string yourself, then call LoadLibrary() and GetProcAddress() to manually setup pointers to the extension functions etc. The point is that you don't have to care about any of that crap when using DirectX. Bear in mind, this is just one example.

Portability etc notwithstanding and purely from an API point of view, there's no question that DirectX is superior to OpenGL. There are lots of examples, but the mere fact that you need _another_ 3rd party API such as GLEW even to be able to use OpenGL's latest features in the first place should speak volumes.

It's a good idea to always name your matrices in a manner that explicitly states the source and destination coordinate systems. So rather than 'projection', 'view' and 'model' you'd have something like 'viewToClip', 'worldToView' and 'modelToView'. Then when you concatenate and invert matrices to create new ones, their names are self-explanatory as are their assumed inputs and outputs. It's quite easy to tell what a 'clipToWorld' matrix does. 'viewProjectionInverted' - not so much.

A couple of comments/elaborations on the "core differences" mentioned in the article:

The first difference mentioned is that whereas the first SSE2 implementations were often implemented using 64-bit ALUs internally, yielding roughly the same performance as doing two equivalent MMX ops manually, this isn't the case with AVX2. However, it may be worth noting, that it largely _is_ the case with the current AVX ("AVX1", i.e. pre-Haswell) implementations.

The second cited difference is that there's a 128-bit "boundary" in many of the operations. This is effectively what can throw down the drain the hopes of getting 2x gains over SSE2 just by naïvely migrating into AVX2. For instance, you cannot do shuffles to/from arbitrary components anymore, but have to consider the 128-bit lane boundaries instead.

The third issue, i.e. data layouts of internal formats and the assumptions of various algorithms are probably the most significant factors that determine how large a benefit you are going to get. Typically the internal data layouts (i.e. is my pixel block size 2x2, 4x4, 16x8 or something else?) are married with the ISA. Thus, when migrating from one instruction set to another, these typically may need to be reconsidered if speed is paramount. Interestingly enough, this means that when the ISA changes, you most likely want to do some higher-level algorithmic optimizations as well.

However, different binaries may generally yield slightly different results due to compilers ordering floating-point operations differently, for example.

The juxtaposition between hardware being the loss-leader over software, and vice versa, is interesting. The article states that "clearly one model is working and one isn't". I'm not sure if this is really the case. For example, in the games console business, the devices were loss-leaders for a long time, but at least Microsoft is now doing more than OK with its Xbox business - granted it took a while to get there. So, over time, loss-leader hardware isn't necessarily a bad strategy.