Registered: Mar, 2007
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
Posted: Mar 26, 2007 3:48 PM
> > You claimed that Java is no longer slow and then you
> > provided with contemporary examples of slow Java
> > applications which you then dismissed.
> I have no problems with any of these applications on my
> computer. What kind of computer with what kind of
> graphics card do you run your Java applications with?
> > So give us some examples of contemporary java apps that
> > perform as well or better than C++ apps.
> It's not just about performant apps. It's about
> programming productivity and application stability. I
> have very performant Java applications that bang away
> The applications that were pointed out, all have something
> in common. They are desktop/GUI apps. The Swing
> implementation, currently, utilizes basic drawing
> primatives to render all components. This means that its
> rendering is more like a 2D/3D game's requirements than a
> "windows desktop app". So, it's no wonder that people
> without powerful graphics cards have poor results with
> Swing based applications. Eclipse/SWT can do better than
> Swing because it uses native drawing. But, in JDK-6,
> support for VISTA and Sun's realization that their
> rendering pipeline was not correct/optimal for windows,
> means that things are going to change, and I believe, for
> the better.
> Unfortunately, the masses are still all keyed in on CPU
> performance and don't understand the time they are wasting
> on writing complex code, debugging memory issues, and
> porting their software to a new OS/CPU combination.
> The design of Java is what enables it to be portable. The
> JDK1.5 memory model changes are what finally made it
> possible to write dependable multi-thread code. My
> largest applications which run with 100's of threads, will
> run equally well on Windows, Linux and MAC OS-X, without a
> single bit of porting work on the software base.
> The work on putting threads into C++ and the lack of GC
> are revealing the deficiencies it really has in its
> overall design. Applications with huge amounts of complex
> data structures are very difficult to get right. C++
> makes it even harder, because you have to deal with memory
> management more explicitly either through finding the
> right library, or creating the memory model you need for
> C++ was never designed for a multi-threaded world, and it
> never will be able to really get there, with any
> dependable portability and operation, without a
> memory-model and then the standardized threading support
> that uses that memory-model. That's the effort that's
> underway now, and this report shows the issues that are
> going to have to be dealt with both technically,
> practically and religously.
> There are vendors today, providing OS based solutions,
> where they have control/advanced knowledge of the issues
> to deal with, including inparting a memory model in their
> compilers that makes it possible for them to support
> threading in some form.
> Thread designs that I saw in this report, based on library
> and templates, are very risky, because they utilize one of
> the more complex parts of the language specification.
> I'm anxious to see how things evolve toward a workable
> standard. But, in the end, I'm not at all sure it will
> happen without a "virtual machine" designed into the mix
> that provides the right level of abstraction that vendors
> can plug into.
"C++ was never designed for a multi-threaded world, and it never will be able to really get there, with any dependable portability and operation, without a memory-model and then the standardized threading support that uses that memory-model. That's the effort that's underway now, and this report shows the issues that are going to have to be dealt with both technically, practically and religously."
This is a false assumption -- C++ like C, was built to enable the maximum flexibility and keep it as light-weight as possible. I believe Dr. Stroustrup would tell you, go write your own threading library in C++.
He even recommends the Boost library which has an implementation.
C programs can be multi-threaded using the POSIX library -- the language has nothing to do with the subject.
The question is whether the language should implement the behavior as part of it's standard library.
Correct me if I am wrong here, but cross platform issues such as endian-ness are a function of the hardware.