Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! - ADA

On 8 Mar, 07:04, "ME" <abcd...@nonodock.net> wrote:
> As many of may have already noticed, there has been a tremendous furor over
> the lack of multicore support in the common languages like C and C++.

No, I did not notice it. It is possble that I've been just too busy
writing multithreaded software in C and C++ and that's why I've missed
this furor.

> Robert Dewar ,our hero, has written an absolutely excellent
> article with a clever intro.http://www.eetimes.com/news/design/s...leID=206900265

No, he didn't write anything special. Actually, there is a lot more to
this subject that he didn't mention.
Take for example lock-free algorithms. There is no visible research on
this related to Ada, unlike Java and C++ (check on
comp.programming.threads).
Ada will most likely miss the "multicore revolution", unless it will
*really* focus on performance - the point is that all this multicore
hoopla revolves around performance, *exclusively*.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

In article
<89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com>,
Maciej Sobczak <see.my.homepage@gmail.com> wrote:

> On 8 Mar, 07:04, "ME" <abcd...@nonodock.net> wrote:
> > As many of may have already noticed, there has been a tremendous furor over
> > the lack of multicore support in the common languages like C and C++.
>
> No, I did not notice it. It is possble that I've been just too busy
> writing multithreaded software in C and C++ and that's why I've missed
> this furor.
>
> > Robert Dewar ,our hero, has written an absolutely excellent
> > article with a clever
> > intro.http://www.eetimes.com/news/design/s...icleID=2069002
> > 65
>
> No, he didn't write anything special. Actually, there is a lot more to
> this subject that he didn't mention.
> Take for example lock-free algorithms. There is no visible research on
> this related to Ada, unlike Java and C++ (check on
> comp.programming.threads).
> Ada will most likely miss the "multicore revolution", unless it will
> *really* focus on performance - the point is that all this multicore
> hoopla revolves around performance, *exclusively*.
>
Not correctness?

--
Christopher J. Henrich
chenrich@monmouth.com
htp://www.mathinteract.com

Ultimately, the most important performance of all is the performance of your
developers. If the product doesn't get to market in time then it might as
well never be developed. That's yet another place where Ada shines. Sure,
you COULD write multithreaded software in C and C++, you could even do it in
assembly or machine code. (Not actually a lot of difference there, IMHO.)
But I bet I'll have my tasks up and running FIRST, and they'll be easier to
debug, too.

