Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 21:52:22 UTC, Jonathan M Davis wrote: On Wednesday, December 07, 2016 15:17:21 Picaud Vincent via Digitalmars-d- learn wrote: That being said, if someone wants to make their life harder by insisting on using D without even druntime, then that's their choice. I think that it's an unnecessarily extreme approach even for really performance-centric code, but they're free to do what they want. It's not only a performance issue. Sometimes, your target platform simply doesn't have the runtime nor Phobos: Emscripten (asmjs), kernel mode code or bare metal embedded stuff. I'm using D without druntime for my D-to-asmjs project. Avoid druntime certainly makes my life harder, but it makes the whole project possible.
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 02:10:35 UTC, Jon Degenhardt wrote: A cycle I think is common is for a researcher (industry or academic) to write functionality in native R code, then when trying to scale it, finds native R code is too slow, and switches to C/C++ to create a library used in R. C/C++ is chosen not because it the preferred choice, but because it is the common choice. In such situations, the performance need is often to be quite a bit faster than native R code, not that it reach zero overhead. My personal opinion, but I do think D would be a very good choice here, run-time, phobos, gc, etc., included. The larger barrier to entry is more about ease of getting started, community (are others using this approach), etc., and less about having the absolutely most optimal performance. (There are obviously areas where the most optimal performance is critical, Mir seems to be targeting a number of them.) Rcpp is the most common dependency for R packages on CRAN. (I actually contributed an example that Dirk went on to use quite often, including his book.[1]) That motivated me to do something similar for D.[2] I have created other packages, though they have less documentation.[3] It will be important to keep the technical requirements low if others are going to adopt D. I use the R package manager for everything, because Dub would require them to learn something that they'd view as weird. And having to understand memory management, as with Rust, would definitely not work. To this point I have focused on adding functionality and ease of installation so as to get my coauthors to use it. Mir is a wonderful project, but those advanced developers are not the ones that would embed D inside an R program, and they would definitely not feel comfortable with the things a statistician/econometrician expects. [1] http://dirk.eddelbuettel.com/blog/2011/04/23/ [2] https://bitbucket.org/bachmeil/embedr [3] For example, https://bitbucket.org/bachmeil/dmdgretl, https://bitbucket.org/bachmeil/dmdquadprog, https://bitbucket.org/bachmeil/dmdoptim
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 16:33:03 UTC, bachmeier wrote: On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko wrote: R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. --Ilya You can call into those same C libs using D. Only if you want a pure D solution do you need to be able to rewrite those libraries and get the same performance. D is a fine solution for the academic or the working statistician that is doing day-to-day analysis. The GC and runtime are not going to be an obstacle for most of them (and most won't even know anything about them). A cycle I think is common is for a researcher (industry or academic) to write functionality in native R code, then when trying to scale it, finds native R code is too slow, and switches to C/C++ to create a library used in R. C/C++ is chosen not because it the preferred choice, but because it is the common choice. In such situations, the performance need is often to be quite a bit faster than native R code, not that it reach zero overhead. My personal opinion, but I do think D would be a very good choice here, run-time, phobos, gc, etc., included. The larger barrier to entry is more about ease of getting started, community (are others using this approach), etc., and less about having the absolutely most optimal performance. (There are obviously areas where the most optimal performance is critical, Mir seems to be targeting a number of them.) For D to compete directly with R, Python, Julia, in these communities then some additional capabilities are probably needed, like a repl, standard scientific packages, etc.
Re: Multiple producer - multiple consumer with std.concurrency?
On 12/07/2016 12:08 PM, Christian Köstlin wrote: > I really like std.concurrency for message passing style coding. > > Today I thought about a scenario where I need a multiple producer, > multiple consumer pattern. > The multiple producer is easily covered by std.concurrency, because > all producers just can send to one Tid. > The tricky part is the multiple consumer part. At the moment I do not > see a way for several Tid's to share the same mailbox. Did I miss > something, or how would you implement this paradigm? > > thanks in advance, > christian > The simplest idea is to have a single dispatcher thread that distributes to consumers. However, both that and other shared mailbox designs are inherently slow due to contention on this single mailbox. Sean Parent's "Better Code: Concurrency" presentation does talk about that topic and tells how "task stealing" is a solution. There are other concurrency models out there like the Disruptor: https://lmax-exchange.github.io/disruptor/ It's a very interesting read but I don't know how it can be done with Phobos. It would be awesome if D had that solution. Ali
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, December 07, 2016 15:17:21 Picaud Vincent via Digitalmars-d- learn wrote: > However I think that to popularize/attract people to use D, it is > very important, to have a mechanism/feature that allows you to be > close to the "zero overhead" situation. You can do that without throwing away all of druntime and Phobos. You just don't use the stuff with the overhead that you can't afford - e.g. if you can't afford the GC, then don't use it. @nogc guarantees that for you. And if you can't afford exceptions, then nothrow does that for you. IMHO, if you ditch druntime and Phobos over GC concerns, you're throwing the baby out with the bath water. Without druntime, you don't even get assertions or unit tests or static constructors or array bounds checking or... I just can't agree that throwing out druntime makes sense even in most really performance-critical environments. Certain features would need to be avoided, but it doesn't require throwing everything out. That being said, if someone wants to make their life harder by insisting on using D without even druntime, then that's their choice. I think that it's an unnecessarily extreme approach even for really performance-centric code, but they're free to do what they want. - Jonathan M Davis
wrong result from ParameterStorageClassTuple?
alias PSC = ParameterStorageClass;
alias PSCT = ParameterStorageClassTuple;
void fun1(return ref int){}
void fun2(return out int){}
PSCT!fun1 == (PSC.return_ | PSC.ref_) // false
PSCT!fun2 == (PSC.return_ | PSC.out_) // false
PSCT!fun1 == PSC.return_ // true
PSCT!fun2 == PSC.return_ // true
how to differentiate them?
Multiple producer - multiple consumer with std.concurrency?
I really like std.concurrency for message passing style coding. Today I thought about a scenario where I need a multiple producer, multiple consumer pattern. The multiple producer is easily covered by std.concurrency, because all producers just can send to one Tid. The tricky part is the multiple consumer part. At the moment I do not see a way for several Tid's to share the same mailbox. Did I miss something, or how would you implement this paradigm? thanks in advance, christian
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 17:32:14 UTC, Alex wrote: enum hasRun(T) = __traits(hasMember, T, "run"); This is strange... I expect this to work... but it does not... hasRun there ONLY takes types, whereas T... can take types, values, aliases, etc. Try making it hasRun(T...) and it will probably work, though really, I'd say just use the helper function...
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 17:05:11 UTC, H. S. Teoh wrote:
Try this:
import std.meta : allSatisfy;
enum hasRun(T) = __traits(hasMember, T, "run");
mixin template S(T...)
if (allSatisfy!(hasRun, T))
{
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
}
This is strange... I expect this to work... but it does not...
meta.d(762,27): Error: template instance F!(rFS) does not match
template declaration hasRun(T)
meta.d(767,13): Error: template instance
std.meta.allSatisfy!(hasRun, rFS) error instantiating
test176.d(70,27): instantiated from here: allSatisfy!(hasRun,
rFS, rAS)
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 17:08:09 UTC, Gary Willoughby
wrote:
Will some like this work?
import std.range.primitives;
mixin template S(T...) if(__traits(hasMember,
ElementType!(T), "run"))
{
...
}
https://dlang.org/phobos/std_range_primitives.html#ElementType
Nope:
template instance ElementType!(rFS, rAS) does not match template
declaration ElementType(R)
Re: constraint on variadic template
On Wed, Dec 07, 2016 at 04:35:52PM +, Alex via Digitalmars-d-learn wrote:
> Hi people,
> have searched the history, but didn't find something similar:
>
> say I have a template like
>
> mixin template S(T...)
> {
> void run()
> {
> foreach(s; T)
> {
> static assert(__traits(hasMember, s, "run"));
> }
> }
> }
>
> How to formulate the check inside the foreach as a template constraint with
> mixin template S(T...) if(???)
[...]
Try this:
import std.meta : allSatisfy;
enum hasRun(T) = __traits(hasMember, T, "run");
mixin template S(T...)
if (allSatisfy!(hasRun, T))
{
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
}
T
--
The richest man is not he who has the most, but he who needs the least.
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 16:35:52 UTC, Alex wrote:
mixin template S(T...)
{
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
}
How to formulate the check inside the foreach as a template
constraint with
mixin template S(T...) if(???)
Will some like this work?
import std.range.primitives;
mixin template S(T...) if(__traits(hasMember,
ElementType!(T), "run"))
{
...
}
https://dlang.org/phobos/std_range_primitives.html#ElementType
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 16:48:08 UTC, Adam D. Ruppe
wrote:
On Wednesday, 7 December 2016 at 16:35:52 UTC, Alex wrote:
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
Just put that in a function:
bool test(T...)() {
foreach(s; T)
if(!__traits(hasMember, s, "run"))
return false;
return true;
}
and use that as the constraint:
S(T...) if (test!T()) {}
Ah! An own constraint... Thanks! :)
Re: constraint on variadic template
On Wednesday, 7 December 2016 at 16:35:52 UTC, Alex wrote:
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
Just put that in a function:
bool test(T...)() {
foreach(s; T)
if(!__traits(hasMember, s, "run"))
return false;
return true;
}
and use that as the constraint:
S(T...) if (test!T()) {}
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote: I don't understand this discussion at all. Why not have both? I don't need bare metal stuff at the moment but I might one day, and I perfectly understand that people may need it. At the same time, there are people who are happy with runtime/Phobos/GC. In my opinion it's not a question of "either or" but of "both and". I can only speak for myself, but the concern is that we'll move in the direction of Rust, where you're supposed to read a dissertation on memory management before writing "Hello, World". The current state of affairs should be the default. Those with more advanced uses in mind should be able to do what they need, but it should be done without pushing away non-hard core developers.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote: I don't understand this discussion at all. Why not have both? I don't need bare metal stuff at the moment but I might one day, and I perfectly understand that people may need it. At the same time, there are people who are happy with runtime/Phobos/GC. In my opinion it's not a question of "either or" but of "both and". Yes, I do agree, that is not exclusive. I only said that IMHO it would be very useful to have a clear "mechanism" (pragma, compiler flags...) to generate code close to what can be done with C. The goal being to have appealing (= fast & low memory footprint) libraries to attract people. That said, D with all its features GC, ... is great, but maybe that is not the feature that catches potential user attention the most. -- Vincent
constraint on variadic template
Hi people,
have searched the history, but didn't find something similar:
say I have a template like
mixin template S(T...)
{
void run()
{
foreach(s; T)
{
static assert(__traits(hasMember, s, "run"));
}
}
}
How to formulate the check inside the foreach as a template
constraint with
mixin template S(T...) if(???)
have tried so far:
mixin template S(T...) if(__traits(hasMember, T, "run"))
but the compiler complies about
Error: expected 2 arguments for hasMember but had 3
which says to me, that the input is not taken value by value, but
all values as entirety.
tried:
if(T.each!(s => __traits(hasMember, s, "run")))
but it complies about
cannot deduce function from argument types !()(void, void)
which is ok, as the the provided types are templates by
themselves.
The formulation at the beginning works, but the intention is a
little bit different.
Thanks in advance
Alex
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko wrote: R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. --Ilya You can call into those same C libs using D. Only if you want a pure D solution do you need to be able to rewrite those libraries and get the same performance. D is a fine solution for the academic or the working statistician that is doing day-to-day analysis. The GC and runtime are not going to be an obstacle for most of them (and most won't even know anything about them).
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 15:17:21 UTC, Picaud Vincent wrote: On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote: [...] I understand and I do agree with these points, honestly. These points are also the reason why I will maybe try to use D for my own codes (D is really much better than C++ concerning template, meta programming syntax, embedded unit tests etc...). However I think that to popularize/attract people to use D, it is very important, to have a mechanism/feature that allows you to be close to the "zero overhead" situation. If you have two concurrent libraries (even in different languages), people will adopt the fastest one... As an example, look at the BLAS lib, people do not try to read/understand the code to see how nice it is, they just look at benchmarks and take the fastest implementation for their architecture. IMHO that is the reason why D must let the opportunity, for those who want (library developers for instance) of coding down to the metal: the goal is to have visibility in benchmarks and to attract users. At least it is my point of view. -- Vincent I don't understand this discussion at all. Why not have both? I don't need bare metal stuff at the moment but I might one day, and I perfectly understand that people may need it. At the same time, there are people who are happy with runtime/Phobos/GC. In my opinion it's not a question of "either or" but of "both and".
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote: I write D code all the time for my research. I want to write correct code quickly. My time is too valuable to spend weeks writing code to cut the running time by a few minutes. That might be fun for some people, but it doesn't pay the bills. It's close enough to optimized C performance out of the box. But ultimately I need a tool that provides fast code, has libraries to do what I want, and allows me to write a correct program with a limited budget. This is, of course, not universal, but zero overhead is not important for most of the numerical code that is written. I understand and I do agree with these points, honestly. These points are also the reason why I will maybe try to use D for my own codes (D is really much better than C++ concerning template, meta programming syntax, embedded unit tests etc...). However I think that to popularize/attract people to use D, it is very important, to have a mechanism/feature that allows you to be close to the "zero overhead" situation. If you have two concurrent libraries (even in different languages), people will adopt the fastest one... As an example, look at the BLAS lib, people do not try to read/understand the code to see how nice it is, they just look at benchmarks and take the fastest implementation for their architecture. IMHO that is the reason why D must let the opportunity, for those who want (library developers for instance) of coding down to the metal: the goal is to have visibility in benchmarks and to attract users. At least it is my point of view. -- Vincent
Re: [Semi-OT] I don't want to leave this language!
On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote: Currently I have been learning D for about a year and a half. This may seem like a short time, but this is the longest I have stuck with any language. I have only been learning for 4 years and I am currently in university studying first year of computer systems engineering. My main problem is that now I am looking for industry placements, it is clear that in this field C and C++ are highly desired. I have used C++ prior to discovering D, but much of my learning curve has occured while using D, and I feel quite comfortable using it. Using D makes me look back at what a great language it is compared to C++ (I know it can also be compared to C but I haven't used C). Failing that, think of this as another one of those 'D is great!' posts ;). And whatever happens, I'll certainly try and convince my host company to use it... "Those who will use D will use D". Tomorrow someone else will come and say "Oh, D is not picking up because of poor GC support to handle memory for large scale deployments". To the comments above, let's have a prof on what you are saying. "Those who will use D will use D". Competition is bad. C++ did compeat with C and we now have a beast. Set your goals and focus on that.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 13:14:52 UTC, Kagamin wrote: On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote: Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. Without runtime you won't have asserts (C has them), bounds checking, array casts, string switch. Doesn't sound good to me. All this can be done without runtime. It is weird that we need runtime for now for this features. And why is it a requirement at all? C and C++ already depend on their quite huge runtimes already. Why D shouldn't? Exactly, C already has a runtime. We can reuse it instead of maintaining our own. I never said we must delete DRunime. I just need an infrastructure without runtime. And I am working on it. Ilya
Re: [Semi-OT] I don't want to leave this language!
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote: Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. Without runtime you won't have asserts (C has them), bounds checking, array casts, string switch. Doesn't sound good to me. And why is it a requirement at all? C and C++ already depend on their quite huge runtimes already. Why D shouldn't?
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 12:36:49 UTC, Dejan Lekic wrote: On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote: Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. I started Mir as scientific/numeric project, but it is going to be a replacement for Phobos to use D instead/with of C/C++. Yes, perhaps it is so in your world... In my world I have absolutely no need for this. In fact we are perfectly happy with Java runtime which is many times bigger than druntime! Exactly, this is why D will never beat Java and Go. BTW, both languages has commercial support. Current D users are here because they are OK with current D runtime. The number of users is small. I don't expect/want that every one will agree. I am targeting the ocean where we has not concurrents except C/C++. GC for D is good as dub package or a compiler option. Ilya
Re: [Semi-OT] I don't want to leave this language!
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote: Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. I started Mir as scientific/numeric project, but it is going to be a replacement for Phobos to use D instead/with of C/C++. Yes, perhaps it is so in your world... In my world I have absolutely no need for this. In fact we are perfectly happy with Java runtime which is many times bigger than druntime!
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 09:56:20 UTC, ketmar wrote: On Wednesday, 7 December 2016 at 09:45:39 UTC, Andrey wrote: I think, a good way to step up for Dlang is to be C++ like Ada variant, with possibility to work without GC. you do know that you *can* use D without GC even now, do you? Yes, I do. But it is like C++ without stdlib. And no volatile access, if I didn't miss something. I agree with Ilya, must be a way to use runtime-free D lib.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote: On Wednesday, 7 December 2016 at 06:17:17 UTC, Picaud Vincent wrote: Considering scientific/numerical applications, I do agree with Ilya: it is mandatory to have zero overhead and a straightforward/direct interoperability with C. I am impressed by the Mir lib results and I think "BetterC" is very attractive/important. As always, it depends on what you are doing. It is mandatory for some numerical applications. R, Matlab, Python, Mathematica, Gauss, and Julia are used all the time and they are not zero overhead. A fast way to kill their usage would be to force their users to think about those issues. What matters is the available libraries, first and foremost, and whatever is second most important, it is a distant second. I write D code all the time for my research. I want to write correct code quickly. My time is too valuable to spend weeks writing code to cut the running time by a few minutes. That might be fun for some people, but it doesn't pay the bills. It's close enough to optimized C performance out of the box. But ultimately I need a tool that provides fast code, has libraries to do what I want, and allows me to write a correct program with a limited budget. This is, of course, not universal, but zero overhead is not important for most of the numerical code that is written. R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. --Ilya
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 06:17:17 UTC, Picaud Vincent wrote: Considering scientific/numerical applications, I do agree with Ilya: it is mandatory to have zero overhead and a straightforward/direct interoperability with C. I am impressed by the Mir lib results and I think "BetterC" is very attractive/important. As always, it depends on what you are doing. It is mandatory for some numerical applications. R, Matlab, Python, Mathematica, Gauss, and Julia are used all the time and they are not zero overhead. A fast way to kill their usage would be to force their users to think about those issues. What matters is the available libraries, first and foremost, and whatever is second most important, it is a distant second. I write D code all the time for my research. I want to write correct code quickly. My time is too valuable to spend weeks writing code to cut the running time by a few minutes. That might be fun for some people, but it doesn't pay the bills. It's close enough to optimized C performance out of the box. But ultimately I need a tool that provides fast code, has libraries to do what I want, and allows me to write a correct program with a limited budget. This is, of course, not universal, but zero overhead is not important for most of the numerical code that is written.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 09:45:39 UTC, Andrey wrote: I think, a good way to step up for Dlang is to be C++ like Ada variant, with possibility to work without GC. you do know that you *can* use D without GC even now, do you?
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 07:27:53 UTC, ketmar wrote: On Wednesday, 7 December 2016 at 02:38:50 UTC, bpr wrote: It's a counterfactual at this point, but I would guess that if D had left out the GC in 2010 when D2 came out it would have been ahead of C++ in many ways and perhaps would have been able to peel off more C++ programmers c++ programmers want c++. anything that is not c++ will be bashed to death. there is absolutely no reason to kill one of the key D features only to attract 2.5 c++ coders. actually, we already have That One C++ Programmer We Need onboard -- Andrei. ;-) Let me put My 2 cents too: the goal is not only attracting 2.5 c++ coders, but to expand Dlang using. I like D, and I want to use it wide. And I believe Dlang adepts too. So we must make D to be usefull for small, metal-bare (important for me), embedded things to whatever... We can't do it now with GC. I'am learning Ada lang now, and understood, that many usefull things Walter took from there. I think, a good way to step up for Dlang is to be C++ like Ada variant, with possibility to work without GC. And with GC too, to make life easier, if someone wants. IMO )
