[Beowulf] Mobos for portable use

[Lux, Jim (337C)]

On 1/20/17, 4:20 PM, "Beowulf on behalf of Alan Louis Scheinine"
<beowulf-bounces at beowulf.org on behalf of alscheinine at tuffmail.us> wrote:

>Are we failing to train programmers with the skills for multithread?
>I'm not in academics so I have not seen first-hand.
>I'm been collecting material to prepare an Optimization User Guide
>for a new computer that will have many Knights Landing chips.
>What I've seen is that a lot has been written between 2015 and now,
>concering SIMD and OpenMP.
>It appears to me that there is plenty of didactit material if one
>were inclined to teach the subject.
>
>‹


The short answer to your first question is ³yes²

The vast majority of programmers do not come out of CS PhD schools - I¹d
venture that most of them don¹t even have a degree in CS, but, rather, in
something else. Most developers don¹t even worry about threading - they¹re
writing code to do database updates, process a bunch of data serially
(e.g. update billing statements nightly) and similar tasks.

Even if you¹re a ³scientific programmer², most likely, you¹re using Matlab
or standard libraries, and the parallelism, if any, is buried in the
libraries you call.

Most of the software development in my section at work is with embedded
processors using real time operating systems (RTEMS), and while there is
some threading, an amazing amount is done by ³one big loop triggered by a
periodic interrupt² style programming.  Everyone argues that ³oh that
context switch in a threaded environment is too slow².  There¹s also a
tendency of each developer to assume they ³own the machine² - just getting
them to periodically ³yield² their threads so the scheduler can run is
something that takes constant reminders.

Folks developing operating system kernels (a very small number of people)
pay attention to threading, because they have to implement the primitives
that allow it.  Folks developing device drivers pay some attention to
multi threading, but more in the context of interrupt service routines,
and properly handling what work gets done in the ISR (with interrupts
disabled) and what gets done at kernel level, and what is in user space.
They¹re not so much looking at ³multi-CPU threading²..
Folks developing filesystems and database engines pay attention to
threads, since most of the time, the physical medium is slow, so threads
handling a transaction block, and you need to maintain update atomicity,
even when  your thread blocks and some other thread runs.

Concurrency is hard and most applications don¹t need it, or can live with
it hidden.




James Lux, P.E.
Task Manager, DHFR Space Testbed
Jet Propulsion Laboratory
4800 Oak Grove Drive, MS 161-213
Pasadena CA 91109
+1(818)354-2075
+1(818)395-2714 (cell)
 







>