3 ms·
This is our inability to use multi-core. From the performance graph (http://regmedia.co.uk/2011/10/20/arm_performance.jpg http://regmedia.co.uk/2011/10/20/arm_
by 6ren 15y ago
This is our inability to use multi-core.
From the performance graph (http://regmedia.co.uk/2011/10/20/arm_performance.jpg http://regmedia.co.uk/2011/10/20/arm_performance.jpg), two A7s would have the same raw processing power as one A15 - at less than half the power. The problem is we can't utilize that raw power effectively. So, instead, this awful, inelegant, stupid design is probably the absolute best we can do at the moment.
People claim that functional programming's immutability solves this problem. But it's interesting that while Erlang, one of the most effective multi-processor languages, is functional, it doesn't use that for multi-core: instead, it uses a shared-nothing architecture (like smalltalk) which is independent of the fp paradigm; and STM (Software Transactional Memory). The second interesting thing is that incredible rewards are available today for a solution (and have been for a while) - so where are the fp solutions? Why haven't they taken over, or had substantial success - or, at least, appeared?
Multi-core is a hard problem. Silicon is cheap but we don't know how to use it (excepting GPUs/CUDA). I think this will not be solved with any existing methods (including 50-year old fp). Instead, it will require a complete reframing of the question, from the silicon-up. That is, it won't even look like a programming language - or a computer.
It's hard to overstate the rewards for solving this.</provocativerant>
- flazzarino 15y agoThere exists a non-intuitive asymmetry in the nature of systems like multi-core. Do four 10mph car crashes do the same damage as one 40mph crash? If it can be properly coordinated. If you can coordinate it, how much does the coordination cost? At worst you only have the power of one 10mph crash, often at best too. Programming for multi-core can a hard problem but the problem doesn't always lie in our abilities, many times it's computationally impossible. To play games and video is a must right? We want the most from our battery right? A fact of the situation is that high power activities are many times mutually exclusive from low power activities right? So what is awful, inelegant or stupid about the design? The asymmetry? There is asymmetry of the interaction? Should you cary around a dumb-phone, a gameboy, and a video player? Maybe more elegant, but it sure is more awful. P.S. Don't talk about FP son ;)
- Someone 15y ago"Do four 10mph car crashes do the same damage as one 40mph crash? If it can be properly coordinated." I know this is totally unrelated, but it is worth correcting: potential energy is 1/2 m v^2, so that faster car has 16 times the potential energy as each of the slower cars. That is why braking distances do not go up linearly with car speed and why high speed accidentals are way more lethal than low speed ones. I guess there is an analogy here that one double-speed CPU beats two single-speed ones for most tasks, but I do not think it is very apt.
- grannyg00se 15y agoErlang wasn't purpose built for multi-core though. It just so happens that everything desired for ultra reliability and continuity ended up working well for multi-core applications. The share-nothing architecture is not "for multi-core" it is for stability and reliability. The multi-core fit is a great bonus that happens to now be very important. Ditto for functional programming's immutability.
- 6ren 15y agoTrue; I was commenting on what makes it good for multi-core. Share-nothing helps; immutability doesn't (because they don't share data, unless on the same core). Unless there's some other benefit to immutability for multi-core...?