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

[Michael Mol]

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.

-- 
:wq