Earlier quoted context omitted.
His name is italicized because he is the primary author of OCaml (and a plethora of other great tools, like CompCert, the first fully-verified compiler). Overall, an exceedingly competent and productive programmer and scientist. The doctor metaphor isn't perfect; what I was going for is, when you are seeking out an expert's advice and you ignore it, why do you go to see the expert in the first place?
Thanks, that makes sense. I don't disagree about taking expert advice! I was just really disappointed to read the part of the article where the author doesn't bother to figure out how to navigate Intel support and report the bug.
I found a bug in Intel Skylake processors
81–90 of 104 posts
Re: I found a bug in Intel Skylake processors
#82> I worked from the executable provided by SIOU, first interactively under GDB (but it nearly drove me crazy, as I had to wait sometimes one hour to trigger the crash again), then using a little OCaml script that ran the program 1000 times and saved the core dumps produced at every crash. rr can often be a time-saver in situations by providing deterministic replays up to the point of a crash, whereas coredump analysi…
Re: I found a bug in Intel Skylake processors
#83Earlier quoted context omitted.
I know nothing of OCaml culture or why the author is deemed worthy of having his name italicized, but the doctor comparison is upsetting. If the guy who wrote this: I was tired of this problem, didn't know how to report those things (Intel doesn't have a public issue tracker like the rest of us), and suspected it was a problem with the specific machines at SIOU (e.g. a batch of flaky chips that got put in the wrong s…
No he wouldn't. Doctors are not obligated to write up case studies or submit them to medical publications.
> Doctors are not obligated to write up case studies or submit them to medical publications.
That's true, although I think we'd all agree that a person who has the knowledge to create a lifesaving treatment for a disease and doesn't bother writing it down because, well, writing is boring, is behaving rather unethically.
But this is merely computer science, not medicine.
Re: I found a bug in Intel Skylake processors
#84Earlier quoted context omitted.
His name is italicized because he is the primary author of OCaml (and a plethora of other great tools, like CompCert, the first fully-verified compiler). Overall, an exceedingly competent and productive programmer and scientist. The doctor metaphor isn't perfect; what I was going for is, when you are seeking out an expert's advice and you ignore it, why do you go to see the expert in the first place?
Thanks, that makes sense. I don't disagree about taking expert advice! I was just really disappointed to read the part of the article where the author doesn't bother to figure out how to navigate Intel support and report the bug.
Do you have a step-by-step guide for doing that or are you just assuming that there must be some magic way?
Re: I found a bug in Intel Skylake processors
#85GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.
Can we all stop shitting on GCC all the time? Thanks.
Re: I found a bug in Intel Skylake processors
#86Earlier quoted context omitted.
Thanks, that makes sense. I don't disagree about taking expert advice! I was just really disappointed to read the part of the article where the author doesn't bother to figure out how to navigate Intel support and report the bug.
> figure out how to navigate Intel support Do you have a step-by-step guide for doing that or are you just assuming that there must be some magic way?
Re: I found a bug in Intel Skylake processors
#87Earlier quoted context omitted.
Thanks, that makes sense. I don't disagree about taking expert advice! I was just really disappointed to read the part of the article where the author doesn't bother to figure out how to navigate Intel support and report the bug.
Bug reports are gifts from inconvenienced users to vendors who have just done free work on the vendors behalf. There is absolutely no obligation on the part of a user to report bugs.
There's at least one obvious error in your statement: if an inconvenienced user's bug report results in less downtime for other users, it is a "gift" to other users, as well as a "gift" to the vendor.
But it says something about our profession if we regard putting flags down to mark the landmines we find a mere courtesy (a gift!) instead of an obligation. I guess that's a debate for a different time and place.
Re: I found a bug in Intel Skylake processors
#88Earlier quoted context omitted.
That's not what happened. You can reproduce what gcc does easily by trying to compile the following code: int f(int x) { return x | 256; } Gcc generates the following code: movl %edi, %eax orb $1, %ah ret In contrast, clang uses an orl instead of orb . The advantage of using orb is that it generates shorter code with an immediate operand. This is on an x86_64 architecture and does not involve 32-bit code.
My point is that binary executables for Microsoft OSes, and the entire market built around them, are the only reason something like %ah (which is an incredibly stupid and expensive thing to address and the actual source of the bug) is part of the x86_64 architecture in the first place.
Re: I found a bug in Intel Skylake processors
#89Earlier quoted context omitted.
> figure out how to navigate Intel support Do you have a step-by-step guide for doing that or are you just assuming that there must be some magic way?
Since we're communicating via rhetorical questions, are you asserting that it's literally impossible to contact Intel support with a defect, or merely tedious? Does it become easier or more difficult if you have a reproducible test case and the sort of connections a prominent FP compiler person has?
Re: I found a bug in Intel Skylake processors
#90Earlier quoted context omitted.
Bug reports are gifts from inconvenienced users to vendors who have just done free work on the vendors behalf. There is absolutely no obligation on the part of a user to report bugs.
I am shocked by this attitude. Maybe I shouldn't be, and I'll certainly give this all some thought. There's at least one obvious error in your statement: if an inconvenienced user's bug report results in less downtime for other users, it is a "gift" to other users, as well as a "gift" to the vendor. But it says something about our profession if we regard putting flags down to mark the landmines we find a mere courtes…
But just like a user has no obligation to 'mark the landmines' for vendors they also have no such obligation towards other users. They do have a right to receiving bug free software in the first place, alas our industry is utterly incapable of doing so which has lowered our expectations to the point where you feel that we have an actual obligation as users to become part of the debugging process.
That is not going to make our lives better.
What will make our lives better is if software producers accept liability for their crap they put out and if they were unable to opt-out of such liability through their software licenses and other legal trickery.
You're just a small step away from making it an obligation rather than an optional thing for users to report bugs, the only difference is that for you the obligation is a moral one rather than a legal one. I really do not subscribe to that, when I pay for something I expect it to work and I expect the vendor (and definitely not the other users) to work as hard as they can to find and fix bugs before the users do.
But we're 'moving fast and breaking shit' in the name of progress and part of that appears to extend to being in perpetual beta test mode. That's not how software should be built and I refuse to subscribe to this new world order where the end user is also the Guinea pig.
Keep in mind that users have their own work to do, are not on the payroll of the vendors usually have forked over cold hard cash in order to be able to use the code (ok, not in the case of open source) and tend to be less knowledgeable about this stuff than the vendors. They really should not have a role in this other than that they may - at their option - upgrade their software from time to time when told very explicitly what the changes are (and hopefully without pulling in a boatload of things that are good for the vendor but not for them).