By the way, a quick search with Google brought up quite a few results. (I'd
suggest a quick look at Anders Gidenstam's page.) Maybe you're too busy
witing multithreaded software in C and C++, if you'd do your work in Ada you
might have time left over to actually search BEFORE you make unsubstantiated
claims against Ada.

Ada hasn't "missed" the "multicore revolution". Quite the opposite, Ada has
had multitasking built-in since the mid 80's and it works just fine on
multicore platforms. (I know, I've been there, done that.) Perhaps someday
one of those C variants you seem to prefer will have the same kind of
advanced features.

Just my $0.02 worth.

Brian




"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com...
> On 8 Mar, 07:04, "ME" <abcd...@nonodock.net> wrote:
>> As many of may have already noticed, there has been a tremendous furor
>> over
>> the lack of multicore support in the common languages like C and C++.
>
> No, I did not notice it. It is possble that I've been just too busy
> writing multithreaded software in C and C++ and that's why I've missed
> this furor.
>
>> Robert Dewar ,our hero, has written an absolutely excellent
>> article with a clever
>> intro.http://www.eetimes.com/news/design/s...leID=206900265
>
> No, he didn't write anything special. Actually, there is a lot more to
> this subject that he didn't mention.
> Take for example lock-free algorithms. There is no visible research on
> this related to Ada, unlike Java and C++ (check on
> comp.programming.threads).
> Ada will most likely miss the "multicore revolution", unless it will
> *really* focus on performance - the point is that all this multicore
> hoopla revolves around performance, *exclusively*.
>
> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com

Maciej Sobczak wrote:
>
> No, I did not notice it. It is possble that I've been just too busy
> writing multithreaded software in C and C++ and that's why I've missed
> this furor.

No, you haven't.

You may have been writing multithreaded SW in C plus a threading library, or in
C++ plus a threading library, but you haven't been writing it in C or C++.

--
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Phaedrus wrote:
>
> Ada hasn't "missed" the "multicore revolution". Quite the opposite, Ada has
> had multitasking built-in since the mid 80's and it works just fine on
> multicore platforms. (I know, I've been there, done that.) Perhaps someday
> one of those C variants you seem to prefer will have the same kind of
> advanced features.

Ada has had tasking since 1980 (Ada 80, MIL-STD 1815). It was significantly
revised for Ada 83.

--
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74

Maciej Sobczak a écrit :
> Ada will most likely miss the "multicore revolution", unless it will
> *really* focus on performance - the point is that all this multicore
> hoopla revolves around performance, *exclusively*.

Probably, that's why C++ code using threading, OpenMP or MPI are just a
mess. Impossible to maintain because C++ hackers seems to prefer working
hard 6 month for gaining 2% of performance instead of buying a new
computer with more core or adding some node on a cluster. Sorry, but
I've seen that, horrible mess just because hacking C++ code seems fun to
many people.

I prefer using Ada, even losing 10% performance initially, having a
clean object oriented design (using distributed annex, and Ada tasking).
Then when the application is done, just buy the new multicore-box and
you get back the performance than what you loose initially.

The cherry on top of the cake is that your application can be ported to
a new architecture without much trouble. I've seen people spending
months porting an application from one machine to another to "tweak" it
as best as possible. A big lost of money when you compare the salary
against the price of a new machine. Especially since now the application
if full of #define and twisted code that make it just unmaintainable.

I hope at some point people will understand that... All this man-power
burned stupidly !

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Pascal Obry wrote:
> Maciej Sobczak a écrit :
>> Ada will most likely miss the "multicore revolution", unless it will
>> *really* focus on performance - the point is that all this multicore
>> hoopla revolves around performance, *exclusively*.
>
> Probably, that's why C++ code using threading, OpenMP or MPI are just a
> mess. Impossible to maintain because C++ hackers seems to prefer working
> hard 6 month for gaining 2% of performance instead of buying a new
> computer with more core or adding some node on a cluster. Sorry, but
> I've seen that, horrible mess just because hacking C++ code seems fun to
> many people.

Then again, the multicore things have atomic updates built in
which offer some opportunities that only happen to be
part of the Ada language. Now this language feature becomes
visible as part of the top selling CPUs...
There is research on employing these CPU mechanisms for Ada use,
but, IIUC, it is not *visible* on many sites that are visible to
those interested in how to use new multicore CPUs.
And Ada RTS/Library inclusion is not done yet, or is it?

Multicore algorithms can continue the great academic tradition of
efficient algorithms. Aren't lock-free ones really a natural
starting point? They also have their uses.
IIRC, ready-made Communicating Sequential Processes has a lower
visibility in CS than the basic critical section model.

Ada's tasking implementations are not currently known to be the
best choice when an algorithm is about how to efficiently use
the multicore CPU with word sized memory. The tasking protocol as
implemented for x86 < Today turns out to be too heavy weight.
The cost is far beyond 10%.



> The cherry on top of the cake is that your application can be ported to
> a new architecture without much trouble.

Gidenstam has ported his Primitives (Ada packages hiding the
CPU's atomic updates) to at least Intel, Sparc, and MIPS.
Built on top of the Primitives, he has a lock-free bounded buffer
in queue mode...

On Mar 9, 11:20 am, Pascal Obry <pas...@obry.net> wrote:
>
> I prefer using Ada, even losing 10% performance initially.
I usually have 4+ times penalty for Ada program with controlled object
for memory allocation/deallocation control and protected objects for
thread safe operations in comparison with equivalent C++ program. :-(

#include <QString>
#include <QTime>

void test(unsigned length)
{
uint x[length];
QString a[1024];
QString b[1024];
QTime timer;

timer.start();

for (int i = 0; i < 1024; i++)
{
a[i] = QString::fromUcs4(x, length);
}

qDebug("Init %d %lf", length, (double)timer.elapsed() / 1000);

timer.restart();

for (int i = 0; i < 1000; i++)
{
if (i % 2)
{
for (int j = 0; j < 1024; j++)
{
a[j] = b[j];
}
}
else
{
for (int j = 0; j < 1024; j++)
{
b[j] = a[j];
}
}
}

qDebug("Copy %d %lf", length, (double)timer.elapsed() / 1000);
}

int main()
{
test (128);
test (1024);
return 0;
}

with Ada.Calendar;
with Ada.Wide_Wide_Text_IO;

with League.Strings;

procedure Speed_Test_League is

type Universal_String_Array is
array (Positive range <>) of League.Strings.Universal_String;

procedure Test (Length : in Positive);

procedure Test (Length : in Positive) is
use type Ada.Calendar.Time;

X : constant Wide_Wide_String (1 .. Length) := (others => ' ');
A : Universal_String_Array (1 .. 1_024);
B : Universal_String_Array (1 .. 1_024);
S : Ada.Calendar.Time;

begin
S := Ada.Calendar.Clock;

for J in A'Range loop
A (J) := League.Strings.To_Universal_String (X);
end loop;

Ada.Wide_Wide_Text_IO.Put_Line
("Init"
& Positive'Wide_Wide_Image (Length)
& Duration'Wide_Wide_Image (Ada.Calendar.Clock - S));

S := Ada.Calendar.Clock;

for J in 1 .. 1_000 loop
if J mod 2 = 1 then
B := A;

else
A := B;
end if;
end loop;

Ada.Wide_Wide_Text_IO.Put_Line
("Copy"
& Positive'Wide_Wide_Image (Length)
& Duration'Wide_Wide_Image (Ada.Calendar.Clock - S));
end Test;

begin
Test (128);
Test (1_024);
end Speed_Test_League;

On 9 Mar, 04:15, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:

> You may have been writing multithreaded SW in C plus a threading library, or in
> C++ plus a threading library, but you haven't been writing it in C or C++.

You are right.
In the same way, nobody every wrote a GUI program in Ada, nor a
networking program, nobody did any cryptography in Ada, etc. These
languages are almost completely useless nowadays, sigh.
I accept this way of reasoning - but it does not change anything in
the industry practice.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com