Fortran 90 and later allow arithmetic operations on whole arrays, like so:
!Both arrays must be the same shape integer foo(37), doublefoo(37) doublefoo=foo*2
This is actually a highly useful feature as it reduces the need for looping (a common place for bugs to hide) and allows array operations to be distributed over multiple processors, if available.
In Pascal, the above might look something like this:
var foo, doublefoo: array[1..37] of integer; {...}
begin {...} doublefoo:=2*foo; {...} end.
--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|
For your information: that already exists in FPC. It's called operator overloading:
http://www.freepascal.org/docs-html/ref/refch12.html#x161-16800012
Felipe Monteiro de Carvalho wrote:
For your information: that already exists in FPC. It's called operator overloading:
GPC has operator overloading as well (as was mentioned here before), and a straightforward array multiplication operator can be implemented in GPC as is.
But I think John's main point was parallelization, i.e. multiplication of larger arrays (I suppose, 37 wouldn't quite make it worthwhile ;-) would automatically be distributed over multiple processors as he wrote, or as we'd probably implement it, into several threads (where the thread -> CPU mapping is left to the OS).
I think perhaps also this can be implemented purely as library code (I generally prefer to keep as much as possible outside of the compiler, because inside of the compiler most things are usually much more complicated). It's not trivial (as multithreading always isn't), and some care is necessary because GPC's runtime in general isn't thread-safe yet, but with careful programming it might be possible today. (If not, some hopefully small issues WRT GPC or the runtime which might arise would need to be fixed.)
Frank
On Fri, Aug 6, 2010 at 8:36 AM, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
GPC has operator overloading as well (as was mentioned here before), and a straightforward array multiplication operator can be implemented in GPC as is.
Interresting, I didn't know it. Is the syntax fpc compatible?
I guess that what prevented me over the years from changing from a vague curiosity about GPC and actually using it is the fact that it doesn't compile the vast majority of Pascal code out there. Had it supported delphi-like syntax with dialect modes like FPC it would probably have been way more used.
But I think John's main point was parallelization, i.e. multiplication of larger arrays (I suppose, 37 wouldn't quite make it worthwhile ;-) would automatically be distributed over multiple processors as he wrote, or as we'd probably implement it, into several threads (where the thread -> CPU mapping is left to the OS).
You can implement that in the code of the operator overloading, just start a thread there.
On 06 Aug 2010, at 13:06, Felipe Monteiro de Carvalho wrote:
I guess that what prevented me over the years from changing from a vague curiosity about GPC and actually using it is the fact that it doesn't compile the vast majority of Pascal code out there. Had it supported delphi-like syntax with dialect modes like FPC it would probably have been way more used.
GPC's problem is not a lack of users, it's a lack of developers (which in turn, as has been discussed, is probably mostly due to the fact that it's written in C). And just like you don't/can't use GPC because it doesn't compile the code you are interested in, there are a bunch of people who don't/can't use FPC because it doesn't compile the code they are interested in.
I think that trying to cater to the same community as FPC would have helped GPC, all other things being equal. It would mainly have meant that its scarce development resources would have been even more thinly spread (not to mention that Delphi is constant moving target).
Jonas
On 06 Aug 2010, at 13:23, Jonas Maebe wrote:
I
*don't*
think that trying to cater to the same community as FPC would have helped GPC, all other things being equal. It would mainly have meant that its scarce development resources would have been even more thinly spread (not to mention that Delphi is constant moving target).
Felipe Monteiro de Carvalho wrote:
But I think John's main point was parallelization, i.e. multiplication of larger arrays (I suppose, 37 wouldn't quite make it worthwhile ;-) would automatically be distributed over multiple processors as he wrote, or as we'd probably implement it, into several threads (where the thread -> CPU mapping is left to the OS).
You can implement that in the code of the operator overloading, just start a thread there.
You probably wouldn't want to start a thread for each multiplication. That's why I said it's not trivial, among other things. I suppose you would use a thread manager or whatever. And then, you'd probably need to let the user control the number of threads (usually a number equal to the number of CPUs or slightly higher (to avoid wasting time during blocks) might be optimal, but some users might prefer to keep some of their CPUs for other tasks or run several such programs in parallel).
Jonas Maebe wrote:
I think that trying to cater to the same community as FPC would have helped GPC, all other things being equal.
Is there a "not" missing?
It would mainly have meant that its scarce development resources would have been even more thinly spread (not to mention that Delphi is constant moving target).
Furthermore, the resources are not naturally given (which also seems to be a rather common misconception here). I don't care much about Delphi, neither personally nor professionally, for several, probably well-known reasons, so I wouldn't have put much work in GPC if it was (mainly or exclusively) oriented in that direction.
Frank
On Fri, 6 Aug 2010, Frank Heckenbach wrote:
But I think John's main point was parallelization, i.e. multiplication of larger arrays (I suppose, 37 wouldn't quite make it worthwhile ;-) would automatically be distributed over multiple processors as he wrote, or as we'd probably implement it, into several threads (where the thread -> CPU mapping is left to the OS).
37000000 would work. :-)
--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|
-
Felipe Monteiro de Carvalho -
Frank Heckenbach -
John L. Ries -
Jonas Maebe