26 karma · joined May 28, 2017
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?
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!
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.
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.
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
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.
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!