On 29/11/2017 08:40 PM, Timothy Sipples wrote:
Anyway, I get your point, that the P word might have caused some anxiety in
the past. It the past (and to some diminishing extent now) it meant
throwing more CPU at a problem to solve it. When one is focused on resource
efficiency and scalability then throwing any resources at a problem is not
ideal. But I wouldn't over-interpret that word, especially nowadays. Thank
goodness work can be parallelized.
I was referring specifically to the example of Spark doing SMF
reporting. Yes, parallel processing in the general case is very useful
to reduce wall clock time. However, it generally requires more CPU for
synchronization etc. Using additional CPU on z/OS to cut the elapsed
time of something like SMF reporting is probably not the best way to go.
Reducing overall CPU usage is more desirable.
On the other hand, for CPU bound SMF reports on a PC, parallel
processing would be the first choice because you probably have multiple
cores sitting idle.
That's how I work with my products. If it's on the PC, I try my best to
parallelize to minimize user wait. If it's on z/OS, I try to cut overall
CPU usage and parallel processing is not a priority.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
