3 ms·

Well if you read the article to the end (which, granted, is not an easy task) the author finally after a lot meandering reaches the conclusion that you may solv

by hristov 13y ago

Well if you read the article to the end (which, granted, is not an easy task) the author finally after a lot meandering reaches the conclusion that you may solve the problem of dark silicon by stopping the increase in clock-speeds while using the increase in transistors to build multiple cores. He then says that this will not result in proportionally higher performance because our software does not run well on multiple cores. This is where Haskell comes in. Haskell allows you to program in a way that makes parallelization relatively easy.

sedev 13y ago
Well for that matter so does Clojure, and both have had a while to pick up traction. Do you think it'll be easier to solve the primarily-social problem of getting traction for languages like that (and I say this as someone who adores Clojure and has some affection for Haskell) or to solve the primarily-technical problem of figuring out chip technologies where one can metaphorically jack up current software and slide the new chip technology in underneath?
011011100 13y ago
+95% of the article is about physical/hardware constraints: energy efficiency, architectural efficiency, etc. Haskell isn't going to solve these problems. Let me quote you: "I have the solution!" It seems like you want to advertise a tool, instead of actually considering the issues.
koobz 13y ago
He's not saying software doesn't run well on multiple cores and we need to learn how to program applications that can utilize multiple cores efficiently. That's a software problem. This is a hardware problem. His argument is that scaling silicon to multiple cores is facing physical barriers. You're no longer getting more cycles, improved transistor density, and decreased power consumption simultaneously. Exponential scaling of cores will not result in exponential scaling of computational throughput because we're facing energy-related tradeoffs.
njharman 13y ago
Thing the answer ids Erlang, which makes parallelization easy. No relative qualification required.

by hristov 13y ago

sedev 13y ago

Well for that matter so does Clojure, and both have had a while to pick up traction. Do you think it'll be easier to solve the primarily-social problem of getting traction for languages like that (and I say this as someone who adores Clojure and has some affection for Haskell) or to solve the primarily-technical problem of figuring out chip technologies where one can metaphorically jack up current software and slide the new chip technology in underneath?

011011100 13y ago

+95% of the article is about physical/hardware constraints: energy efficiency, architectural efficiency, etc. Haskell isn't going to solve these problems. Let me quote you: "I have the solution!" It seems like you want to advertise a tool, instead of actually considering the issues.

koobz 13y ago

He's not saying software doesn't run well on multiple cores and we need to learn how to program applications that can utilize multiple cores efficiently. That's a software problem. This is a hardware problem. His argument is that scaling silicon to multiple cores is facing physical barriers. You're no longer getting more cycles, improved transistor density, and decreased power consumption simultaneously. Exponential scaling of cores will not result in exponential scaling of computational throughput because we're facing energy-related tradeoffs.

njharman 13y ago

Thing the answer ids Erlang, which makes parallelization easy. No relative qualification required.