What little we've seen of x86 micro ops (the great work reverse engineering the k10 microcode), shows that the micro ops look very much like x86 instructions. Still predominantly two address, RMW instructions for instance. Very similar to the original 8086's microcode structure rather than some reaction to the RISC movement, despite the common trope to state the contrary.
Can't wait to see more information about the goldmont microcode work to see if that holds for intel as well as it does for AMD.
It is partly historical notoriety. It allows one to prove certain statements that seem counter-intuitive. So proofs that employ it can often be viewed with some skepticism.
Moreover, this axiom is _independent_ of the other axioms in ZFC. It is in fact possible to have entirely self-consistent "worlds" of mathematics, ones where axiom of choice is true, and ones where it is false.
If it seems weird that math can give you contradictory results, remember that the difference only shows up when you deal with some form of infinity (e.g. when performing an operation on an infinitely large set). For any usage of math in the real world, the truth or falsity of this axiom won't give you contradictory results.
One of my highest-cited papers didn't pass peer-review. But that's okay. The citations (of the pre-print version) speak for themselves. If papers like these are good enough that new students entering the field use it as a ramp-up resource, they won't hesitate to cite it over and over again when they submit something for peer-review.
So journal publication is not the only means of recognition.
Speaking of which, computer science is a bit weird in that conference papers tend to have higher visibility than journals, even though the latter still has some of its grandfathered glory. Not all conferences are equal, obviously. Some have a more rigorous submission process than others. But our field definitely carries a bit of skepticism about the value added by journal publishers.
They do only have an API and the (trained) model (parameters) are not released. But I believe the "semi-public" here refers to the fact that access to the API is limited to invitees (with the ability to add your name to a waitlist).
> SQLite was originally designed with a policy of avoiding arbitrary limits. [...] Unfortunately, the no-limits policy has been shown to create problems. Because the upper bounds were not well defined, they were not tested, and bugs were often found when pushing SQLite to extremes.
Thanks -- that makes total sense, all for guaranteed tests.
Though I shudder to imagine the effort that goes into testing a 281 TB database.
Do they purchase all those hard drives and make one enormous RAID concatenated disk set? Or is there a way to more cheaply virtualize that by combining a bunch of max-sized 16 TB AWS EBS instances? What types of errors are even likely to come up at that point -- errors in SQLite's internal logic, or errors in the operating system or drivers?
The TH3 test harness for SQLite (https://www.sqlite.org/th3.html) supports a virtual filesystem in which we can create test database files that appear to be very large but that don't actually contain much data or use much space.
If they have customers who need that kind of database, I'm sure they will be willing to help out with the testing. The setup doesn't have to be too crazy. Storage appliances with 20-30 hard drives are fairly common, actually. Even for individual humans, not just corporations. LVM allows you to easily create a logical volume out of multiple physical volumes, e.g. https://www.redhat.com/sysadmin/creating-logical-volumes.
The material nature of hardware is barely any higher than that of software. Yes, you cannot just copy bits around, but you can take the same design and fabricate millions of chips for pennies. The cost of production for any given chip of Silicon has almost nothing to do with its material cost. It has everything to do with the amount of design work that went into it, just like software. None of that appreciably changes the benefits of cooperation vs competition.
