On Friday, 11 December 2015 at 09:28:03 UTC, deadalnix wrote:
No, I just like you to explain me how to serve web request at
scale, because I have zero clue how that works.
Only well behaved kids get presents for xmas.
On Thu, 2015-12-10 at 20:17 +, Ola Fosheim Grøstad via Digitalmars-
d wrote:
[…]
>
> Go has a more advanced, memory efficient and secure runtime than
> D fibers. So when calling C Go has to do extra work. E.g. Ensure
> that the stack is large enough for C etc.
Goroutines are great. They ar
On Friday, 11 December 2015 at 05:05:29 UTC, Chris Wright wrote:
1. Kill caches and TLB
Which only affects efficiency, not correctness.
That's true, but when you have fibers or coroutines as a
paradigm, you do it because it is a convenient way of preserving
statefulness. So you want to be a
On Friday, 11 December 2015 at 09:10:42 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 11 December 2015 at 06:36:47 UTC, deadalnix wrote:
Yeah tell me more about having web servers with many
persistent connections, I don't have the opportunity to see to
many of these t work.
There is a point in t
On Friday, 11 December 2015 at 06:36:47 UTC, deadalnix wrote:
Yeah tell me more about having web servers with many persistent
connections, I don't have the opportunity to see to many of
these t work.
There is a point in this statement?
On Friday, 11 December 2015 at 02:08:27 UTC, Ola Fosheim Gr wrote:
On Friday, 11 December 2015 at 01:43:12 UTC, deadalnix wrote:
I mean, yes, if you run tens of thousand of fibers maybe
you'll experience that, but that doesn't sound like a very
smart plan to boot.
If you cannot spin up fibers
On Fri, 11 Dec 2015 01:43:12 +, deadalnix wrote:
> Benchmark needed. It not like the stack is randomly accessed, so I don't
> think the TLB argument makes a lot of sense.
The TLB issue is about the pattern of memory access, and that's got a lot
more to do with the user's code than with the s
On Fri, 11 Dec 2015 01:25:24 +, Ola Fosheim Gr wrote:
> it does not work for 64 bit either. You will:
>
> 1. Kill caches and TLB
Which only affects efficiency, not correctness. And that's only for
people who want to use as much as a gigabyte of stack space for every
fiber.
Since the TLB is
On Friday, 11 December 2015 at 01:43:12 UTC, deadalnix wrote:
I mean, yes, if you run tens of thousand of fibers maybe you'll
experience that, but that doesn't sound like a very smart plan
to boot.
If you cannot spin up fibers in the thousands, then it is very
limited. If you cannot have freq
On Friday, 11 December 2015 at 01:25:24 UTC, Ola Fosheim Gr wrote:
On Thursday, 10 December 2015 at 23:25:42 UTC, Chris Wright
wrote:
This doesn't work well for 32-bit processes because, while it
doesn't demand memory up front, it does demand address space.
But lazily demanding pages from the O
On Thursday, 10 December 2015 at 23:25:42 UTC, Chris Wright wrote:
This doesn't work well for 32-bit processes because, while it
doesn't demand memory up front, it does demand address space.
But lazily demanding pages from the OS doesn't help. You still
have to divide the address space among fi
On Thu, 10 Dec 2015 20:17:57 +, Ola Fosheim Grøstad wrote:
> But the D fiber stacks aren't managed/safe, so in D the programmer is
> responsible for allocating a stack that is large enough. And that is
> neither safe or scalable.
Try it out!
---
import core.thread;
import std.stdio;
void m
On Thursday, 10 December 2015 at 19:46:44 UTC, Ali Çehreli wrote:
However, Mike Parker's book "Learning D" has more than 50 pages
on "Connecting D with C":
Well now I need to buy that!
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
I read this post about the difficulties of using go/cgo to
interface with C code:
http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
How does D do in comparison? specifically in regards to:
1. Call overhead (CG
On Thursday, 10 December 2015 at 16:37:16 UTC, Chris Wright wrote:
From what you're saying about Go, it sounds like someone
implemented the C calling convention at runtime.
Go has a more advanced, memory efficient and secure runtime than
D fibers. So when calling C Go has to do extra work. E.g
On 12/10/2015 09:24 AM, jmh530 wrote:
> On Thursday, 10 December 2015 at 17:16:43 UTC, Gary Willoughby wrote:
>>
>> Some reading:
>>
>> https://dlang.org/spec/interfaceToC.html
>> http://wiki.dlang.org/D_binding_for_C
>
> I can't recall if Ali's book has a section on this, but I'm not a fan of
> t
On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer
wrote:
To add to this, as long as you're on anything but OS X, you're
fine. Debugging D on OS X is, to put it plainly, fucked.
I have some good thing coming out of lldb. Far from perfect, but
usable.
On Thursday, 10 December 2015 at 17:16:43 UTC, Gary Willoughby
wrote:
Some reading:
https://dlang.org/spec/interfaceToC.html
http://wiki.dlang.org/D_binding_for_C
I can't recall if Ali's book has a section on this, but I'm not a
fan of those links.
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
I read this post about the difficulties of using go/cgo to
interface with C code:
http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
How does D do in comparison? specifically in regards to:
1. Call overhead (CG
On Thu, 10 Dec 2015 13:33:07 +, Pradeep Gowda wrote:
> I read this post about the difficulties of using go/cgo to interface
> with C code:
> http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
>
> How does D do in comparison? specifically in regards to:
>
> 1. Call overhead (CG
On Thursday, 10 December 2015 at 15:29:46 UTC, Jack Stouffer
wrote:
On Thursday, 10 December 2015 at 15:18:18 UTC, John Colvin
wrote:
On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer
wrote:
On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin
wrote:
On Thursday, 10 December 20
On Thursday, 10 December 2015 at 15:18:18 UTC, John Colvin wrote:
On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer
wrote:
On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin
wrote:
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
5. Debugging (ease of acce
On Thursday, 10 December 2015 at 14:57:33 UTC, Jack Stouffer
wrote:
On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin
wrote:
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
5. Debugging (ease of accessing C parts when debugging)
5) Trivial. From the debuggers perspe
On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
5. Debugging (ease of accessing C parts when debugging)
5) Trivial. From the debuggers perspective it's all just
functions, you might not even notice the languag
On Thursday, 10 December 2015 at 13:52:57 UTC, John Colvin wrote:
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
2. Memory management. (I guess D is not immune from having to
manage memory for the C functions it calls.. but is there a
difference in approach? is it safer i
On Thursday, 10 December 2015 at 13:33:07 UTC, Pradeep Gowda
wrote:
I read this post about the difficulties of using go/cgo to
interface with C code:
http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
How does D do in comparison? specifically in regards to:
1. Call overhead (CG
I read this post about the difficulties of using go/cgo to
interface with C code:
http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
How does D do in comparison? specifically in regards to:
1. Call overhead (CGo is 100 times slower than native Go fn call)
2. Memory management. (
27 matches
Mail list logo
