Concurrent programming in a black box

    About two months ago, the first experimental Russian-language online seminar from Intel " Intel Parallel Studio workflow " was held. At this seminar, an attempt was made to show that there are such magical tools that will help to implement parallelization and optimization of C ++ code, even if you do not have a complete understanding of the principles of the program. I know that this approach is often criticized. And another reminder that the actions shown on the webinar are incorrect, pushed me to this post.



    Similar disagreements existed once between supporters and opponents of using debugging tools (“debuggers”). Opponents claimed that debuggers are the result of an incorrect methodology, and users of debuggers are simply illiterate. Their main argument was that the use of debugging tools encourages code writing by trial and error, without trying to think through the algorithm and rewrite it, break it into small functions, and make it more concise and simple so that there is no room for errors. Since there are few opponents of debugging tools, many may not even have heard of such disputes. Well, now we are witnessing the beginning of a new round.

    Currently, two approaches to the problem of parallelizing programs have been formed and are being discussed. Supporters of the first want to get some means that will allow them to parallelize the program with minimal rework. These are practitioners who want to adapt their solutions to the capabilities of multi-core systems that appear on the tables of ordinary users. The second ones like to talk about various theories of parallelization, about parallel programming languages ​​and the fact that you need to clearly understand how parallel code will work. Indeed, in their opinion, otherwise it is impossible to achieve its correctness and effectiveness.



    I agree with the second group, which calls for conscious action, whether it's debugging or experimenting using OpenMP directives. This approach is provoked by the creation of less reliable programs, because not a correct code is recognized as a workable code, but a code that works correctly on a number of tests. This is definitely a bad thing. But with my soul I fully support the first group.

    I am a practitioner. And I think that a long time ago no one knows how real programs work. And it makes no sense to say whether the debugged or parallelized program is clear to the developer or not. It is always incomprehensible if we are talking about industrial software development. Opponents of the "black box theory" (the first group) are mainly representatives of the academic community, teachers or people involved in solving narrow problems, where the extreme efficiency of parallelism is important. For example, numerical programming. Usually they deal with prototypes of programs that calculate something, in which they are well versed and know which parallelization algorithms should be used in each particular case. The programs are small, they can be read, or even rewritten if necessary, in another language. The error is

    An analogy with the second group (theorists, or opponents of the black box). A man with a flashlight and a magnifying glass, who is studying with interest a beautiful chest covered with paintings and offers ways to make it even more beautiful and convenient to use.

    A real programmer involved in the development of a large project that has been developed for years or even decades is in completely different conditions. Most likely, he came to the project when megabytes of code were already written and he did not know the whole history of various architectural solutions. Perhaps he does not even have anyone to ask. He did not have time to read the source code, and he would never have that much time. He works in a certain area of ​​work and may not imagine how many algorithms written long before he joined the development team work, but which he is forced to use.

    An analogy with the first group (practitioners, or black box advocates). A man with a flashlight and a magnifying glass in a huge maze. He can carefully study the frescoes on the walls, but the beam of a lantern cannot highlight opposite walls and allows you to see the corridors of the maze only in fragments, without creating a holistic picture.

    I do not consider the approach to parallel programming, as a black box experiment, a good methodology. But it is better than not doing anything or offering, to fully understand the structure of the existing software package and algorithms. This, unfortunately, just does not work. The complexity of many software solutions has outgrown the possibilities of consciousness of individuals and even teams that work with them. Using specialized tools that somehow solve the problem of parallelization and debugging is the only option available. The experience of developing an extremely effective, but small, parallel program is not applicable here.

    The profiler will not offer a high-level way to change the algorithm. But it will show how you can at least partially speed up the program by parallelizing the most critical sections of code. A parallel debugger or code analyzer will not prove the correctness of a parallel program. But they will allow you to hedge a programmer who forgot to shine a flashlight in one of the directions and thereby missed an important element from his gaze.

    I support the use of tools that allow and help parallelize not only well-understood code, but also black boxes, as practically the only way to work with large software systems.

    Also popular now: