On Mon, 2006-08-28 at 15:55 -0400, Peter Tanski wrote:
> On Aug 28, 2006, at 2:19 PM, skaller wrote:
> As for assembler,
> that sounds like a huge project.
Not really that hard.
> It's too bad the C-- people are
> lagging at the pace of academic research.
I think it is a pity it went slightly overboard.
> > OpenMP ... I meant supporting it *in Felix*.
> >
> > OpenMP specifies various constructions for C++.
> >
> > My thought is to provide matching Felix constructions
> > with similar semantics.
>
> You intend to extend felix to the assembly level? Isn't that what it
> would take?
No, why would it?
Machine code doesn't help spawning threads .. that can only
be done by the operating system.
All the synchronisation support is already available in Posix.
Some low level stuff, as mentioned by Marcus, may help make
it faster. For example flushing the cache, or one cache line,
on AMD64 is a user space machine instruction.
If gcc doesn't provide it directly, it can be encoded with
one line of _asm { .. } code.
Similarly for 'lock free' operations. On AMD64 atomic
increment is one instruction with a LOCK prefix.
The actual hard stuff is, for example, in the parallel loop,
deciding how to parcel out the iterations to the available
threads .. and that's just a simple math calculation:
choosing the right formula is the hard part, and OpenMP
more or less leaves that up to the programmer anyhow :)
OpenMP doesn't drill down to sending instructions off
to one or more CPUs .. most CPU's already do this internally,
sending instructions off to multiple calculating units,
but it is a function of the microcoding, not accessible
to the application programmer, except perhaps by using
specific interfaces like MMX/SSE or whatever ..
that's not really thread parallelism but vectorisation.
Gcc supports that for all platforms already.
> > well yes .. since it isn't a messaging protocol, that part is easy :)
> > It provides hints about how to distribute work between processors.
>
> So OpenMP really only provides a benefit on a single multiprocessor
Yes. It's intended only for shared memory single computer
multiprocessors, from machines like my AMD64 x2 dual core
up to Sun's machines which can run 64 processors.
Tomorrow AMD will have 256 core chips... so scalability
is important :)
This is also why a parallel collector is important.
Cluster computing is another level up, using network
connected machines with no shared memory. This is harder,
because you want to be able to run across the Internet,
but at the same time optimise away the networking interface
if you're running processes on a multi-processor.
> > I have yet to check, but completely ignoring these hints
> > appears to be a valid implementation. In C++ the hints
> > are all pragmas, and the parallelised code can be executed
> > 'as written' sequentially with the same semantics.
>
> But then it would be no more "parallel" than a single-threaded
> application would be, right?
Yes, that's right. You can write a parallel program, and
still compile and run on a system with no Open MP support
(except for the functions which would be dummy).
This is why the constuctions are modelled using
#pragma omp ...
Ignoring pragmas is harmless (it isn't allowed to change
semantics).
> I honestly don't know that much about OpenMP
Neither did I until 10 minutes ago .. just download and
scan the specs.
It is, actually, quite good IMHO.
> You can use both PVM and MPI (latest: MPICH2) on a single
> multiprocessor computer and get roughly the same effect you would
> using OpenMP. They each use their own runtime system.
Maybe. OpenMP is designed for shared memory, MPI at least
isn't. So it isn't clear that all programs would be equally
efficient: shared memory is a lot faster sometimes: it is
very hard to beat hardware cache synchronisation with
library functions doing the same job.
> > No reason you can't do both: they're two different levels of
> > granularity.
>
> You mean both as in one implementation that runs both or as in two
> implementations?
I mean you can use both OpenMP pragams and MPI message passing
in the same program. Because the former is shared memory
threading and the latter is process level message passing:
there is no common conflict (provided MPI implementation
is thread safe of course!)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
