Re: GOMP Requirements v1.1

[Diego Novillo <dnovillo at redhat dot com>]

On Tue, 2004-11-09 at 08:11, Scott Robert Ladd wrote:

> I've posted the GOMP Requirements document for public review.
> 
>      http://www.coyotegulch.com/gomp/gomp_requirements.html
> 
Looks good.  I'd submit it as a patch for GOMP's home page.  Some
suggestions:




        Use of OpenMP will significantly improve performance when the
        appropriate hardware is present.

s/will/may/.


        Benchmarks will be acquired or devised to track and verify
        performance gains.

Hmm, I wonder if we can do little more than verifying that parallel
sections are indeed emitted with the right library calls and what not. 
But I guess that could be adequate enough.



        For example, an arbitrary algorithm that runs in 100 seconds
        when compiled as serial (uniprocessor) code should run in 60
        seconds or less when compiled with OpenMP for a dual-processor
        system, or in 30 seconds or less when four processors are
        available. These numbers suggest the expected performance gains
        from OpenMP; different algorithms and architectures (dual core
        versus dual processor, SMP versus NUMA) will have different
        performance characteristics. 

This is not completely right.  Serial and parallel algorithms are rarely
the same.  Sometimes an excellent sequential algorithm makes for an
extremely poor parallel algorithm (eg, quicksort).

I understand the intent of the paragraph, but it's worded in such a way
that a reader not familiar with concurrency will probably think that by
sprinkling OpenMP pragmas in their code will suddenly produce a
fantastically fast parallel program.

One thing that we could define are intermediate goals that could be
merged into mainline independently of the rest of the system.  For
instance, if we defined builtins for hooking into the gomp runtime, we
could have a release with just the library and the builtins but with no
#pragma processing.  As a second goal, we could merge pragma processing
and finally merge the middle-end changes.


Diego.