@steipete puts it pretty well: JavaScript really made it. We now tweak CPUs to make it faster.
http://benediktmeurer.de/2016/12/16/the-truth-about-traditio...
This is when Chrome on Android finally started to turn a corner, they've done a fantastic job. JS perf has increased 50% from 2016 to 2018 in Chrome/Android. Sadly Android is still hamstrung by extremely mediocre Qualcomm SoCs but they've made huge strides on the software side.
I worked very hard on pulling the same trick at Sony. We'd made Vegas scriptable, and, once it was part of Bapco's Sysmark, we received immense support from chip vendors. Machines, engineers, tools, instructions added to instruction sets... It was a nutty time.
Of course, the biggest wins worked everywhere, like the 6755399441055744 single precision rounding trick, or the use of memory mapped file regions to cache the rendering tree. Still, becoming part of a performance benchmark is a great way to get attention.
Not talking about Go language.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
EDIT: before people accuse me of making a false dichotomy: I acknowledge that there are other uses for computers, but am unable to think of any others where the increased resource consumption would be worth it. Another thing: cell phones, the battery would drain much more quickly if everything were a webapp. Perhaps video game consoles will switch to such a JIT, though...
“There are no financial instruments that will protect you from a world where we no longer trust each other.” https://www.mrmoneymustache.com/2018/01/02/why-bitcoin-is-st...
first two aren't even about cryptocurrencies - every currency is more attractive than bolivar in Venezuela these days. i guess all those people are doing something illegal (surviving?) or will be better off with electricity (spoiler alert - they already have electricity).
the last one is even dumber and coming from supposedly somebody who should know their way around finances and yet quotes like the one you posted or this one:
> These are preposterous numbers. The imaginary value of these valueless bits of computer data represents enough money to change the course of the entire human race, for example eliminating all poverty or replacing the entire world’s 800 gigawatts of coal power plants with solar generation. Why? WHY???
just show how clueless he is.
there is a gigantic difference between not trusting and not having to trust.
and of course market cap numbers are preposterous. it's because they are meaningless and don't represent anything that exists in reality. not the amount of money that was spent acquiring those currencies, not the amount of money that can be made selling those currencies. it's meaningless numbers.
This is the point, though. Everyone expecting financial security has to trust. There is no alternative.
so you're right, i have to trust math and i am ok with that.
You're worried about the wrong player in this game.
cryptocurrencies is simply different financial system where you don't need to trust middlemen.
it's really astonishing how complacent people have become towards trusting middlemen in financial systems. if you ignore the banking services that you're paying for either directly or indirectly via taxes - what is the bank doing for you? why should you pay for having a record in the database? why should bank be involved in facilitating or even censoring your transactions?
i'm worried about exactly the right player in this game.
Seems like the author I cited has it exactly right, then.
is this the way you concede your opinion expressed above was wrong? because you just jumped from "financial system is not a risk, counterparty is a risk" to "but what about transparency and law enforcement"..
Financial security depends on the ability to show who bad actors are and undo their transactions. I don't see how this is possible without some sort of middleman involving civil government. Yes, the current banking system has flaws, but they are not technological flaws and cannot be solved by technological means.
yes, in context of resolving dispute with counterparty
> Financial security depends on the ability to show who bad actors are and undo their transactions
no, that's in my opinion the opposite of financial security. i feel financially secure when i know no government, bank or corporation fuck up can affect the state of my account.
> Yes, the current banking system has flaws, but they are not technological flaws and cannot be solved by technological means.
the flaw of current banking system is humans. humans are often corrupt, incompetent, unreliable and with malicious intent.
basing financial security on assumption that only honest, competent, reliable and well intentioned humans end up in positions of power is obviously wrong.
i don't hold that assumption and think that taking humans out of the loop is the best way to address flaws of existing system.
the fact that flaws are not technological in no way means technology can't solve them.
Software, including a blockchain or Bitcoin, is designed by humans.
Not exactly Javascript but running untrusted code in a safe language in the kernel can give already performance improvements for some workloads due to avoiding system call overhead. It will be interesting to see where this goes in the future.
Not to mention that that benchmark is very synthetic and doesn't really reflect the kinds of speedups that will generally be found.
https://en.wikipedia.org/wiki/Jazelle
I would not be surprised if they come up with a way of directly executing WASM or such. (And then the possibilities for security exploits become a lot more interesting...)
I’m also not sure if that’s a “win” in general. Dynamic languages used doubles since forever now and to me, either A) cpu makers sleep for too long, B) js is such a historical mess that fixing it in hw is reasonable now.
It is interesting how e.g. LuaJIT may benefit from that, but unfortunately it is [formally] unavailable on appstore because of licensing restrictions. As are non-apple fast js engines.
As for other languages that use Doubles, this instruction isn't for general-purpose Doubles. CPUs already handle those. This instruction specifically implements the exact semantics that JavaScript wants. Now, maybe some other dynamic languages would want the same semantics when converting Doubles to ints, I don't know. But it's by no means a given that they would. Also, most languages don't use Doubles for all numeric types anyway.