Reader Feedback on Moore’s Law and the Performance Wall
October 12, 2009 Timothy Prickett Morgan
|
Last week, in talking about the future Power7-based servers from IBM, as I have been doing for the past several weeks, I brought up the idea that IT managers and programmers had better start thinking about how multicore and multithreaded chips with a lot more cores and a lot more threads might impact their applications. I received a thoughtful letter from a long-time i programmer, which gave me–and therefore you–some food for thought. Hey, TPM: The whole threads thing concerning RPG is bogus. Before one starts questioning RPG’s performance with multi-threading, one should ask what the need for multi-threading is. The serialization wait warning is true for any language, and in fact is the same performance issues described so well for the multi-threaded CPUs. If for some stupid reason one writes a multi-threaded program and has shared memory data, almost always a requirement for the threads to communicate with each other, and something shared is locked up waiting for something, similar to a record lock, then yes, performance suffers as both threads are waiting until shared memory is available. Very similar timing and such to CPU threads waiting for shared memory. Now why would we do that with RPG? Often another thread is created for monitoring for messages, be it from an interface, communications such as sockets, or whatever. But we don’t typically consider the socket or interface to be “waiting” unnecessarily and less efficient than before, etc. We in fact consider the overall end product to be more responsive in that input can be responded to while background processing is taking place, whereas previously input would only be responded to when background processing took a break to check. Now it would check a shared flag with interface thread but to interface there has already been a more immediate acknowledgement. The real issue here is Java and its multiple threads in a job calling an RPG procedure from multiple threads. The RPG procedures/programs that participate in threads need to be compiled as serialized (same as in any language) and of course could become a bottleneck. This is true of any shared resource in any language. Obviously the solution is architecting such that as much is duplicated as possible to minimize shared resources. So for example, a Java class is instantiated for each thread and duplicated within the job and is not a bottleneck. Yet if that class accesses a common resource, at some point you have to lock it with serialization and you can have threads waiting to access it. I haven’t tried any of this or dealt with these issues yet, but I’ve read the same warnings and considered it, and I consider that while issue regarding RPG specifically is technically accurate, but bogus. If the RPG code is doing anything halfway useful, then of course it should process round robin as called and ensure data integrity. It is also good sound architecture to serialize at such a solid modular entry as a subprocedure or program call. I would view as data queue processing with a dataq server. Same thing, same concept, same results. In fact, the threads could (and traditionally we would) write to a dataq server instead. However, serialization would likely be a few microseconds faster but as with any threading any shared resources including our RPG programs that can be called from multiple threads need to be compiled as serializable to have only one thread executing in it at a time. There was, of course, the whole thing about the RPG cycle code being non-reentrant so that by definition any RPG with a Main entry was a shared resource, and I understand that that has been improved in i 6.1 for improved participation of RPG in multi-threading but don’t recall the particulars on it. I think its enough that CPU threads can be granular at the job level for us to get full power from new architectures. I think it is totally bogus to suggest that RPG needs to be rearchitected for it. I also think it is totally bogus that Java would be considered better suited for it due to launching multiple threads. The bottom line is the actual work that needs to be performed, and if it was useful to launch multiple threads in a job, we would have figured out how to work around it a long time ago. –Ralph RELATED STORIES Moore’s Law and the Performance Wall IBM to Mothball a Whole Bunch of Stuff with Power7 Start Planning for Power7 Iron Now The Feeds and Guessed Speeds of Power7 Power 7: Lots of Cores, Lots of Threads IBM Launches Power6+ Servers–Again
|
