Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Learning Perl 6

evanmiller.org

Post reply on HN
Print view View original

141–150 of 380 posts

Re: Why I’m Learning Perl 6

#141

Post by smitherfield »

kbenson wrote: post #127
joosters wrote: post #103

Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. The OS is designed to sche…

> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") thread…

Edit: I mistakenly read "OS-level threads" again where s/he said "application level threads" in the quote.

> For others, application level threads don't achieve the parallelism requires to efficiently use the hardware available.

You've got this backwards: OS-level threads execute in parallel (or, rather, may be executed in parallel), while green threads spawned within the same OS-level thread execute sequentially on a single processor core (but in no predetermined order).

Re: Why I’m Learning Perl 6

#142

Post by kbenson »

joosters wrote: post #134
kbenson wrote: post #130

Earlier quoted context omitted.

You just described M:N threading, and what's being touted in this article as good about Perl 6.

Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.

I was referring two your second paragraph but had missed your reference to the OP, which makes it obvious what you are trying to say.

Re: Why I’m Learning Perl 6

#143

Post by gjm11 »

bloobloobloo wrote: post #133
Rjevski wrote: post #28

My personal issue with Perl is how much of a mess the syntax is (10 different ways of doing the same thing), and the lack of a standard library (CPAN is not a viable replacement).

> 10 different ways of doing the same thing Mostly an urban myth. Where it isn't, at least 8 of those ways are actually important. Exercise: write a python program that prints Python's quoting documentation, without external files, without editing the documentation. Spoiler alert: it's impossible.

I'm not sure I understand your exercise. What do you mean by "Python's quoting documentation", and what do you mean by "editing" it?

Re: Why I’m Learning Perl 6

#144

Post by weberc2 »

pjmlp wrote: post #123
weberc2 wrote: post #113

Earlier quoted context omitted.

Have Jython and IronPython reached compatibility with Python 3 yet? Last I checked they hadn't, or it was still in alpha.

I don't know, but Python 3 still isn't relevant to many people. For example, I have to explicitly install 2.7 to be able to use Cocos2d-x build scripts.

Maybe, but it seems like a bad idea to invest in Python 2 (which is teaching is ended of life) just to get parallelism when there are other programming languages that have great concurrency stories and a bright future. That said, if PyPy3 ditches the GIL, let me know!

Re: Why I’m Learning Perl 6

#145

Post by krylon »

krylon wrote: post #18

Can anyone recommend a good book on Perl 6? Are there any (even bad ones)? Right now I feel the major reason that keeps me from investing time in Perl 6 - besides adoption by distros - is the lack of a good book, like the Lama and the Camel book for Perl 5. It's kind of frustrating after having waited so long.

To all who answered: Thank you very, very much!!!

Re: Why I’m Learning Perl 6

#146

Post by hashkb »

simias wrote: post #135
dragonwriter wrote: post #70

Earlier quoted context omitted.

> Every major language, or at least the ones that matter for backend development, has support for thread multiplexing / coroutines / fibers, whatever. M:N threading is not, from a developer perspective, the same thing as coroutines/fibers. Coroutines are lower-level; it's possible to build something like M:N threading on top of coroutines, but it means doing a lot of work that's already done for you in a language tha…

That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly. If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.

Author demonstrates exactly what is meant with code exam in the article

Re: Why I’m Learning Perl 6

#147

Post by cchase88 »

le-mark wrote: post #101
totalperspectiv wrote: post #68

Earlier quoted context omitted.

I hadn't heard of Tcl before but it looks awesome! What do you find its ideal use cases to be?

TCL is pretty old school and doesn't get a lot of attention nowadays. The main use I'm aware of is in BigIP F5 config files. There are some really interesting things about it though, for example how control flow constructs (if/else, while) are implemented as commands, using built in uplevel and upvar [1] commands to control the scope of the currently executing code. Some people say it's lisp-like, that's one of the t…

I wrote a blog post where I show how to define "until" using Uplevel: http://christopherchase.cc/posts/tcl-until.html

Re: Why I’m Learning Perl 6

#148

Post by gpderetta »

kbenson wrote: post #127
joosters wrote: post #103

Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. The OS is designed to sche…

> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") thread…

>> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. >That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") threads, and schedule them on N actual threads.

More or less. I would say that manually threading continuations through async calls doesn't count as M:N. Not even when done via semi-automatically via the stack-less coroutines which are popular on recent languages as they are a very leaky abstraction.

I would even argue that a proper M:N system should have, if not full preemption, at least a best effort attempt at guaranteeing forward progress by implicit insertion of yields.

Re: Why I’m Learning Perl 6

#149

Post by raiph »

joosters wrote: post #134
kbenson wrote: post #130

Earlier quoted context omitted.

You just described M:N threading, and what's being touted in this article as good about Perl 6.

Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.

i.e. SIMD i.e. something like:

    @array = 1, 2 ... 1,000,000 ;
    @array>>++ ;
where the `>>++` operation increments each of a million integers with the workload distributed across multiple real CPUs?

Re: Why I’m Learning Perl 6

#150

Post by kbenson »

smitherfield wrote: post #141
kbenson wrote: post #127

Earlier quoted context omitted.

> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") thread…

Edit: I mistakenly read "OS-level threads" again where s/he said "application level threads" in the quote. > For others, application level threads don't achieve the parallelism requires to efficiently use the hardware available. You've got this backwards: OS-level threads execute in parallel (or, rather, may be executed in parallel), while green threads spawned within the same OS-level thread execute sequentially on…

I think you missed where I linked "application" threads to "green" threads, as opposed to OS level threads.
Post reply on HN