On 1/20/17, 4:20 PM, "Beowulf on behalf of Alan Louis Scheinine" <beowulf-boun...@beowulf.org on behalf of alschein...@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) > _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
