[mdlug] Parallella: A Supercomputer For Everyone by Adapteva — Kickstarter

[Aaron Kulkis]

Michael Mol wrote:
> On Thu, Oct 11, 2012 at 4:02 PM, Aaron Kulkis <akulkis00 at gmail.com> wrote:
>> Garry Stahl wrote:
>>>
>>> On 10/10/2012 05:31 PM, Aaron Kulkis wrote:
>>>>
>>>> Very true.  Most GUI stuff is a complete waste of storage space,
>>>> in-core memory, cache space, and clock cycles.
>>>
>>> Except the Amiga is a GUI system.  An elegantly programed efficient,
>>> multi-processor GUI system.
>>
>> Exactly.  There wasn't room for bloat.
>>
>> I'm constantly frustrated that although CPUs have sped up by
>> a factor of 3000 since when I learned to program in high school,
>> apps aren't running any faster.
>>
>> The Amiga code was written to run on hardware that ran at
>> only 1% of the speed of current off-the-shelf hardware.
>
> Understand that the CPU capacity is being spent to improve development
> speed, rather than end-user functionality speed. Trying to run a
> programming language like current Ruby or current Python on an Amiga
> would be...terrible. Either the 'trying' part (presuming you could fit
> the port into the target environment) or the 'running' part (the speed
> won't be there).
>
> Instead, software development costs have shrank dramatically with the
> availability of powerful tools for rapid problem solving.
>
> Yes, a programmer with the mindset of a 1980s assembly coder could
> achieve absolutely amazing performance on a modern system, but the
> code will have much higher porting and maintenance costs; x86 CPUs
> have grown as fast as they are not just because they clock faster, but
> because they've gone superscalar, highly parallel and have added tons
> of new low-level features (register renaming, additional
> general-purpose registers, additional registers of entirely new
> classes...).
>
> If you're paying attention to the things necessary to squeeze every
> last {int|fl}op of performance from a given modern CPU, you'll find
> that you need to keep several different variants of your code handy to
> account for difference in execution speed or stall behavior for
> individual instructions across different brands of CPUs--even
> different models within the same brand!
>
> Whether compilers are better than humans at this kind of work depends
> on how much time you're willing to spend, both as a human doing
> assembly tuning, and as a human waiting on a compiler to try
> absolutely every permutation of often-incompatible optimization
> paths...and this depends on the tool being a compiled language, where
> you have a better (not perfect; see callbacks) chance of knowing how
> pieces of code are going to need to fit together at run-time. If
> you're working in a dynamic language that compiles to opcodes which
> run in their own vm (such as Python, Perl, Ruby...), huge classes of
> optimizations have to be thrown out because the compiler can't know a
> particular path won't be taken.
>
> All that 'bloat' is really a set of tools designed to allow
> programmers to get useful products to end-users in a timely fashion.
> Without it, the computing world would look much as it did in the early
> 1980s; development would be limited to hobbyists and dev shops running
> their own code on timeshare systems with services rented out to
> customers.
>
> The modern picture is much, much nicer and cheaper.
>

  I think the bigger problem is far too many programmers who
have never endured a data-structures and algorithms course,
and so instead of using proper data structures, like, say, a
B-tree, store large amounts of data, instead go for a simple
linear array, because that's all they're comfortable with.

It's not always the case, but far too often.