|
in reply to Re: Multi-core and the future
in thread Multi-core and the future
I can elaborate on that a bit.
Consider control structures such as for loops. In Fortran, they put the "for" after the statement to indicate vector hardware usage. Perl has the same syntax! But, it works the same as the ordinary form. But, in general the idea is to define looping constructs that are more like SIMD rather than traditional loops. That is, perform this step on each of all these items, but in no particular order. Order of the iterations is not defined, and may just as well be parallel or code for the SIMD instructions on the CPU.
In particular, the "hyper" operator syntax is defined this way. @c = @a »+« @b; will add the corresponding elements in parallel. @list.».run(); will execute the method on every item in the list, in parallel.
Also, lists may be "lazy", and establish co-routines to delay evaluation. But, if there are more cores free, why not start working on the list AND return at the same time? Don't wait for items to be needed for sure, any more than always computing them up front. It can compute the list in the background.
—John
|
Re^3: Multi-core and the future
by BrowserUk (Patriarch) on Aug 31, 2008 at 22:38 UTC
|
All of this sounds great. And by great, I mean: brilliant; fantastic; amazing; extraordinary; just what the doctor ordered. I intend no hint of 'faint praise' here. But...
Does any of this actually work? Anywhere?
Each time a new parrot comes out I dutifully download it and go in exploration of the infrastructure to support these constructs, and I come up short.
And every now and again I pop over to PDD 25 and look for changes, but rarely notice any. It still talks the talk of supporting every concurrency model known to man, and then some, but comes up way short of explaining how it's going to achieve this feat.
And that's essentially why I stopped following the P6 lists. There is an aweful lot of talk about what P6 will do. Discussion after excruciating discussion about almost irrelevant minutia of what perl 6 will do. But almost nothing, and fiery defence for there being nothing, when the question is asked: how will P6/Parrot pull this off. (Not to mention the now sad joke of "by Christmas" for the question: when.)
I want to believe. I really, really want to believe...
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Actually audreyt did present a version of pugs once that parallelized meta operators, with measurable speed difference between single core and dual core (not quite a factor of 2, but somewhere around 1.7 iirc). I don't know if "mainstream" pugs does it, though.
I agree that it's hard to keep faith, but recently something helped me a lot: I played with grammars in Rakudo, and found that 1) although they are still limited, they work quite well and 2) it's really easy to parse stuff for which you'd normally write a recursive descending parser. (And I'll blog about it later this week). Now I firmly believe that they will be one of the killer features of Perl 6, even if concurrency might turn out not to work as well as promised.
I don't think that you'll see a working, usable Perl 6 level concurrency implementation within the next year, though.
| [reply] |
|
|
| [reply] |
|
|
It still talks the talk of supporting every concurrency model known to man
And does it really need to? In the first release?
Wouldn't it be better to keep it in mind so the design isn't completely closed to future concurrency changes, and get something out the door?
I'm assuming not everything in Perl 6 can work perfectly in the first ever release, so there would be a scoped delivery plan for which features go in 6.0, 6.1, 6.2 ... anyway, wouldn't it?
/J
| [reply] |
|
|
And does it really need to? In the first release?
Personally, I think not. From my perspective PDD 25 reads like nobody could make up their mind which were important, so they opted for them all. However, I am very aware as I write, that Allison Randall is a seriously knowledgable person, and I may just be missing the point.
The problem with making the choice of concurrency model for Parrot, is the ideal of being able to support the requirements of any dynamic high level language that might sit atop it.
The really tough part about concurrency is that you cannot tack it on later with any prospect of useability or performance. It has to be accounted for in the design of every aspect of the low-level supporting infrastructure. There is no way around that. Memory management, garbage collection, IO infrastructure, even the right choice of underlying C-runtime libraries are critical to success.
And all of those choices are compounded by:
- each concurrency model you attempt to support;
- each HLL that might utilise them in novel ways;
And that's the crux of the nervous tremours I feel in my gut each time I read about what Perl 6 will do and what Parrot will support. I have expended a considerable amount thought and reading to trying to understand how to implement just one of the concurrency models mentioned, and I believe it to be extremely hard, but doable.
But trying to support them all? Trying to design a garbage collector that can support all those models of concurrency, potentially concurrently with the requirement to be able to run (say) Ruby code from within Python code from within Perl code. Will that ever be doable?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re^3: Multi-core and the future
by moritz (Cardinal) on Aug 31, 2008 at 22:32 UTC
|
Another typical example for un-ordered evaluation are junctions.
all($x, $y, $z) > 0
autothreads to
all($x > 0, $y > 0, $z > 0)
At the same time it short circuiting, so as soon as one of these conditions is false, the execution of all other autothreaded comparisons (or in general sub calls) can be interrupted. | [reply]
[d/l]
[select] |
Re^3: Multi-core and the future
by swampyankee (Parson) on Aug 31, 2008 at 22:26 UTC
|
Parallelism is one of the reasons why F90 introduced array operations, e.g., something like Perl's @a = @b or grep; implementation of these would be an obvious part a parallel version of Perl (∀Perl?). In F90, there is no special syntax akin to @a = @b »+« @c needed; it's not distinguished from a regular addition.
Information about American English usage here and here. Floating point issues? Please read this before posting. — emc
| [reply] |
|
|
Consider multiplication. @a »*« @b is explicitly element-wise looping over the operator. @a * @b is not built-in, and could be defined, for example, between two Matrix objects if you like, to do matrix multiplication. You could also define infix:<+> between two lists to simply call the hyperoperator. Also, the syntax generalizes more than the implicit way of Fortran: apply a method call to each element, rather than to the container itself.
| [reply] |
|
|
Usually (F90 permits overloading), F90's array operations apply the same operation to each element of an array, and cannot process arrays which aren't conformal (same organization), so F90's array operation A = B * C would be the equivalent to
real,dimension(2,3,4) :: A, B, C
integer j, k, m
do j = 1, 2
do k = 1, 3
do m = 1, 4
A(j,k,m) = B(j,k,m) * C(j,k,m)
enddo
enddo
enddo
Of course, Fortran programmers like typing no more than any other type of programmer1, so A = B * C would be preferred ;-).
I'm not saying that the F90 way is optimal; it's just that the philosophy behind the F90 standard is to make parallelization transparent to the application programmer, which means that having a different syntax for parallel operations would be frowned upon. Certainly, some of Perl's existing syntax (grep, many list operations) could be parallelized without any visible changes to the language.
1 Well, maybe COBOL programmers like typing, but I wouldn't want to stereotype them.
Information about American English usage here and here. Floating point issues? Please read this before posting. — emc
| [reply]
[d/l] |
|
|
