You'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.

There's 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...

Azul had/has some interesting technology. (They're still around but just do software now.) I had some conversations on this topic broadly at a conference I was speaking at a month or so ago which had more hardware/software overlap than is typical. IMO, we're unlikely to come up with anything else in the near-term that delivered the kind of scaling CMOS process technology did. As a result, it's at least possible that we'll see specialized hardware make more sense in a world where "Moore's Law" won't let general purpose x86 chips just hit the same performance level in a couple of years.

Well, 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.

> 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.

Yes, 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.

> 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

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

You just replace the "C" transistors with "Javascript" transistors

Most 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.

And they're mostly right -- there is great value in having one language be used by a large part of the industry.