[Beowulf] Linux Magazine - What He Said

Vincent Diepeveen diep at xs4all.nl
Thu Oct 2 06:28:38 PDT 2008


To comment a bit on the article:

 >What if a high level programing description language was developed.  
Note I did not say programming language.
 >This description language would allow you to “describe” what you  
needed to do and not how to do it (as
 >discussed before). This draft description would then be presented  
to an AI based clarifier which would examine
 >the description, look for inconsistencies or missing information  
and work with the programmer to create a formal
 >description of the problem. At that point the description is turned  
over to a really smart compiler that could target
 >a particular hardware platform and produce the needed optimized  
binaries.
 >Perhaps a GA could be thrown in to help optimize everything.

The typical average PHD way of approaching problems they need to solve:

Suppose you need to solve a huge problem A at a major parallel machine.
We throw the problem A into a blackbox B giving output A'.

Now our fantastic new brilliant method/algorithm comes into place  
that works on A' what our paper is about,
and we solve the problem with that.

I see that scenario a lot in all kind of different variations.

A great example of it is:

We invent algorithm f( x )

Now in our program we have
    if( magicfunction(x) && f(x) )
       then printf("problem solved. jippie i got my research done.\n");

They test it at 1 case C and shout victory.
typical AI way of doing things. There is so little AI dudes who do  
more than fill 50 pages of paper a year with ideas that keep untested,
and because of never testing their understanding of the problem never  
advances and the next guy still shows up with the same untested
solution. So the above guy who actually is *doing* something and  
testing something, already gets cheered for (with some reasons).

But of course magicfunction(x) only works for their case C.
There is no statistic significance.

The number of AI guys who test their algorithm/method at state of the  
art software, be it selfwritten or from someone else,
AND test is statistical significant without using some flawed testset  
where magicfunction(x) is always true, those guys you can
really count on 2 hands the past 30 years.

In parallel AI it is even worse in fact. There is for example just 2  
chessprograms that scale well (so without losing first factor 50 to  
the parallel
search frame) at supercomputers. There is some fuzz now about go  
programs using UCT/Monte Carlo and a few other algorithms
combined; but these random algorithms miss such simple tactics, which  
for their computing
power should be easy to not miss, that they really should think out a  
better way to search there parallel.

Each AI solution that is not embarrassingly parallel is so difficult  
to parallellize well, so not losing a factor 50,
that it is just real hard to make generic frameworks that work real  
efficient. Such a framework would pose a solution for only 1
program; as soon as you improve 1 year later the program with a new  
enhancement the entire parallel framework might need to get
rewritten from scratch again, to not again lose some factors in speed  
in scaling.

The commercial way most AI guys look to the parallel problem is  
therefore real simple:
    "can i get faster than i am at a PC, as it is a government  
machine anyway,
     i didn't pay for efficient usage of it, i just want to be faster  
than my home PC
     without too much effort".

I'm not gonna fight that lemma.

However a generic framework that works like that is not gonna get  
used of course. It just speeds you up so much to make a custom
parallel solution, that everyone is doing it.

Besides, the hardware is that expensive, that it's worth doing it.

 >This process sounds like it would take a lot of computing  
resources. Guess what? We have that.

 >Why not throw a cluster at this problem. Maybe it would take a week  
to create a binary,
 >but it would be cluster time and not your time. There would be no  
edit/make/run cycle
 >because the description tells the compiler what the program has to  
do. The minutia
 >(or opportunities for bugs) of programming whether it be serial or  
parallel would be
 >handled by the compiler. Talk about a killer application.




On Oct 2, 2008, at 11:05 AM, John Hearns wrote:

> I just read Douglas Eadline's article on Linux Magazine, entitled  
> "What He Said"
> http://www.linux-mag.com/id/7087
>
> Very thought provoking article, and took me back to thinking about  
> genetic algorithms,
> a subject I flirted with 20 years ago. I didn't find it worthwhile  
> on a Sparc1 system with a whopping 2 Mbytes of RAM.
>
> I guess I should encourage responses to be made on the Linux Mag site.
>
> John Hearns
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit  
> http://www.beowulf.org/mailman/listinfo/beowulf





More information about the Beowulf mailing list