Last week Stefan and me took part as guests at the para//el conference in Heidelberg. The actual program was separated into 2 keynotes, one per day, and 36 talks, 18 per day, three at a time (in parallel). Right at the beginning it was said, that we were two out of 150 participants, which, I would say, leads to a nice atmosphere. It wasn't difficult to attend a discussion or meet other people during the pauses and I haven't further experienced, quite contrary to other conferences, any large queueing at launch. Why? Well, someone encountered that a table, if placed correctly, offers space for more than one line at the buffet, which is quite a good news! 🙂
We've both really enjoyed the days viewed from that angle, so lets talk about the conference and the talks itself. It becomes visible, that concurrency or parallism - a detail that people tend to interprete quite differently or have different opionions about the exact meaning - is not considered something that is only subject to languages like C/C++ or to specific topics of the IT like embedded programming or HPC, but rather something that can be discussed in a broader sense.
At synyx, we program most of the time in Java and talks had been scheduled very nicely without any or less overlap, which is true for other languages as well, but my point here is, that, concurrency on the JVM is getting more and more attention nowadays. When did you read the last time about the memory model of the JVM? But sometimes, it makes even more sense to listen to sessions, that do not cross your every-day-borders, just to see how problems get solved or pattern applied by different people or divisions. What's a cache-line, volatile, atomic? What are the implications to multi-core or multi-socket environments, and what if we put a JVM in between? A slight change to a system, for instance, a change to the compiler, JVM or even a different CPU model might have an impact, due some underlying rules and optimization strategies, including hard and software. Visibility constraints might be a good keyword here and it was quite interesting to hear about so many different aspects again. The speakers did a good job to paint the picture with smaller examples: a + b + c might not be c + b + a under certain circumstances. While this problem is not related to parallism at first, but rather to numerical precision errors, it might be more visible to those environments and reveals the great spectrum of possible talks everyone could attend.
So, when I go through all of the sessions in my mind again, there was one challenging question to me, quite a bit philosophic maybe, at least to me.
In a concurrent world, how much precision would you be willing to relinquish, for a correct view of the shared world?
I would like to keep this open for now, you may want to think about it on your own, but you may also want to anticipate the outer rim of the IT. I can really recommend the reading of java concurrency in practice from Goetz Brian et. al to everyone who couldn't join the para//el in 2016 and wants to know more about the concurrent world. Threads are not evil, if used with the right abstraction and pooling helps to minimize the initialization costs.
In general, there is only one thing that I've missed along the talks about performance, correctness and theory, which is test. I'd really like to gain more insights about how people verify concurrent code. How fine grained should we formulate tests? What can we say about tools, software, patterns or even a simple setup? Might be even more complex for the Embedded world.
Well, might be relevant for 2017, might not be relevant, we will see.
Thanks to everyone who made the conference to what we've seen in 2016!