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?
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).
The reason I ask is that only British people seem to add "lovely" in their sentences.
Also, I now learnt that the WINDMILL answer refers to something in London. I don't know how outsiders — say a random person from Argentina — is supposed to know that.
Yeah sometimes they test vocabulary, sometimes they test general knowledge (or at least your ability to google or have an anagram solver). So you do learn while solving, which is a plus.
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?
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!
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.
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
Not to turn this into a debate on patents, but even the patent itself seems to admit it's an obvious and anticipated improvement made possible by cheaper silicon:
> In an effort to gain the advantages conferred by operating on a floating point basis, some prior art systems have attempted to perform floating point through software emulation
> But as advances in semiconductor and computer technology enable greater processing power and faster speeds; as prices drop;...it has been _discovered_ by the present inventors that it is now practical to implement some portions or even the entire rasterization process by hardware in a floating point format. [emphasis added]
> Hence, due to the improvements in processor speed and other improvements that make it practical to operate on large amounts of data, it is now possible and cost beneficial to utilize the valuable information that can be provided by the frame buffer.
It's a good idea, but obvious - everyone was waiting for this inevitable improvement. Their idea of floating-point-all-the-things is also good, but just a matter of engineering. They don't disclose their exact engineering, anyway; but just patent the general idea.
> Thus, there is a need for a graphical display system which predominately uses floating point throughout the entire geometry, rasterization, and frame buffering processes. The present invention provides one such display system.
I'm surprised it was granted, and I don't think it would upheld in court - but it doesn't need to, it's just another plank in the patent portfolio.
Thank you. It seems I didn't stumble upon the issue because in WebGL I didn't even have to enable the extension to have float color framebuffers in most platforms. Instead I tried to create a framebuffer to check if it's supported.
> 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!
Yes, but that's not an inherent problem with the technology. It's the result of a hardcoded throughput limit which, so far, they haven't been able to remove for political reasons.
Just removing that limit wouldn't let Bitcoin grow much further anyway, but there are all sorts of technologies in development that could take cryptocurrencies to massive scale, including the Lightning network, Ethereum's sharded proof-of-stake, DFinity's threshold signatures, Mimblewimble, and others.
According to this thread [0] the recommended fee is 0.0001 BTC that'd be $0.20. Of course if you have a non standard transaction the recommended fee will vary.
> assuming you want it confirmed reasonably quickly
Generally it takes 10 minutes to mine a block so even with a very high fee you won't have it accepted in seconds (except for a pure luck situation where you send a transaction, miner takes it and immediately finds a block).
Personally I wouldn't think fees are a big deal now that miners rely mainly on coinbase transactions (getting BTC just for mining a block). Fees will play a big role when miners stop creating BTC out of thin air and will have to survive on fees only.
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.
> 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!)
Maybe it'll end up with bigger amount of smaller miners. Now the cost of entering mining is high but when the incentives will be smaller Bitcoin mining may end up where it begun - on small hardware. If fees sky rocket nobody would be using it. One way or another that'll be interesting times...
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.
If this continues as it is now, once mining blocks no longer creates new bitcoins, we'll surely be looking at fees of $100+ for confirmation within 24 hours.
This may be a misconception - a decrease in the rewards paid to miners wouldn't obviously be "made up for" by an increase in transaction fees. The fee is basically a bid to be included in the next 1MB block, so it should be a pure product of transaction volume (and, of course, the BTC/USD exchange rate by extension). However, I agree that both the transaction volume and the exchange rate are likely to continue increasing.
But, if I'm missing something, it would be interesting to know!
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?