On Sunday, 19 June 2016 at 06:28:45 UTC, deadalnix wrote:
> On Sunday, 19 June 2016 at 05:37:01 UTC, Walter Bright wrote:
>> On 6/18/2016 10:22 PM, Suliman wrote:
>>>> 8. create a greenthreads module that works like Goroutines
>>>
>>> But we already have fibers, I thought that they are same with Goroutines
>>>
>>
>> Fibers are thread local. Goroutines are distributed among fibers and threads, and can switch from one thread to another.
>
> Alright. What is the goal here ?
>
> First, Fiber are doing some synchronized work. This must go. They can't be exchanged across thread safely so this is only make performance worse without any benefit.
>
> Second, while go move goroutine from one thread to another, the go scheduler goes to great length to avoid doing it. There is all kind of bad side effects coming from this and you don't want them. HHVM does not move requests from one thread to another.
>
> It is to be noted that go to not provide any control over scheduling, while D does, doesn't have thread local storage and the type system doesn't provide any sharing constraints.
>
> This is important because we do. If we want to make that work, there are implications. First, it become impossible to cache the TLS segment address across function calls as any function call can mean the thread has changed. Even with that deoptimization (that all code will need to pay, not only the code using these goroutines) that means the type system is now completely broken. Any goroutine can take the address of a thread local, store it on the stack and voila, it is now shared across threads. So that means you need in addition DIP30 or something alike to make sure that the only things passed to the goroutine is shared. In addition, you want to make sure these do not touch the TLS, so you either need some kind of new attribute, like pure_tls, or just make them pure altogether (which would reduce their utility greatly).
>
> TL;DR : It sucks, there are all kind of bad side effects. The only reason go does it, is because they goroutine everything and can only have an adaptive strategy as this is done in the runtime.
>
> Now on the rant. We don't need more stuff. We have plenty of stuff. We have plenty of unfinished stuff and this is what we should focus on. We have plenty of stuff that try to be 2 things at once and does both badly. We don't need anymore of this.
>
> Just remove all synchronization from fiber and be done with it.

I agree. BTW, what do you think about improving the compiler's understanding of Fibers (AFAIU they're purely a runtime thing), so e.g. they're usable at CTFE. See this for more details:

http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html

On Sunday, 19 June 2016 at 01:01:30 UTC, Nicholas Wilson wrote:
> On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:
>> 9. create a module that enables code to be run on GPUs (John Colvin is doing work on this, ask him how to help!)
>
> Now that I'm on my (southern hemisphere) winter break I will be working on getting LDC to emit PTX and SPRIV and if I get time whatever metal uses to be able to use D as the source language for CUDA, OpenCL and Metal respectively. This should hopefully enable seamless integration with the use of introspection and whatnot.
>
> This would give us a huge advantage, being able to target the three major compute APIs.

This would be awesome. I would love to get my hands on prototypes of this, no matter how buggy and unfinished they are at any given point.

On Sunday, 19 June 2016 at 06:37:03 UTC, ZombineDev wrote:
> I agree. BTW, what do you think about improving the compiler's understanding of Fibers (AFAIU they're purely a runtime thing), so e.g. they're usable at CTFE. See this for more details:
>
> http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html

I saw that but I'm unclear what is the cost benefit at this point. Which is an elaborate way to say I don't know.

On Sunday, 19 June 2016 at 06:28:45 UTC, deadalnix wrote:
> On Sunday, 19 June 2016 at 05:37:01 UTC, Walter Bright wrote:
>> On 6/18/2016 10:22 PM, Suliman wrote:
>>>> 8. create a greenthreads module that works like Goroutines
>>>
>>> But we already have fibers, I thought that they are same with Goroutines
>>>
>>
>> Fibers are thread local. Goroutines are distributed among fibers and threads, and can switch from one thread to another.
>
> Alright. What is the goal here ?

