I second the above. I'm about to finish my PhD and within the entire department, I only know of one guy who was self funded. The rest of us all have grants that cover both tuition fees and a tax free stipend which, unless you live in London, is ok.
It does? How can you conclude that without having inspected the missing parts?
It could be a manufacturing defect, it could be all kinds of other things including a design flaw, to conclude that it 'screams of bad servicing' without having any evidence on an incident that is not even a day old is jumping to conclusions.
An educated guess is something entirely different than throwing out the first thing that comes to mind in a complex situation. Evidence, not guesses is where it is at.
I'm merely pointing out that the parent mischaracterized the statement as a conclusion. It's just a guess. (it's also an unnecessarily adversarial post)
You are trying to counter my observation about terminology, guess vs conclusion, by saying that evidence is better. Not really relevant.
The conclusion of United Airlines Flight 232 was that although it was a manufacturing defect, the maintenance crew should have noticed the crack. Normally, cracks slowly spread over time until the part catastrophically fails, giving you time to catch it using various techniques (ultrasound, x-ray, penetrating dyes).
I'm not sure why you think it's reasonable to extrapolate the conclusion from an accident with a 1973 plane to an accident with modern hardware and vastly different fan materials. UA232 had a titanium alloy fan disk, while modern turbofans tend towards a nickel superalloy, sometimes even a single crystal.
As most people mentioned, the issue in C/C++ is aliasing hence why the compiler cannot safely generate SIMD instructions. However, having worked in scientific computing for a few years on CFD solvers (written in C++), I have seen a very large advancement in what the compiler can do ( Intel compilers especially ). Our approach is to use OpenMP 4.0 directives as they also give you data scoping and alignment clauses. It's probably the best of both worlds where there is some much needed input from the programmer and then the compiler takes care of the rest. On our benchmark, a compute bound kernel would perform perhaps 10% better with hand tuned intrinsics vs the autovectorized version via OpenMP. And that is mostly because it removes some intermediary loads and stores when using short vectors in the autovectorized version which are usually done from a higher level cache anyway. In terms of portability, well, you can see why going for the OpenMP version is the safer bet. One important aspect to take into account is that for efficient autovectorization, you need to rewrite a lot of your kernels to use a vector programming paradigm (basically use short vectors of SIMD size -- which can be changed at compile time depending on uarch ) and trust me, then the compiler will be in its comfort zone. I've seen the compiler generate as good instructions for conditional branching as with hand tuned intrinsics ( AVX/AVX2 and AVX512 ). It can also do transposition from an AoS data structures to SoA in flight however our hand tuned kernels still outperform these since we know to use the lower latency instructions. From a performance perspective, without SIMD, we lose on average 2-3X in our simulation turn around time but getting our whole solver vectorized was a pretty mammoth task.
