We (co-author here) are using EEVDF already since its in the latest mainline kernels. We havent noticed any major differences using the default settings, but plan to get around to tuning it later.
I am partial to the iPXE boot idea, you may find https://netboot.xyz useful.
As for how to prepare the images, you need a ramfs image with the root filesystem as a cpio file and a kernel as a vmlinuz file. You then serve these in a basic HTTP file server that your iPXE config points to.
Generating the vmlinuz file is pretty easy given a kernel. The cpio file is trickier. netboot.xyz recommends just grabbing a standard distribution. Otherwise this reduces to the problem of creating your own.
"That allows a single bit to potentially hold two values at once, or for two bits to hold four values at once. Keep scaling those numbers, and you quickly end up with a device that can process data exponentially faster than today’s computers."
Yet another quote for the misrepresentation of science in articles.
"When used as a failure detector, timeouts are just a guess that something is wrong. (If they could, distributed algorithms would do without clocks entirely, but then consensus becomes impossible [10]."
Having just re-read Lynch's paper, can you explain what you mean here? I didn't see anything explicitly relying on time. It could be there is some implicit usage I didnt see. Additionally, the paper's impossibility result is about "perfectly correct consensus" which applies with and without clocks and then has a positive result for "partially correct consensus" (i.e. not deciding a value is a correct result). Im not sure which you mean when you say "consensus becomes impossible" as it is either already impossible (the perfectly correct protocol) with one faulty process or (to my understanding) not dependent on time (the partially correct protocol).
The FLP result (Fischer, Lynch, Paterson) shows that consensus cannot reliably be solved in an asynchronous system (if you do not make any timing assumptions) if one or more processes can fail. The impossibility result shows that any consensus algorithm in such a system will have executions in which it waits forever and never makes a decision, which breaks the liveness property of consensus.
However, if you do allow some timing assumptions — just enough to measure a timeout, nothing more — then consensus becomes possible. In this case, the timeout is known as an "unreliable failure detector". See Chandra and Toueg's paper for details.
In a good algorithm, the safety properties do not depend on timing, only the liveness properties do. Rather than "consensus being impossible" perhaps it would be clearer to say "consensus may never terminate" in an asynchronous system. But "consensus impossible" is the standard way of phrasing this issue in the distributed systems literature.
I'm having trouble relating this comment to the referenced paper [1], which seems to be explicit that its impossiblity result does not apply when synchronised clocks are available.
For example, on page 375: “Crucial to our proof is that processing is completely asynchronous; that is, we make no assumptions about the relative speeds of processes or about the delay time in delivering a message. We also assume that processes do not have access to synchronized clocks, so algorithms based on time-outs, for example, cannot be used.”
You mean the OP's comment or mine? I agree with you if you mean the OP's comment. Though your quote refers to synchronized clocks. I dont think OP is referring to synchronized clocks, though your point that Lynch et al does not rely on timeouts is what Im getting at.
"When used as a failure detector, timeouts are just a guess that something is wrong."
I send a packet over the network. I configured the timeout to be 10 seconds. 10 seconds passes. Is the packet truly lost? Or, maybe the packet was received, processed, and and a response is on the way back, but it takes 20 seconds instead of 10! Or maybe it takes an hour instead of 20 seconds. Or a decade.
We don't know if the packet is truly lost or is just taking >$timeout_timer and making assumptions is dangerous.
My question was about his claim in regards to the result in the paper. In practice, you are right but a consensus algorithm is still "partially correct" if it never decides on a value. It is only incorrect if different nodes decide on different values. For example, paxos does is not guaranteed to decide on a value. So timeouts are useful guessing tools, but I dont see how there is no consensus possible without them.
My understanding is that it is not enough to just be a "qbit based computer" to be able to solve QBP (i.e. perform shors algorithm to break RSA).
These computers are quantum adiabatic computers which are indeed quantum in that they use qbits, but it is not clear that they can perform some operations required for QBP problems. See scott aaronson's blog for more info [1].
The article refers to 1180 MW of _power_. MW is joules/s and the unit of power is the watt (j/s). Your math talks about MegaWatt-Hours.
These are often confused in articles, do you happen to know if that was the case in this article? Did they mean 1180 MWH or 1180 MW as stated? Otherwise your yearly production calculation is very off. 1180 MW (j/s) would produce 10^7 MHW per hour.
I was having trouble understanding why fixed-point arithmetic was particularly useful in game development. In fact, I was curious why fixed point representation was more useful than floating point at all...
Two links deep, I found [1]. The salient being "...floating point representation gives you extra precision for numbers near zero, this extra precision comes at the expense of precision for numbers further out"
The most useful feature of fixed point calculations is its deterministic nature.
Determinism is necessary when multiple parties need to be in the same state, with the state being too large to be exchanged between the parties.
The canonical example are RTS style games where there are hundreds of units, but only the actions of the players are sent to every other players.
The result of the actions are computed independently by all the players. Having all the players be in sync requires determinism in the calculations, which floating point calculations do not provide.
To add to this, when you're trying to minimize information flow among parties, you might have each player only send information to some other players (perhaps only the set that needs to know right now - think unit information from Player A to Player B. This is in the 'fog of war' for player C, so you don't send it. Later, however, the accumulated state needs to be sent to player C when it becomes relevant to her. I made this example up, but it's quite common to minimize the amount of information sent over the network in latency-sensitive networked multiplayer games.)
The short answer is that accumulated calculations deviate in floating point arithmetic, because floats don't behave like mathematical abstract numbers. One easy way to see this is that operations on floats are not associative, especially when you're working on numbers that differ greatly in magnitude. So you don't have the guarantee that (A * (B * C)) = ((A * B) * C). This can end up with state slowly deviating and it all falling apart.
The reason for this is fairly easy to see: floats are represented as A * 2^B (A is the 'mantissa', B is the 'exponent'). In double-precision floating points, the mantissa is 52 bits, and the exponent has 11 bits (1 is left over for the sign bit). So if you have a really small number, say X = 1.125125123 * 2^-22, you can store it with a lot of precision. If you have a really large number, say Y = 1.236235423 * 2^30, you can also store this with a lot of precision. But now add the two together, and you're basically going to throw out the smaller number entirely, because you don't have enough mantissa bits. So essentially (X + Y) gives you Y. Now if you had a third number, say Z = 1.5 * 2^-22, and you were trying to do Y + X + Z, then order matters. Because (X+Z) together might "bump" it up to the point where they are within a multiplicative factor of (2^52) of Y, so they have some impact on the total. But Y + X throws out X, and then (Y + X) + Z throws out Z. So (Y + X) + Z ≠ Y + (X + Z)
P.S. I didn't check the math but that's the basic argument. I could be off by one or two orders of magnitude, but the point stands that floats behave wackily if you care about correctness.
I'm confused at why you'd expect fixed point to avoid these problems. Consider
auto pi = fixed_point<int16_t, -7>(3.141592654);
auto e = fixed_point<int16_t, -7>(2.718281828);
auto log2_10 = fixed_point<int16_t, -7>(3.321928095);
std::cout << (pi * e) * log2_10 << std::endl;
std::cout << pi * (e * log2_10) << std::endl;
These give 28.2422 and 28.2656 with the provided code, respectively.
For float16s, these give 28.375 and 28.359 respectively.
The correct answer is 28.368, so floats are much closer as well as being closer to each other.
---
In fact, your example doesn't justify this calculation. If one is sending the accumulated values to C, one isn't worried about calculation error. You just need to require all parties that do calculate it to do so in agreement.
There are several more targeted problems of floating point
* C++ makes few guarantees about what floating point calculations do, and they can vary even between optimization levels. Languages like Python and Javascript fix this by setting well-defined behaviour.
* Often one only needs a certain level of detail, so adaptive computations are just a waste. If you know the bounds of your map and the maximum zoom, a fixed precision gives more uniform calculations and often better precision.
* Fixed precision has obvious and rounding-free addition.
IEEE floating point with a specified rounding mode should be deterministic. Unfortunately the C and C++ standards allow calculations to have excess precision, removing this determinism. Other languages, notably JavaScript, do guarantee this determinism in the spec.
The idea that floating point isn't deterministic is patently false. If it wasn't, that'd mean that every computer adds random noise to the calculation. That's nonsense. This myth seems to be propagated because fp is hard to work with and has a lot of quirks: its non uniform division of space, the x87 extended precision mode, the various rounding modes... But none of that stuff is intractable.
A two-byte fixed-point number is likely to be less expensive to deal with than a two-byte floating-point number. (Promotion and demotion cost is pretty high for small floating-point types (bit masking, shifting, oring, etc.) compared to fixed-point promotion and demotion (shift).)
Similar to the PathEngine concept, when I compress 3D meshes to 6 bytes per xyz, I could use float16. But, there's no point to having most of the precision focused in the center of the mesh. The verts are usually fairly evenly distributed if not biased towards the outside edge of the bounding box.
Bit-level, cross-platform floating point determinism is harder than it should be. That and associativity is important in physics, financials, replays and distributed simulation.
The PlayStation1 and GameBoyAdvance didn't have FPU coprocessors. Software floating point was completely impractical. So, you pretty much had to use fixed point. To the point that the PS1 did have a fixed-point vector math coprocessor! :D
Yes, it limited the participation to one time. We don't show "locked" images, after doing unlocking. Most visitors are expected to be one-time visitors, finding the recipe via Google Search. Even if they re-visit, IMHO, it is measured risk to take in order to get actionable data for taking further decisions on shaping this feature.
As someone that uses Microsoft's STL, I just wanted to let you know I appreciate your work. Stepping through the STL (whether on purpose or via accidental F11 instead of F10) has made me a better programmer. I mean it sincerely!
