The Future of C++ ?

[blangela]

If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.

I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years. Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

I do believe that C++ is more difficult to learn than many of these
other languages. Despite my best efforts to make them exciting, I see
the eyes of my students start to glaze over when I start explaining
pointers. When I ask them to tokenize an english sentence (using the
strtok() function) and print the token in reverse order (they need to
declare an array of type char * and save the addresses of the tokens in
this array), I experience near panic from many of my students. But
these concepts need to be taught in a responsible C++ course. As was
pointed out to me recently, Microsoft still requires applicants to
demonstrate a very good knowledge of string manipulation using C-style
strings (none of these fancy string class objects!) when recruiting C++
programmers.

The ironic part is there is still a large demand for C++ developers
here in Vancouver. In fact, the company that I believe employs the
most developers here in Vancouver, employs almost entirely C++
programmers. This company, Electronic Arts (if you have not heard of
them, I guarantee that your kids have -- they create video games) is
only one of several gaming companies here in Vancouver that employ
primarily C++ programmers. Other companies like Kodak, MDSA, Nokia,
MDSI, etc. also employ large numbers of C++ programmers. Not
surprisingly, I have talked to several companies here in Vancouver who
are complaining that they are having difficulty finding C++ developers
and are looking at trying to recruit from abroad (eastern Europe
primarily).

I believe that many of these companies will be forced to migrate away
from C++ in the near future, simply because they will not be able to
find C++ programmers in the future. Soon the baby boomer C++
programmers will begin to retire, then the proverbial @@@@ will really
start to hit the fan!

Please tell me I am wrong, and paint me a view of the future which
includes C++.

[Noah Roberts]

Earl Purple wrote:

Just a little space savings? We are talking about a whole community
here that does not use exceptions at all because of the enormous
overhead.

Yeah, I've talked to those people. As far as I can tell not a one has
any objective information to back up the claim that there even is any
overhead much less enormous overhead. Some have minimal experience
with some compiler they used in the 90's that handled exceptions poorly
and have never bothered to look at anything more modern...those are the
_most_ informed.

[Chris Thomasson]

ACK! Those were crappy old versions...
Here is the newest ones:

..align 16
# int refcount_ia32_c as(
# refcount_ia32_t * volatile*,
# refcount_ia32_t *,
# refcount_ia32_t *)
..globl _refcount_ia32_ cas
_refcount_ia32_ cas:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_c as_failed
MOVL 8(%ESP), %EAX
MOVL 12(%ESP), %EDX
LOCK CMPXCHGL %EDX, (%ECX)
JNE refcount_ia32_c as_failed
MOVL $1, %EAX
RETL

refcount_ia32_c as_failed:
XORl %EAX, %EAX
RETL


..align 16
# int refcount_ia32_a dd_cas_weak(
# refcount_ia32_t * volatile*,
# refcount_ia32_t *,
# refcount_ia32_t *,
# int)
..globl _refcount_ia32_ add_cas_weak
_refcount_ia32_ add_cas_weak:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_c as_failed

MOVL 12(%ESP), %EDX
TESTL %EDX, %EDX
JE refcount_ia32_a dd_cas_weak_exe cute
MOVL 16(%ESP), %EAX
CMPL $0, %EAX
JLE refcount_ia32_a dd_cas_weak_exe cute
LOCK XADDL %EAX, (%EDX)

refcount_ia32_a dd_cas_weak_exe cute:
MOVL 8(%ESP), %EAX
LOCK CMPXCHG %EDX, (%ECX)
JNE refcount_ia32_a dd_cas_weak_dec
MOVL $1, %EAX
RETL

refcount_ia32_a dd_cas_weak_dec :
TESTL %EDX, %EDX
JE refcount_ia32_a dd_cas_weak_fai led

CMPL $0, 16(%ESP)
JLE refcount_ia32_a dd_cas_weak_fai led
LOCK DECL (%EDX)

refcount_ia32_a dd_cas_weak_fai led:
XORL %EAX, %EAX
RETL

Can you notice the difference between the crap code and this code? Hint...
It has something to do with redundant condition codes...
;^)

[Mirek Fidler]

ACK! Those were crappy old versions...

Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).

LOCK CMPXCHGL %EDX, (%ECX)

LOCK XADDL %EAX, (%EDX)

LOCK CMPXCHG %EDX, (%ECX)

LOCK DECL (%EDX)

Are these considered lock-free? Or they are used in "slow path" only?

If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?

Mirek

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

>ACK! Those were crappy old versions...

Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).

> LOCK CMPXCHGL %EDX, (%ECX)

> LOCK XADDL %EAX, (%EDX)

LOCK CMPXCHG %EDX, (%ECX)

> LOCK DECL (%EDX)

Are these considered lock-free?

Yes. They do assert the bus lock signal, but that different than using a
mutex:

http://groups.google.de/group/comp.p...d5c6aa62e8f876
(this might clear some thing up for you...)

Or they are used in "slow path" only?

