I thank K.W. Hirchert for the remarks summarized in the
following points taken up from his mail.
1) probability for name conflicts seemed high.
2) worked poorly when programming interactions between two or
more structures
a) the size of this problem domain is too small to justify
this much extra baggage
b) use my favorite editor to convert the type definition
into the required ASSOCIATE statement
c) problem relatively unusual
"Problem domain is too small" seems to me the more undeserved criticism.
I simply ask the availability, in the new f2k, of tools
suitable to carrying out parallel programs using threads.
The parallel calculation can be carried out using
[a] parallelization directives (and I hope that
the new OpenMP specifications coherent with fortran 90 become
really standard),
[b] directives for data driving parallelism (HPF), [c]
libraries for messages exchange (PVM and MPI) and, at the end,
[d] the seldom used, threads.
The scientific programmers very seldom or never
use threads but, in my opinion, many advantages can be
obtained using threads.
Above all, the threads library is embedded into the kernel of
any multitasking operative system so that efficiency and
optimization are assured.
Then, the use of threads is very cheap and, at least, the
threads are really at hand, already in the old Microsoft
Fortran Power Station 4, and now in the Digital Visual
Fortran. I still use the release 5 but, obviously, also in the
recent DVF6 there is a interface module for this purpose(mt module).
Unfortunately the calls to the threads library functions
are not standard.
Between Windows threads and Unix threads there are not
negligible differences but the meaning is
substantially the same.
By the way, on this subject, I ask that at least some
fundamental functions for the threads management are inserted
in the f2k intrinsic functions set. The chief one, between
these functions is, obviously, that one allowing the creation, called
in Windows CreateThread.
The main problem, to write a high level Fortran program with
threads is, basically, to be able to project the whole
program structure following a suitable scheme.
The proposed WITH instruction or my enhanced ASSOCIATE instruction
make easier the thread programming.
The availability of WITH could avoid injustly damaging a
programming technique offering advantages and very good performances.
At the thread creation moment it is necessary specify the thread job,
that is the function to be executed.
This function is the main program of the thread and must
activate all the subroutines to be called before the thread end.
I name "thread_main" this subroutine that, on the basis of
the library requirements, allows only one argument (that must be integer)
usually used to pass to the thread_main its
identifying number.
I repeat: I am describing a method applicable to ALL programs for
parallel computations using threads.
It is not my personal problem...
A typical thread_main will be the following:
recursive subroutine thread_main(numth)
use thread_mem
integer,intent(in):: numth
call step1(utility_obj(numth))
call step2(utility_obj(numth))
call step3(utility_obj(numth))
....
call step100(utility_obj(numth))
return
end subroutine thread_main
I point out that all subroutines that can be used at the same
time from two or more threads must be declared RECURSIVE to
avoid clash between the threads.
Everyone knows that each big program is made up of many subroutines and then
the thread_main representing what must be done, will be
made up of many subroutines each one representing one of the many
steps of the complex parallel calculation.
Obviously each parallel calculation requires some
synchronization points and then a typical subroutine
can include calls to the thread library to put in wait
the thread at the synchronization point required from the
calculation.
You must notice that the thread_main make use of
only one element of the vector utility_obj(:) defined
in the module used from the thread_main that is the
thread_mem module.
The vector utility_obj is made up of a very, very complex type
of data and the instruction WITH or ASSOCIATED would be very
useful for this type of data.
A typical stepxxx is is made as follows:
recursive subroutine stepxxx(thread_world)
use thread_worl_def
use common_link
type(utility_obj),intent(in out):: thread_word
associate ( *=> thread_world%*) ! hic sunt leones
....
a = b + c ... ! same as thread_world%a =
! thread_world%b + thread_world%c
....
end associate
end subroutine stepxxx
so the typical stepxxx is connected with the thread private
memory by the thread_world argument and all the threads can
exchange data by the objects defined in the common_link
module.
This is the general scheme explaining why I would
like a WITH or enhanced ASSOCIATED instruction would be available,
not indispensable but supporting the readibility and the
mathematical style of the executive instructions
of a generic subroutine step01, step02,....step100.
What I have now written denies the statement relevant to
"a my personal problem". The problem is general: what is the way of
making a scientific programmer can easily use the threads
parallelization scheme and can choose between this
method and the traditional ones:
OpenMP, MPI, HPF (answer to point a) ?
To confute the point b) I admit that with a good editor you
can do everything you like but I find fault with long lists
of ASSOCIATE to be repeated in each subroutine step01, step02, .. step99
instead of a single definition of one utility_type put in
the thread_world_def module.
The reasons are the same that make me prefer a single MODULE
to many COMMON where in each subroutine a certain number of variables
is ridefined (that is the answer to point b).
The COMMON is near, that is in the subroutine, the MODULE is
far away, but I like more an unique MODULE. So the ASSOCIATE list
is near, the utility_object definition is far but I
prefer one because it is unique.
With regard to point c) I admit that the scientific programmers NOW are
not accustomed to using the threads but the threads use is simple, cheap,
efficient and I hope the f2k will include instructions helping
the use of threads. Then, unusual now but very usual in the future (I hope).
With regard to point 1) and 2) I think that who wrote Pascal has already
overcome these difficulties.
Besides, supposing the explicit associations prevailing on the
implicit ones, the ASSOCIATED instruction enhanced with *=>...%*
allows to easily get over the ambiguities.
In the Pascal WITH instruction the more inner object (record)
prevails, that is, If I write WITH aobj,bobj that is:
WITH aobj DO
BEGIN
WITH bobj DO
BEGIN
...:= aandb + ....
END;
END;
the component (Pascal field name) aandb is, without ambiguities,
that one of bobj even if aobj too has a component with the same name.
Than, in the Pascal WITH the last object in the list
prevails whereas in the ASSOCIATE the prevailing of the first
object in the list would be more intuitive, I think
(but I can change my opinion, for analogy with Pascal).
Then:
ASSOCIATE ( *=> aobj%*, *=> bobj%*, bb=> bobj%aandb)
...
END ASSOCIATE
In such a way aandb means aobj%aandb and if I would like
to use bobj%aandb I could use bb.
At least an aesthetic consideration.
I like the mathematical style: it lasts from hundreds of years.
For me a formula is clear when only one symbol represent an object.
I hope UNICODE Fortan will be soon available so that variables
represented with greek, hebrew, indian etc characters could be declared.
If possible, than, a variable must be represented with
one or few symbols and I do not regard as equivalent to can write:
ASSOCIATE (o=>obj)
o%a+o%b+o%c...
END ASSOCIATE
or:
ASSOCIATE ( *=> obj%* )
a+b+c...
END ASSOCIATE
The second possibility is enormously better. The first one tell me
nothing about the formula and turns my stomach.
Best regards
G.B.
Bibliography
http://www.devresource.hp.com/devresource/Topics/Threads/Threads.html
http://www.devresource.hp.com/STK/man/11.00/pthread_3t.html
http://users.erols.com/dnagle/
====
In 09.22 04/12/00 -0600, hai scritto:
>At 09:25 AM 12/4/00 +0100, Giampaolo Bottoni wrote:
>>I look at ftp://ftp.j3-fortran.org/j3/doc/standing/007 but,
>>if I have correctly understood, the ASSOCIATE construct is,
>>from some points of view, LESS powerful than Pascal's and
>>(this is for me more important) JavaScript's WITH.
>>
>>Whith the ASSOCIATE construct I must specify ALL the
>>associated components. I would like instead to IMPLICITLY
>>specify to the compiler that a lot of variables belongs to
>>the same object.
>>
>>With the WITH construct I can look at any Fortran 77
>>old instruction sequence, create a service derived utility_type whose
>>components are all the instruction sequence variables
>>and then, using a simple WITH, perform the
>>sequence instructions with the data of the created utility_object.
>>Without any modification of the old instruction sequence
>>and without a long list of all the instruction sequence variables !!!!
>>
>>If the same calculation must be performed with different
>>data, a parallelization procedure (using the Unix pthread_create(...)
>>or the Windows CreateThread(...)) can be set up where
>>each thread works on a different element of a vector whose elements
>>are of the type of the utility_object.
>>
>>A NEW PROPOSAL for the ASSOCIATE instruction: If I could write:
>>
>>ASSOCIATE ( *=> myobj%* )
>> a=b+c+d+...+z
>>END ASSOCIATE
>>
>>that is if all the components would match to their own names (*=>myobj%*),
>>the ASSOCIATE instruction could work exactly as the WITH !!!
>>Now, instead, I must write:
>>
>>ASSOCIATE (a =>myobj%a, b=>myobj%b ,..., z=myobj%z)
>>
>>a very hard and tiring work if I have hundred of components!
>>
>>...
>>
>>Joking aside, do you think that my proposed enancement ( *=> xxx%* )
>>can be accepted ?
>
>I think it improbable.
>
>The committee was unhappy with the Pascal-like version of WITH for a number
>of reasons. I probably don't remember them all, but here are a couple:
>
>1. The component names unconditionally override local variables with the
>same name. This may not be a problem for small programs written by a
>single author, as that author can arrange for the names not to overlap, but
>in larger programs with multiple authors, the probability for name
>conflicts seemed high. It would be possible to work around this if a
>renaming facility (like that on the USE statement) were included, but that
>seemed at odds with the original intent of having a _simple_ ASSOCIATE
>construct.
>
>2. Although the Pascal-like approach can work well when dealing with the
>components of a single structure, it worked poorly when programming
>interactions between two or more structures. One could only "abbreviate"
>the references to one of the structures, so references to the other(s) had
>to be written in full.
>
>For these reasons and others, the committee felt it better that the user,
>rather than the compiler, be in control of the abbreviated names being
>created by ASSOCIATE. It was assumed that in the single structure case,
>rather than write
>
>ASSOCIATE (a =>myobj%a, b=>myobj%b ,..., z=myobj%z)
> a=b+c+d+...+z
>END ASSOCIATE
>
>one would be more likely to write something like
>
>ASSOCIATE (M => myobj)
> M%a=M%b+M%c+M%d+...+M%z
>END ASSOCIATE
>
>[In practice, most of the components names are likely to be longer that one
>character, but the "abbreviation" for the object really is likely to be one
>or two characters long, so the "overhead" for referencing components would
>be kept relatively small.] This approach extends well to multiple
>structures; all one has to do is add more "abbreviations" for the
>designators of the other objects.
>
>I realize that this approach does not work well for the particular problem
>you are describing because of your requirement that the reference syntax
>not be changed. I suppose it _possible_ that the committee would consider
>your proposed extension to support that particular class of problems, but I
>think it likely that they would find the size of this problem domain too
>small to justify this much extra baggage.
>
>[I find it somewhat disingenuous for you to complain about dealing with
>hundreds of component names in the ASSOCIATE statement when you were
>willing to deal with those same hundreds of names in creating the
>type. Indeed, if I were faced with your application on a one-shot basis, I
>would probably use my favorite editor to convert the type definition into
>the required ASSOCIATE statement, so I wouldn't have to deal with those
>hundreds of components individually. (If I were doing it repeatedly, I
>would probably use a Perl script instead -- higher initial cost but less
>incremental cost each time I created a new ASSOCIATE statement.)]
>
>Perhaps I am misjudging the extent of your problem domain, but its special
>characteristics, i.e.,
>a) the existence of extensive code that you wish to change from applying to
>variables to applying to components without textual modifications,
>b) the lack of need to access other variables in the surrounding
>environment, and
>c) the lack of need to deal with more than one instance of the structure at
>at time,
>collectively strike me as being relatively unusual.
>
>--
>Kurt W Hirchert [log in to unmask]
>UIUC Department of Atmospheric Sciences +1-217-265-0327
>
|