Do people really want the threads? You don't get them with gccgo either, do you?

Isn't the common request more about the channels Go provides?

On Sunday, 19 June 2016 at 09:50:42 UTC, John Colvin wrote:
> On Sunday, 19 June 2016 at 01:01:30 UTC, Nicholas Wilson wrote:
>> On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:
>>> [...]
>>
>> Now that I'm on my (southern hemisphere) winter break I will be working on getting LDC to emit PTX and SPRIV and if I get time whatever metal uses to be able to use D as the source language for CUDA, OpenCL and Metal respectively. This should hopefully enable seamless integration with the use of introspection and whatnot.
>>
>> This would give us a huge advantage, being able to target the three major compute APIs.
>
> This would be awesome. I would love to get my hands on prototypes of this, no matter how buggy and unfinished they are at any given point.

Glad you're enthusiastic! I've made a new thread in general about this. All testing appreciated.

On Sunday, 19 June 2016 at 06:19:34 UTC, Dicebot wrote:
>
> Which is inherently suboptimal and is a part of Go marketing bullshit not worth spending time on. It also requires heavy runtime modifications (because TLS) unless one wants to totally screw plain fibers.
>
> Proper action item instead would be providing standard event loop and task system in Phobos.

I'm really not much of a fibers user, but I have read a bit on how Chapel handles parallelism and found that very interesting.

On Sunday, 19 June 2016 at 13:32:02 UTC, jmh530 wrote:
> On Sunday, 19 June 2016 at 06:19:34 UTC, Dicebot wrote:
>>
>> Which is inherently suboptimal and is a part of Go marketing bullshit not worth spending time on. It also requires heavy runtime modifications (because TLS) unless one wants to totally screw plain fibers.
>>
>> Proper action item instead would be providing standard event loop and task system in Phobos.
>
> I'm really not much of a fibers user, but I have read a bit on how Chapel handles parallelism and found that very interesting.

Fibers are more of a concurrency than a parallelism tool. Do you have a link to relevant Chapel description? I am not familiar with it.

On Sunday, 19 June 2016 at 15:40:09 UTC, Dicebot wrote:
> On Sunday, 19 June 2016 at 13:32:02 UTC, jmh530 wrote:
>> On Sunday, 19 June 2016 at 06:19:34 UTC, Dicebot wrote:
>>>
>>> Which is inherently suboptimal and is a part of Go marketing bullshit not worth spending time on. It also requires heavy runtime modifications (because TLS) unless one wants to totally screw plain fibers.
>>>
>>> Proper action item instead would be providing standard event loop and task system in Phobos.
>>
>> I'm really not much of a fibers user, but I have read a bit on how Chapel handles parallelism and found that very interesting.
>
> Fibers are more of a concurrency than a parallelism tool. Do you have a link to relevant Chapel description? I am not familiar with it.

Just found this, although there's probably other material out there:

http://chapel.cray.com/tutorials/SC10/M10-4-TaskPar.pdf

Lodovico Giaretta

On Sunday, 19 June 2016 at 16:21:36 UTC, Lodovico Giaretta wrote:
>>
>> Fibers are more of a concurrency than a parallelism tool. Do you have a link to relevant Chapel description? I am not familiar with it.
>
> Just found this, although there's probably other material out there:
>
> http://chapel.cray.com/tutorials/SC10/M10-4-TaskPar.pdf
>
> Lodovico Giaretta

Thanks, that would be what I would have directed him to. They kind of use task parallelism in a way similar to concurrency. There is more here
http://chapel.cray.com/docs/latest/users-guide/taskpar/taskParallelismOverview.html
as well as in the language spec
http://chapel.cray.com/docs/latest/language/spec.html

On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:

> 6. replace std.xml with something we can be proud of that is second to none in performance (Robert burner Schadek is mentoring on this https://github.com/lodo1995/experimental.xml)

I hope it will support html and xpath too.

Andrea