HN user
I agree. It seems like this bug arises because one Future is awaited while another is ignored. I have seen this sort of bug a lot.
So maybe all that is needed is a lint that warns if you keep a Future (or a reference to one) across an await point? The Future you are awaiting wouldn't count of course. Is there some case where this doesn't work?
Full paper here: https://www.science.org/doi/10.1126/science.ade9097
Not sure if this is what you mean but IIRC you can give the current selection a name by just typing it into the box in the top-left (the one that shows what is currently selected).
fifteensquared.net is great for explained answers, see eg http://www.fifteensquared.net/2018/03/09/independent-9798-ph... for the WINDMILL explanation.
While I do not believe Broadcom has released any documentation on the 3D hardware in the Raspberry Pi 4, you can figure out a fair amount by looking at the Mesa driver. In particular see the shader processor instruction packing code (https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/...).
For vertex arrays, while in theory the driver could load vec2/vec4 F16 attributes into the vertex shader as-is, AFAICT the Mesa driver does not attempt to do this; they get converted to F32 as they are loaded from main memory. There would be downsides to getting rid of this conversion... in particular the hardware does not support F32->F16 conversions when loading attributes, so the driver would have to recompile the shader if you switched the vertex arrays to F32 (or perhaps more likely recompile the shader when it realises you are using F16 vertex arrays rather than F32).
In any case, the hardware does support zero overhead F16->F32 conversions when loading attributes, so you should not see a performance drop when switching vertex arrays to F16! The performance should go up slightly as less data needs to be loaded from main memory. If you're seeing an 80% performance drop something has gone terribly wrong!
The Raspberry Pi 4 3D hardware has pretty extensive support for 16-bit floats. eg All 32-bit FP ops support "free" conversion from/to 16-bit float on input/output, and there are a few 16-bit float ops (eg multiply) which work on 16-bit vec2s (effectively giving double the throughput if they can be used). I don't know how well the Mesa driver supports any of that stuff though. Do you know if there was something specific that was slow?
Same issue on both Firefox (57.0.2) and Chrome (62.0.3202.94) on Windows 10 (build 16299.64). At least for me forward doesn't seem to be completely ignored; while holding it down it will occasionally spurt forward a bit.
So I've thought about this a bit.
Assume there are a fixed number of transactions per block (N), but a greater number of potential transactions that people would like to do. Also assume that there is a maximum percentage (of transaction amount) that people will be willing to pay as a fee (F).
Then I think the transaction fee should tend to F * average amount of Nth largest potential transaction in a block window.
The cost of mining a block ought to tend to just less than the average block payout (reward + fees). When the reward disappears, this will happen as miners shut down due to not being able to make a profit and the mining difficulty decreases.
Only the most efficient miners will survive. I think this means a few big miners, rather than many small miners, as big miners are almost certainly more efficient.
They are what prevented it being a required part of ES3 I believe. See the "IP Status" section here https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_c...
Individual vendors can of course expose that extension, provided they have a license.
Edit: it looks like ES3.2 requires support for floating-point framebuffers, so presumably the patent issue has been resolved somehow.
ES3 requires floating-point texture support, so any mobile GPU which supports that will support floating-point textures. The extension may not be exposed in ES2 of course.
Note that:
- 32-bit float texture filtering is not required to be supported, as it may cost significant area.
- Floating-point framebuffer support is not required, due to patent issues... :S
I got it from https://bitcoinfees.21.com "The fastest and cheapest transaction fee is currently 330 satoshis/byte, shown in green at the top. For the median transaction size of 226 bytes, this results in a fee of 74,580 satoshis." 74,580 satoshis is currently ~$1.50.
As you and b1daly point out the majority of the cost of running Bitcoin is currently paid for by mining rewards, but even so the fees are still crazy!
I don't know what will happen when the mining reward disappears. There will surely be far fewer miners, which will decrease the real-world cost of mining a block (and also decrease the security of the system!)
If proof-of-stake or something like it is ever adopted then presumably the cost of running the system will plummet but I'm not familiar enough with that stuff to say much more.
Cryptocurrencies like Bitcoin are already trustless – any machine can accept it from any other, securely. They are (nearly) free.
I believe it currently costs ~$1.50 in fees for a single Bitcoin transaction, assuming you want it confirmed reasonably quickly. Not what I would call nearly free!