On 29/03/17 22:30, fredvs wrote:
@Karoly Balogh (Charlie/SGR) Perfect, I have now all the arguments to defend the "Dinosaur Threading"choice. Thanks.
I'd second Charlie's point, and add that a very small change to a system's layout, e.g. a DIMM on a NUMA node going dodgy and being excluded at boot, can have a drastic effect if process or interrupt affinity has been locked down inadvisedly.
Another thing to take into account is that when many people mention parallelisation they're thinking of something like OpenMP, which in practice is built on top of threads and processes and obviously introduces substantial overhead. It's good for large jobs carefully designed, particularly on very large datasets.
Some languages were designed with at least some measure of parallelisation in mind. I'd highlight in particular APL, which tried to minimise control flow variation so that in principle at least a function could be applied to all elements of an array simultaneously. Granted that in those days CPUs were a scarce resource, but even then there were understood to be hazards which could break the programming model.
Ryan mentions OpenCL etc., which is about as close as we've got to "a vector processor on every desktop".
Finally, I suggest that you look at least briefly at https://en.wikipedia.org/wiki/Vector_Pascal which appears to have some quite good stuff in it.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
