4 ms·
based on historical evidence, a dedicated chip for executing javascript will be created before the industry makes a concerted effort to find a better tool.
by chillaxtian 11y ago
based on historical evidence, a dedicated chip for executing javascript will be created before the industry makes a concerted effort to find a better tool.
- wolfgke 11y ago> a dedicated chip for executing javascript will be created Unluckily this is not so easy: If you know a way, Yossi Kreinin would be really interested to know: > http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html And here is a list of ideas/problems that he identified within "the usual suspects": > http://yosefk.com/blog/high-level-cpu-follow-up.html http://yosefk.com/blog/high-level-cpu-follow-up.html
- hamiltonkibbe 11y agoYou just replace the "C" transistors with "Javascript" transistors
- deleted 11y ago[deleted]
- k__ 11y agoMost people are simply value oriented if it comes to programming languages. I worked in many companies that would consider stuff like Java too "enterprisey". In 2006 most employers said "There is an abundance of PHP coders, why should I switch to something more expensive?!" Now they say this about JavaScript. And devs think "Well, lets learn something to make money with. Since there are some much JavaScript jobs, lets learn it!" I did so myself and made good money.
- Scarblac 11y agoAnd they're mostly right -- there is great value in having one language be used by a large part of the industry.
- adwn 11y agoYou're probably joking, but the "we need CPUs that are optimized for our high-level languages"-argument has been raised again and again in all seriousness in the past, without anyone ever showing a convincing way to speed up Javascript, Python, etc. in hardware. Fact is, chasing pointers through small objects or looking up methods in hash tables is very cache-unfriendly, and memory latency is the bottleneck for many computational tasks today. Instead, we should work on improved languages that provide better compromises between performance and convenience. Rust, for example, is a good step in this direction.
- marcosdumay 11y agoWell, whatever language you want to run, processors that are good for cache unfriendly tasks would be huge for logical AI, data mining, some kinds of image processing, and possibly a lot of other tasks. As dies get bigger, there's no law of nature saying that CPU power must be concentrated far from memory.
- adwn 11y ago> As dies get bigger, there's no law of nature saying that CPU power must be concentrated far from memory. Actually, there is. The main reason why the L1 cache is so small, is that a larger cache would take more cycles to access. The L2 cache is allowed to have a higher latency, so the electrical signals have more time to propagate through a physically larger area. 3D stacked dies alleviate this problem, and the trend goes towards putting several dies side-by-side in a single package (a chip), enabling lower latencies, higher throughput, and less power consumption.
- marcosdumay 11y agoYes, if you concentrate all your CPU power on a single region, it'll be far from most of the memory. There's natural law that mandates the CPU power to be concentrated.
- simonster 11y agoThere's http://www.azulsystems.com/products/vega/processor http://www.azulsystems.com/products/vega/processor, which is a CPU with special GC instructions, created by the same company as one of the most sophisticated garbage collectors. Apparently they thought they could speed things up with specialized hardware. Not sure what the performance looks like in practice, but it is interesting that it exists...
- reubenmorais 11y agohttps://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle