Re: Perl6 and "accents"
Tom Christiansen wrote:
Exegesis 5 @ http://dev.perl.org/perl6/doc/design/exe/E05.html reads:
# Perl 6
/ < - [A-Za-z] >+ / # All alphabetics except A-Z or a-z
# (i.e. the accented alphabetics)
[Update: Would now need to be <+ - [A..Za..z]> to avoid ambiguity
with "Texas quotes", and because we want to reserve whitespace as the first
character inside the angles for other uses.]
Explicit character classes were deliberately made a little less convenient
in Perl 6, because they're generally a bad idea in a Unicode world. For
example, the [A-Za-z] character class in the above examples won't even
match standard alphabetic Latin-1 characters like 'Ã', 'é', 'ø', let alone
alphabetic characters from code-sets such as Cyrillic, Hiragana, Ogham,
Cherokee, or Klingon.
First off, that "i.e. the accented alphabetics" phrasing is quite incorrect!
Of course. If the author intended to match "special" (= non-ASCII) Latin
letters, it should be something like
use charnames ();
for $codepoint ( 1 .. 0x ) {
$char = chr($codepoint);
if (
$char =~ /\p{L}/
&& $char =~ /\p{Latin}/
&& $char !~ /[A-Za-z]/) {
printf("%c %04X %s\n", $cp, $cp, charnames::viacode($codepoint));
}
}
Code like /[^\P{Alpha}A-Za-z]/ matches not just things like
[...]
but also of course:
[...]
00C6 LATIN CAPITAL LETTER AE
00D0 LATIN CAPITAL LETTER ETH
Good examples.
Both cannot be decomposed. Depending on your needs 'LETTER AE' can be
seen as a ligature. For example current botanical Latin allows (AFAIK)
'LETTER AE' but also 'LETTER A' + 'LETTER E'. If someone needs to match
both variants, there is no way around a local-specific transliteration.
'LATIN CAPITAL LETTER ETH' looks like an accented character (0110 LATIN
CAPITAL LETTER D WITH STROKE). Unicode policy does not (did not) allow
(de-)composition of overlays, which is the case for example for all
characters 'WITH STROKE'. Thus ':ignoremark' and ':samemark' will be
useless, if someone needs similarity matching of e.g.
unmark('ø') =~ /o/
[...]
It's not. Accent is not a synonym for any of those. Not all marks are
accents, and not all accents are marks.
I believe what is meant by "accent" is NFD($char) =~ /\pM/. Fine: then
say "with diacritics", not "with accents".
Agreed. Everything related to Unicode should use Unicode terms at least
in the definition. And if a Unicode term is used it should exactly mean
what is specified in the Unicode standard. E.g. it would be a fault, if
graphemes are defined by '\pX' or '(?>\PM\pM*)', as Unicode provides the
properties 'Grapheme_Base' and 'Grapheme_Extend' (unfortunately they are
not supported by Perl 5 or Perl 6).
Helmut Wollmersdorfer
Re: Perl6 and "accents"
Tom Christiansen wrote:
Certainly it's perfectly well known amongst people who deal with
letters--including with the Unicode standard.
"Accent" does have a colloquial meaning that maps correctly,
but sadly that colloquial definition does not correspond to
the technical definition, so in being clear, you become less
accurate. There is, as far as I'm aware, no good middle
ground, here.
One doesn't *have* to make up play-words. There's nothing wrong with the
correct terminology. Calling a mark a mark is pretty darned simple.
Well, scientist are not always happy with Unicode terms, e.g.
'ideograph' for Han characters, or 'Latin' for Roman scripts. But the
terms should be used as defined by the standard--as names/identifiers of
properties.
Unicode has blocks for diacritic marks, and a Diacritic property for
testing whether something is one. There are 1328 code points whose
canonical decompositions have both both \p{Diacritic} and \pM in them,
946 code points that have only \pM but not \p{Diacritic}, and 197 that
have \p{Diacritic} but not \pM.
If someone really uses Unicode there is way no around deep knowledge of
the properties. Such code will use Unicode properties directly, and Perl
6 should therefore support all the properties.
I still think resorting to talking about "accent marks" is a bad idea.
I had somebody the other day thinking that "throwing out the accent marks"
meant deleting all characters whose code points were over 0x7F--and this
was a recent CompSci major, too.
I know this sort of people. They also believe that UTF-8 is a 2-byte
encoding.
But that's nothing. The more you look into it, the weirder it can get,
especially with collation and canonical equivalence, both of which really
require locale knowledge outside the charset itself.
Sure. The specs of Perl 6 still need huge work on the Unicode part.
Helmut Wollmersdorfer
Re: Perl6 and "accents"
FYI, Larry "accents" to "marks" in this commit, as well as some refactoring of the short adverbs associated with them: http://www.nntp.perl.org/group/perl.perl6.language/2010/05/msg33671.html Thanks, Moritz
Fwd: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20) (nntp: message 1
--- Forwarded message --- From: nigelsande...@btconnect.com To: "Dave Whipp - dave_wh...@yahoo.com" <+nntp+browseruk+2dcf7cf254.dave_whipp#yahoo@spamgourmet.com>, "Dave Whipp - d...@whipp.name" <+nntp+browseruk+e66dbbe0cf.dave#whipp.n...@spamgourmet.com> Cc: Subject: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20) (nntp: message 1 of 20) Date: Tue, 18 May 2010 00:38:43 +0100 On Mon, 17 May 2010 23:25:07 +0100, Dave Whipp - dave_wh...@yahoo.com <+nntp+browseruk+2dcf7cf254.dave_whipp#yahoo@spamgourmet.com> wrote: Thanks for the clarification. However, I would point out that the whose purpose of CUDA is to define an abstraction (using terms like threads and warps) that expose the GPU "internal operations" to the applications programmer as somewhere between SIMD and MIMD (hence the term SIMT -- single instruction, multiple thread: CUDA programmers write single-threaded, non-vectorized, code that the compiler then scales up) Yeah! But that's just another example of stupid overloading of terminology confusing things. And that's not just my opinion. For example, see: http://www.anandtech.com/show/2556/5 "NVIDIA wanted us to push some ridiculous acronym for their SM's architecture: SIMT (single instruction multiple thread). First off, this is a confusing descriptor based on the normal understanding of instructions and threads. But more to the point, there already exists a programming model that nicely fits what NVIDIA and AMD are both actually doing in hardware: SPMD, or single program multiple data. This description is most often attached to distributed memory systems and large scale clusters, but it really is actually what is going on here." Also, if we assume that users will be writing their own operators, which will be auto-vectorized via hyper operators, then the idea that hyper's will seamlessly map to a SIMD core is probably somewhat optimistic. Well, I was talking about the obviously vectorizable operations: array addition, multiplication & scaling etc. But I agree with you, for anything more complex than simple SIMD operations, it is probably optimistic that the hyper-operators could successfully map them to GPGPU functionality transparently. But then we fall back to my earlier point that (certianly the more complex uses of) CUDA and OpenCL would require a (non-core) module. Essentially a thin wrapper around their APIs. I see three domains of threading: the passive parallelism of GPUs; the slight parallelism (ignoring ILP) of multicore; and the massive parallelism of cloud computing. Each of these domains has its own jargon that includes some concept of "thread". I know that it's hopelessly naive, but it would be nice if the basic Perl6 threading abstractions were applicable to all three (not because there's a common implementation, but because I wouldn't need to learn three different language dialects). I too find it unlikely that it would be possible to accommodate all those three into a single cohesive semantic view. Erlang's processes & messages view is perhaps the closest yet. But Erlang started life targeting relatively simple, single-core, single-tasking, embedded systems in telephone exchanges, where kernel-threading simply was not available. It's Raison d'être was IO-bound communications applications running on networks of simple processors. But the only way forward to sustain Moore's Law is cpu parallelism, and that required them to add kernel threading to achieve scale. They're just now beginning the process of working out how to manage the interactions of multiple concurrent user-space schedulers running under a kernel scheduler. I personally find CPU parallelism to be the least interesting of the three. Least interesting (to you) maybe, but it is now the most prevalent domain. And that will become more and more true in the immediate and foreseeable future. It is also the most relevant domain for the majority of the applications that are the natural target of dynamic languages. Developers of photo-realistic games, audio, video and image processing applications will continue to use compiled languages for the foreseeable future. It's possible to envisage that such things could be written in dynamic languages (at the top level), by utilising compiled modules to do the heavy lifting. But no matter how much interpreter performance improves, compiled-to-native code will always win on pure performance stakes. And with gaming technology, the more performance you have, the more realistic the game and the more you can do. And I see no sign of that topping out in favour of programmer efficiency any time soon. It's quite amazing what can be done in Java these days with HotSpot JIT, kernel threading, the vast improvements in GC algorithms and wait-free data structures, but that has taken them
Fwd: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20)
--- Forwarded message --- From: nigelsande...@btconnect.com To: "Dave Whipp - d...@whipp.name" <+nntp+browseruk+e66dbbe0cf.dave#whipp.n...@spamgourmet.com> Cc: Subject: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20) Date: Mon, 17 May 2010 22:31:45 +0100 On Mon, 17 May 2010 20:33:24 +0100, Dave Whipp - dave_wh...@yahoo.com <+nntp+browseruk+2dcf7cf254.dave_whipp#yahoo@spamgourmet.com> wrote: From that statement, you do not appear to understand the subject matter of this thread: Perl 6 concurrency model. Actually, the reason for my post was that I fear that I did understand the subject matter of the thread: seems to me that any reasonable discussion of "perl 6 concurrency" should not be too focused on pthreads-style threading. Okay. Now we're at cross-purposes about the heavily overloaded term "threading". Whilst GPUs overload the term "threading" for their internal operations, they are for the most part invisible to applications programmer. And quite different to the 100,000 threads demos in the Go and Erlang documentation to which I referred. The latter being MIMD algorithms, and significantly harder to find applications for than, SIMD algorithms which are commonplace and well understood. My uses of the terms "threading" and "threads" are limited specifically to MIMD threading of two forms: Kernel threading: pthreads, Win32/64 threads etc. User-space threading: green threads; coroutines; goroutines; Actors; etc. See below for why I've been limiting myself to these two definitions. OpenCL/Cuda are not exotic $M hardware: they are available (and performant) on any PC (or Mac) that is mainstream or above. Millions of threads is not a huge number: its one thread per pixel on a 720p video frame (and I see no reason, other than performance, not to use Perl6 for image processing). If the discussion is stricly limited abstracting remote procedure calls, then I'll back away. But the exclusion of modules that map hyper-operators (and feeds, etc.) to OpenCL from the generic concept of "perl6 concurrency" seems rather blinkered. FWIW, I absolutely agree with you that the mapping between Perl 6 hyper-operators and (GPU-based or otherwise) SIMD instructions is a natural fit. But, in your post above you said: "Pure SIMD (vectorization) is insufficient for many of these workloads: programmers really do need to think in terms of threads (most likely mapped to OpenCL or Cuda under the hood)." By which I took you to mean that in-box SIMD (be it x86/x64 CPU or GPU SIMD instruction sets) was "insufficient for many of the[se] workloads" you were considering. And therefore took you to be suggesting that the Perl 6 should also be catering for the heterogeneous aspects of OpenCL in core. I now realise that you were distinguishing between CPU SIMD instructions and GPU SIMD instructions. But the real point here is Perl 6 doesn't need a threading model to use and benefit from using GPU SIMD. Any bog-standard single-threaded process can benefit from using CUDA or the homogeneous aspect of OpenCL where available, for SIMD algorithms. Their use can be entirely transparent to the language semantics for built-in operations like the hyper-operators. Ideally, the Perl 6 runtime would implement roles for OpenCl or CUDA for hyper-operations; fall back to CPU SIMD instructions; ad fall back again to old-fashioned loops if neither where available. This would all be entirely transparent to the Perl 6 programmer, just as utilising discrete FPUs was transparent to the C programmer back in the day. In an ideal world, Perl 6.0.0.0.0 would ship with just the looping hyper-operator implementation; and it would be down to users loading in an appropriately named Role that matched the hardware's capabilities that would then get transparently picked up and used by the hyper-operations to give them CPU-SIMD or GPU-SIMD as available. Or perhaps these would become perl6 build-time configuration options. The discussion (which originally started outside of this list), was about MIMD threading--the two categories above--in order to utilise the multiple *C*PU cores that are now ubiquitous. For this Perl 6 does need to sort out a threading model. The guts of the discussion has been kernel threading (and mutable shared state) is necessary. The perception being that by using user-threading (on a single core at a time), you avoid the need for and complexities of locking and synchronisation. And one of the (I believe spurious) arguments for the use of user-space (MIMD) threading, is that they are lightweight which allows you to runs thousands of concurrent threads. And it does. I've done it with Erlang right here on my dirt-cheap Intel Core2 Quad Q6600 processor. But, no matter how hard you try, you can never push the CPU utilisation above 25%, because those 100,000 u
Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model
Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu:
> 3) The tough-y: Closed-over variables.
> These are tough because it exposes lexicals to sharing, but they are so
> natural to use, it is hard to suggest banning their use in concurrent
> routines.
This is the point I was trying to address, actually. Having *only*
explicitly shared variables makes it very cumbersome to write threaded
code, specially because explicitly shared variables have a lot of
restrictions on what they can be (this is from my experience in Perl 5
and SDL, which was what brought me to the message-passing idea).
> However, interpreters already have to detect closed over variables in
> order to 'lift' them and extend their lifetimes beyond their natural
> scope.
Actually, the interpreter might choose to to implement the closed-up
variables by keeping that entire associated scope when it is still
referenced by another value, i.e.:
{ my $a;
{ my $b = 1;
{ $a = sub { $b++ } } }
this would happen by the having every lexical scope holding a reference
to its outer scope, so when a scope in the middle exits, but some
coderef was returned keeping it as its lexical outer, the entire scope
would be kept.
This means two things:
1) the interpreter doesn't need to detect the closed over variables, so
even string eval'ed access to such variables would work (which is, imho,
a good thing)
2) all the values in that lexical scope are also preserved with the
closure, even if they won't be used (which is a bad thing).
> It doesn't seem it would be any harder to lift them to shared
> variable status, moving them out of the thread-local lexical pads and into
> the same data-space as process globals and explicitly shared data.
It is still possible to do the detection on the moment of the runtime
lookup, tho...
> My currently favoured mechanism for handling shared data, is via
> message-passing, but passing references to the shared data, rather than
> the data itself. This seems to give the reason-ability, compose-ability
> and controlled access of message passing whilst retaining the efficiency
> of direct, shared-state mutability.
That was part of my idea too, I wasn't trying to address remote
processes or anything like that, I was considering doing the queues in
shared memory for its efficiency.
> Only the code that declares the shared
> data, plus any other thread it choses to send a handle to, has any
> knowledge of, and therefore access to the shared state.
If we can overcome the limitations we have in Perl 5 shared values, I'm
entirely in agreement with the above statement (assuming closed-over
values become shared transparently)
> Effectively, allocating a shared entity returns a handle to the underlying
> state, and only the holder of that handle can access it. Such handles
> would be indirect references and only usable from the thread that creates
> them. When a handle is passed as a message to another thread, it is
> transformed into a handle usable by the recipient thread during the
> transfer and the old handle becomes invalid. Attempt to use an old handle
> after it has been sent result in a runtime exception.
This is exactly what I meant by RemoteValue, RemoteInvocation and
InvocationQueue in my original idea.
daniel
Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model
Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu: > Interoperability with Perl 5 and > is reference counting should not be a high priority in the decision making > process for defining the Perl 6 concurrency model. If we drop that requirement then we can simply go to the we-can-spawn-as-many-os-threads-as-we-want model.. daniel
Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model
On Tue, 18 May 2010 11:39:04 +0100, Daniel Ruoso wrote:
This is the point I was trying to address, actually. Having *only*
explicitly shared variables makes it very cumbersome to write threaded
code, specially because explicitly shared variables have a lot of
restrictions on what they can be (this is from my experience in Perl 5
and SDL, which was what brought me to the message-passing idea).
Well, do not base anything upon the restrictions and limitations of the
Perl 5 threads/shared modules. They are broken-by-design in so many ways
that they are not a good reference point. That particular
restriction--what a :shared var can and cannot hold--is in some cases just
an arbitrary restriction for no good reason that I can see.
For example: file handles cannot be assigned to :shared vars is totally
arbitrary. This can be demonstrated in two ways:
1) If you pass the fileno of the filehandle to a thread and have it dup(2)
a copy, then it can use it concurrently with the originating thread
without problems--subject to the obvious locking requirements.
2) I've previously hacked the sources to bypass this restrict by adding
SVt_PVGV to the switch in the following function:
SV *
Perl_sharedsv_find(pTHX_ SV *sv)
{
MAGIC *mg;
if (SvTYPE(sv) >= SVt_PVMG) {
switch(SvTYPE(sv)) {
case SVt_PVAV:
case SVt_PVHV:
case SVt_PVGV: // !!!
if ((mg = mg_find(sv, PERL_MAGIC_tied))
&& mg->mg_virtual == &sharedsv_array_vtbl) {
return ((SV *)mg->mg_ptr);
}
break;
default:
/* This should work for elements as well as they
* have scalar magic as well as their element magic
*/
if ((mg = mg_find(sv, PERL_MAGIC_shared_scalar))
&& mg->mg_virtual == &sharedsv_scalar_vtbl) {
return ((SV *)mg->mg_ptr);
}
break;
}
}
/* Just for tidyness of API also handle tie objects */
if (SvROK(sv) && sv_derived_from(sv, "threads::shared::tie")) {
return (S_sharedsv_from_obj(aTHX_ sv));
}
return (NULL);
}
And with that one change, sharing file/directory handles in Perl 5 became
possible and worked.
The problem is, GVs can hold far more than just those handles. And many of
the glob-modules utilise the other slots in a GV (array/hahs scalaer etc.)
for storing state and bless them as objects. At that point--when I tried
the change--the was a conflict between the blessing that Shared.XS uses to
make sharing working and any other type of blessing. The net result was
that whilst the change lifted the restriction upon simple globs, it still
didn't work with many of the most useful glob-based module--IO::Socket::*;
HTTP::Deamon; etc. I guess that now the sharing of blessed objects has
been mage possible, I shoudl try the hack again a see if it would allow
those blessed globs to work.
Anyway, the point is that the limitations and restrictions of the Perl5
implementation of the iThreads model, should not be considered as
fundamental problems with with the iThreads model itself. They aren't.
However, interpreters already have to detect closed over variables
in
order to 'lift' them and extend their lifetimes beyond their natural
scope.
Actually, the interpreter might choose to to implement the closed-up
variables by keeping that entire associated scope when it is still
referenced by another value, i.e.:
{ my $a;
{ my $b = 1;
{ $a = sub { $b++ } } }
this would happen by the having every lexical scope holding a reference
to its outer scope, so when a scope in the middle exits, but some
coderef was returned keeping it as its lexical outer, the entire scope
would be kept.
This means two things:
1) the interpreter doesn't need to detect the closed over variables, so
even string eval'ed access to such variables would work (which is, imho,
a good thing)
You'd have to explain further for me to understand why it is necessary to
keep whole scopes around:
- in order to make closures accessible from string-eval;
- and why that is desirable?
2) all the values in that lexical scope are also preserved with the
closure, even if they won't be used (which is a bad thing).
Please no! :)
This is essentially the biggest problem with the Perl 5 iThreads
implementation. It is the *need* (though I have serious doubts that it is
actually a need even for Perl 5), to CLONE entire scope stacks every time
you spawn a thread that makes them costly to use. Both because of the time
it takes to perform the clone at spawn time; and the memory used to keep
copies of all that stuff that simply isn't wanted; and in many cases isn't
even accessible. AFAIK going by what I can find about the history of
iThreads development, this was only done in Perl 5 in order to provide the
Windows fork emulation.
But as a predom
Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model
On Tue, 18 May 2010 11:41:08 +0100, Daniel Ruoso wrote: Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu: Interoperability with Perl 5 and is reference counting should not be a high priority in the decision making process for defining the Perl 6 concurrency model. If we drop that requirement then we can simply go to the we-can-spawn-as-many-os-threads-as-we-want model.. I do not see that as a requirement. But, I am painfully aware that I am playing catchup with all the various versions, flavours and colors of Perl6 interpreter. And more importantly, the significance of each of tehm. When I recently started following #perl6 I was blown away (and totally confused) by all the various flavours that the eval bot responded to. The funny thing is that I have a serious soft spot for the timelyness of reference couting "GC". And I recently came across a paper on a new RCGC that claimed to address the circular reference problem without resorting to weak references or other labour intensive mechanisms; nor a stop-the-world GC cycle. I scanned the paper and it was essentially a multi-pass "coloring" scheme, but achived better performaince than most by a) running locally (to scopes I think) so that it had far fewer arenas to scan. b) Using a invative coloring scheme that meant it was O(N) rather than the usual O(N * M) Most of it went over my head, (as is often the case with aademic papers), but it seems real. But I think that is a boat that has long sailed for Perl 6? daniel
Parrot 2.4.0 "Sulfur Crest"
"So there me was beating boulder into powder because me couldn't eat it, and magic ball land in lap. Naturally me think, "All right, free egg." because me stupid and me caveman. So me spent about three days humping and bust open with thigh bone so me could eat it good. Then magic ball shoot Oog with beam, and next thing me know me go out and invent wheel out of dinosaur brain. Magic dino wheel rolls for three short distance until me eat it. The point is, me get smarter. Soon me walk upright, me feather back dirty, matted hair into wings for style, and me stop to use bathroom as opposed to me just doing it as me walk. " -- Oog, Aqua Teen Hunger Force On behalf of the Parrot team, I'm proud to announce Parrot 2.4.0 "Sulfur Crest." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.4.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 2.4.0 News: - Core + Various long-standing bugs in IMCC were fixed + STRINGs are now immutable. + use STRINGNULL instead of NULL when working with strings + Fixed storage of methods in the NameSpace PMC + Added :nsentry flag to force method to be stored in the NameSpace + Added StringBuilder and PackfileDebug PMCs + Added experimental opcodes find_codepoint and unroll - Compilers + Fixed reporting of line numbers in IMCC + Removed deprecated NQP compiler, replaced with new NQP-RX + Removed NCIGen compiler - Deprecations + Tools to distribute on CPAN were removed + Deprecated dynpmcs have been removed to external repositories + Removed RetContinuation PMC + Removed CGoto, CGP, and Switch runcores - Tests + Many tests for the extend/embed interface were added + done_testing() is now implemented in Test::More - Tools + The fakexecutable tapir is renamed parrot-prove + Performance fixes to the pbc_to_exe tool + Fix data_json to work outside of trunk + The dynpmc GzipHandle (zlib wrapper) was added + The library Archive/Tar.pir was added. + The library Archive/Zip.pir was added. + The libraries LWP.pir, HTTP/Message.pir & URI.pir were added. - Miscellaneous + Six Parrot-related projects accepted to GSoC + Improve use of const and other compiler hints Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 15 June 2010. Enjoy! --Andrew Whitworth
Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model
Em Ter, 2010-05-18 às 15:15 +0100, nigelsande...@btconnect.com escreveu:
> > 1) the interpreter doesn't need to detect the closed over variables, so
> > even string eval'ed access to such variables would work (which is, imho,
> > a good thing)
> You'd have to explain further for me to understand why it is necessary to
> keep whole scopes around:
> - in order to make closures accessible from string-eval;
> - and why that is desirable?
I have no strong opinion on that, actually... Pointing to the outer
scope was simply an easy way to have it working...
But this is currently, iirc, a requirement for the language, and
supported by rakudo and pugs...
perl6: my $a; { my $b = 1; $a = sub { return eval '$b++' } };
say $a.(); say $a.(); say $a.();
..pugs, rakudo 689429: OUTPUT«123»
> > 2) all the values in that lexical scope are also preserved with the
> > closure, even if they won't be used (which is a bad thing).
> Please no! :)
> This is essentially the biggest problem with the Perl 5 iThreads
> implementation. It is the *need* (though I have serious doubts that it is
> actually a need even for Perl 5), to CLONE entire scope stacks every time
> you spawn a thread that makes them costly to use.
hmmm... I wasn't expecting to clone the entire scope stack, but rather
to ask the owner of the outer scope for a value...
But I have to admit that importing the symbols used from outer scopes to
the current scope and making them shared (or a RemoteValue in my
original idea) is probably prettier. Accessing the OUTER scope in
run-time (via string eval, OUTER::{$var} or CALLER::{$var}) could be
subject to additional restrictions.
daniel
Re: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20)
On Tue, May 18, 2010 at 3:19 AM, wrote: > The guts of the discussion has been kernel threading (and mutable shared > state) is necessary. The perception being that by using user-threading (on > a single core at a time), you avoid the need for and complexities of > locking and synchronisation. And one of the (I believe spurious) arguments > for the use of user-space (MIMD) threading, is that they are lightweight > which allows you to runs thousands of concurrent threads. > > And it does. I've done it with Erlang right here on my dirt-cheap Intel > Core2 Quad Q6600 processor. But, no matter how hard you try, you can never > push the CPU utilisation above 25%, because those 100,000 user-threads all > run in a single kernel-thread. And that means I waste 75% of my processing > power. And next year (or maybe the spring after), when the lowest spec > Magny-Cours 12-core processor systems have fallen to my 'dirt-cheap' price > point, I'd be wasting 92% of my processing power. > > And for those geneticists and engineers trying to use Perl 6 on their > relatively cheap 48-core boxes to chug through their inherently MIMD > algorithms, they'd be wasting 98% of their CPU power if Perl 6 does not > provide for a threading model that scales across multiple cores. > > I hope that gives some context to a) my misunderstanding of your post; b) > my continued advocacy that kernel threading has to underpin Perl 6's > threading model. > > Java has has user-space threading (green threads) for years; and it was an > ongoing nightmare until they adopted kernels threads in Java 1.5. > Erlang has had user-space threading (coroutines) for years; but they've > had to add kernel threading in the last couple of versions in order to > scale. > IO has had coroutines; but has now added kernel threading in order to > scale. You are imposing a false dichotomy here. Neither 'green' threads nor kernel threads preclude each other. In fact, it can be convincingly argued that they work _best_ when combined. Please look at the GSoC proposal for hybrid threading on the Parrot list.
Re: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20)
Em Ter, 2010-05-18 às 12:58 -0700, Alex Elsayed escreveu: > You are imposing a false dichotomy here. Neither 'green' threads nor kernel > threads preclude each other. In fact, it can be convincingly argued that they > work _best_ when combined. Please look at the GSoC proposal for hybrid > threading on the Parrot list. While I agree that there isn't a dichotomy, the point here is more in the lines of: 1) Green threads are usually related to the requirement of serialized access to data so you can share all data in the thread without resorting to locks for every value. 2) If that requirement is dropped, once only data that is explicitly marked as shared can be seen by both threads, the point for green threads is moot, since the OS threads are always going to be better performant then a manually implemented scheduler. My original idea was pointing in creating a "shared memory space" that would be seen by every green thread in the same os thread, where some lines would be drawn to allow OS threading with different memory spaces - message passing would be used to communicate between two different "memory spaces". But what we might be getting here is at the point where we don't need green threads at all... I'm still not sure about one point or another, tho.. daniel