The only place where my algorithm makes use of a lock is in the
refcount_ia32_a dd_load_strong( ...) function, and when the
refcount_ia32_s ub_strong(...) drops the reference count to zero. Other than
that, everything is 100% lock-free.

If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?

Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.

[Chris Thomasson]

Here is another link to some more info on my algorithm:

http://groups.google.com/group/comp....a6aff02b594e70

[Mirek Fidler]

Chris Thomasson wrote:

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** **************@ 16g2000cwy.goog legroups.com...

ACK! Those were crappy old versions...

Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).

LOCK CMPXCHGL %EDX, (%ECX)

LOCK XADDL %EAX, (%EDX)

LOCK CMPXCHG %EDX, (%ECX)

LOCK DECL (%EDX)

Are these considered lock-free?

Yes. They do assert the bus lock signal, but that different than using a
mutex:

Actually, I always thought that basic Win32 mutex (CRITICAL_SECTI ON) is
(in fast path) nothing more than single CAS operation...

Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.

I was sort of hoping that you found a way around this LOCK :)

If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?

Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.

Confused a bit again.

Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?

Does strong safety here mean that I would be able to read and/or write
the String without locking?

( Who needs it? :-) )

Thanks for explaining.

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** *************@j 72g2000cwa.goog legroups.com...

>
Chris Thomasson wrote:

>"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******* *************** @16g2000cwy.goo glegroups.com.. .

>ACK! Those were crappy old versions...

Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).

[...]

>
Are these considered lock-free?

Yes. They do assert the bus lock signal, but that different than using a
mutex:

Actually, I always thought that basic Win32 mutex (CRITICAL_SECTI ON) is
(in fast path) nothing more than single CAS operation...

Consider the fact that the interlocked instruction used for CRITICAL_SECTIO N
does not operate on the shared data you want to alter. It only operates on
the lock state. And, you have to take into account that a lock has to be
unlocked. Thats another interlocked instruction.

So, if you measure a 100% uncontended lock-free operation vs. a 100%
unconteded lock-based operation you get this:

lock-free update if a word
------------------------

1 interlocked instruction


lock-based update of a word
-----------------------------

2 interlocked instructions
1 store


-- The interlocked instruction in the lock-free performed the update
directly to the word.
-- The interlocked instructions in the lock-based performed the update on
the locks internal state. The store instruction actually updated the word...
IMO, the lock-free stuff is a winner... Now if you take contention into
account, well, the lock-based stuff might have to park threads in the
kernel! The lock-free will not...
Is this making any sense to you? I don't think that I am a very good
teacher, but I try... So try to bear with me here...

;^)

Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.

I was sort of hoping that you found a way around this LOCK :)

If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?

Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.

Confused a bit again.

Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?

If you perform the atomic increments under the protection of the lock, then
you will be fine.

Does strong safety here mean that I would be able to read and/or write
the String without locking?

Once you acquire a strong reference to you string object, you can do
lock-free COW via. CAS.

[Joe Seigh]

Mirek Fidler wrote:

Chris Thomasson wrote:
Actually, I always thought that basic Win32 mutex (CRITICAL_SECTI ON) is
(in fast path) nothing more than single CAS operation...

Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.

I was sort of hoping that you found a way around this LOCK :)

Branch logic is almost as expensive as an inline LOCK. In multi-core
will become the norm, unconditional LOCK is probably the most efficient.

>

>>>If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?

Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.

Confused a bit again.

Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?

Does strong safety here mean that I would be able to read and/or write
the String without locking?

( Who needs it? :-) )

Maybe not for String, but for the more complex data structures like
collections lock-free beats anything else out there in solving
the reader/writer problem.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Chris Thomasson]

Once you acquire a strong reference to you string object, you can do

lock-free COW via. CAS.

The basic idea is:
pseudo-code
---------------

typedef std::string mystring_t;
typedef vzsync::ptr::gl obal<mystring_t mystring_gptr_t ;
typedef mystring_gptr_t ::local_t mystring_lptr_t ;
static mystring_gptr_t s_buf(new mystring_t("hel lo"));
void do_cow_cas(myst ring_t const &src) {
mystring_lptr_t xchg(new mystring_t), cmp;

do {
cmp = s_buf;
if (cmp) {
xchg->append(src);
}
} while(s_buf.cas (cmp, xchg));
}
or you can do a 100% lock-free swap like this:

void do_swap_weak(my string_lptr_t &dest, mystring_t const &src) {
dest->append(src);
s_buf = dest;
}
There are more tricks... However, are you having trouble understanding the
pseudo-code?

[Chris Thomasson]

ARGHGGH!

void do_cow_cas(myst ring_t const &src) {
mystring_lptr_t xchg(new mystring_t), cmp;

do {
cmp = s_buf;
if (cmp) {

Need to add this of course!!!

xchg->assign(*cmp) ;

xchg->append(src);
}
} while(s_buf.cas (cmp, xchg));
}

sorry for any confusion!

;^(...