4 ms·

This is the reason why I'm considering only enabling that feature on Chrome (because of WASM and battery API) and Desktop PC (because of the battery/heat issues

This is the reason why I'm considering only enabling that feature on Chrome (because of WASM and battery API) and Desktop PC (because of the battery/heat issues). For experiment, I've turned on a miner in one tab of my brother's 7-year old modest PC setup. He went for several hours without noticing it, while doing blender rendering as well as somewhat intensive photoshoping.

user5994461 9y ago
Just because the user doesn't notice or doesn't understand what happens doesn't make it acceptable. Chrome is going toward more and more aggressive CPU throttling of tabs in the background. If mining becomes a thing, we're going to a world where background tabs will stop being rendered at all.
- synthmeat 9y ago
  > Just because the user doesn't notice or doesn't understand what happens doesn't make it acceptable. I did this on my brother, for data gathering. It'd most certainly not be implemented non-transparently in the end-product. > Chrome is going toward more and more aggressive CPU throttling of tabs in the background. That's why you mine during active game. The more people love it, the more they mine it. It can certainly be made mostly win-win scenario, which is why I aim on, again, transparently experimenting with it.
  - klipt 9y ago
    Is mining in a browser remotely cost efficient? Doesn't it end up costing the user more in electricity than just buying the coins directly?
    - synthmeat 9y ago
      There are many tradeoffs one makes taking any route. Electricity-wise? I'm not sure. We'll see. > ...just buying the coins directly? Realistically, there's never such a thing such as "just buying coins". You need payment processor / security / refunds / authorization / ... There is, however, something close to "just mining coins". This is one of the fundamental reasons cryptocurrency is attractive in the first place.
bartread 9y ago
Is this not already in the BTC situation, where you burn more in cost of electricity than you gain from mining? Granted, in this case it would be somebody else's electricity, but that feels a bit ethically grey, as well as perhaps environmentally irresponsible. Don't get me wrong, I've considered similar things, but I'm pretty uncomfortable with the idea for the above reasons. Plus, whatever people might tell you, even the absolute best JavaScript engine is slow by comparison with other languages. Example: in the last few weeks due to #reasons I've ported a measure calculation engine for market research data from JavaScript to C#. At first, in many ways, it was a like for like conversion, in that I preserved the data model and general mechanism and flow of calculations, albeit that I applied a much stronger separation of concerns. Nevertheless, with no optimisation, it was roughly 2x the performance of the JS version (V8, of course) running on the same machine. I then started to take advantage of .NET's strong typing for numbers and strings, switched out dictionaries for strongly typed arrays using (obviously) integer lookup, rather than using integers as keys in dictionaries. I also fixed a couple of issues where I was inadvertently using exceptions for flow control, and recalculating strings to generate hashcodes (doh!). What's surprising is that those changes get me to about 15x faster, and that's really just taking advantage of strong typing and more appropriate data structures that are available in .NET. (JS has arrays, and engines like V8 do optimise for them, even though they're strictly just objects with special properties. Whereas in C, C++, C# arrays are the absolute fastest data structure to access, bar none.) Also worth pointing out that judicious switching from dictionaries to arrays absolutely slashed memory use. I also implemented the kicker - which happens to be language agnostic - which was to change the moving average calculations to preserve and reuse intermediate results. This got me a 10x performance gain on top of the rest, taking me to about 150x. Like I say, that would probably have been the case in JS as well, so it's not really a fair comparison. Nevertheless, bear in mind that whilst JavaScript is certainly a lot faster than it used to be, it is not fast, even by the standards of other managed runtime languages. And it's absolutely not fast by the standards of well-written C++ or C compiled down to native code. I'm not sure how much benefit you'd get from a WebAssembly approach, although possibly something worth looking at.
- synthmeat 9y ago
  Go check it out with this miner implementation I intend using and customizing. [1] [1] https://coin-hive.com https://coin-hive.com

user5994461 9y ago

Just because the user doesn't notice or doesn't understand what happens doesn't make it acceptable. Chrome is going toward more and more aggressive CPU throttling of tabs in the background. If mining becomes a thing, we're going to a world where background tabs will stop being rendered at all.

synthmeat 9y ago
> Just because the user doesn't notice or doesn't understand what happens doesn't make it acceptable. I did this on my brother, for data gathering. It'd most certainly not be implemented non-transparently in the end-product. > Chrome is going toward more and more aggressive CPU throttling of tabs in the background. That's why you mine during active game. The more people love it, the more they mine it. It can certainly be made mostly win-win scenario, which is why I aim on, again, transparently experimenting with it.
- klipt 9y ago
  Is mining in a browser remotely cost efficient? Doesn't it end up costing the user more in electricity than just buying the coins directly?
  - synthmeat 9y ago
    There are many tradeoffs one makes taking any route. Electricity-wise? I'm not sure. We'll see. > ...just buying the coins directly? Realistically, there's never such a thing such as "just buying coins". You need payment processor / security / refunds / authorization / ... There is, however, something close to "just mining coins". This is one of the fundamental reasons cryptocurrency is attractive in the first place.

bartread 9y ago

Is this not already in the BTC situation, where you burn more in cost of electricity than you gain from mining? Granted, in this case it would be somebody else's electricity, but that feels a bit ethically grey, as well as perhaps environmentally irresponsible. Don't get me wrong, I've considered similar things, but I'm pretty uncomfortable with the idea for the above reasons. Plus, whatever people might tell you, even the absolute best JavaScript engine is slow by comparison with other languages. Example: in the last few weeks due to #reasons I've ported a measure calculation engine for market research data from JavaScript to C#. At first, in many ways, it was a like for like conversion, in that I preserved the data model and general mechanism and flow of calculations, albeit that I applied a much stronger separation of concerns. Nevertheless, with no optimisation, it was roughly 2x the performance of the JS version (V8, of course) running on the same machine. I then started to take advantage of .NET's strong typing for numbers and strings, switched out dictionaries for strongly typed arrays using (obviously) integer lookup, rather than using integers as keys in dictionaries. I also fixed a couple of issues where I was inadvertently using exceptions for flow control, and recalculating strings to generate hashcodes (doh!). What's surprising is that those changes get me to about 15x faster, and that's really just taking advantage of strong typing and more appropriate data structures that are available in .NET. (JS has arrays, and engines like V8 do optimise for them, even though they're strictly just objects with special properties. Whereas in C, C++, C# arrays are the absolute fastest data structure to access, bar none.) Also worth pointing out that judicious switching from dictionaries to arrays absolutely slashed memory use. I also implemented the kicker - which happens to be language agnostic - which was to change the moving average calculations to preserve and reuse intermediate results. This got me a 10x performance gain on top of the rest, taking me to about 150x. Like I say, that would probably have been the case in JS as well, so it's not really a fair comparison. Nevertheless, bear in mind that whilst JavaScript is certainly a lot faster than it used to be, it is not fast, even by the standards of other managed runtime languages. And it's absolutely not fast by the standards of well-written C++ or C compiled down to native code. I'm not sure how much benefit you'd get from a WebAssembly approach, although possibly something worth looking at.

synthmeat 9y ago
Go check it out with this miner implementation I intend using and customizing. [1] [1] https://coin-hive.com https://coin-hive.com