Adding pclmulqdq assembly instruction to dlang asm.
Thanks! Directly using opcodes does the trick.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 02:56:04 UTC, jmh530 wrote: On Saturday, 13 June 2015 at 11:18:54 UTC, Ola Fosheim Grøstad wrote: I think linear algebra should have the same syntax for small and large matrices and switch representation behind the scenes. Switching representations behind the scenes? Sounds complicated. You don't have much of a choice if you want it to perform. You have take take into consideration: 1. hardware factors such as SIMD and alignment 2. what is known at compile time and what is only known at runtime 3. common usage patterns (what elements are usually 0, 1 or a value) 4. when does it pay off to encode the matrix modifications and layout as meta information (like transpose and scalar multiplication or addition) And sometimes you might want to compute the inverse matrix when doing the transforms, rather than as a separate step for performance reasons. I would think that if you were designing it from the ground up, you would have one general matrix math library. Then a graphics library could be built on top of that functionality. That way, as improvements are made to the matrix math functionality, the graphics library would benefit too. Yes, but nobody wants to use a matrix library that does not perform close to the hardware limitations, so the representation should be special cased to fit the hardware for common matrix layouts.
Re: Adding pclmulqdq assembly instruction to dlang asm.
https://issues.dlang.org/show_bug.cgi?id=14697
Re: DIP80: phobos additions
On Saturday, 13 June 2015 at 10:35:55 UTC, Tofu Ninja wrote: On Saturday, 13 June 2015 at 08:45:20 UTC, John Colvin wrote: The tiny subset of numerical linear algebra that is relevant for graphics (mostly very basic operations, 2,3 or 4 dimensions) is not at all representative of the whole. The algorithms are different and the APIs are often necessarily different. Even just considering scale, no one sane calls in to BLAS to multiply a 3*3 matrix by a 3 element vector, simultaneously no one sane *doesn't* call in to BLAS or an equivalent to multiply two 500*500 matrices. I think there is a conflict of interest with what people want. There seem to be people like me who only want or need simple matrices like glm to do basic geometric/graphics related stuff. Then there is the group of people who want large 500x500 matrices to do weird crazy maths stuff. Maybe they should be kept separate? In which case then we are really talking about adding two different things. Maybe have a std.math.matrix and a std.blas? +1 nobody uses general purpose linear matrix libraries for games/graphics for a reason, many game math libraries take shortcuts everywhere and are extensively optimized(e.g, for cache lines) for the general purpose vec3/mat4 types. many performance benefits for massive matrices see performance detriments for tiny graphics-oriented matrices. This is just shoehorning, plain and simple.
Re: std.(experimental.)logger voting manager wanted
On Friday, 12 June 2015 at 12:58:46 UTC, Robert burner Schadek wrote: std.(experimental.)logger has been in phobos for one release. The idea was to mature stuff in experimental for one release and then have a vote on inclusion into phobos as std.logger. I would like to see this vote happen before 2.068. Unfortunately, Dicebot is not longer the review manager. Who wants to count yes/no/(my logger is better) votes in a forum thread? Could you please update the dub-package for the std.logger update to the current version ? as long as I have to support D<2067 for ldc/gdc I need to use the dub package of the logger and this is not api compatible to the one bundled with dmd2067.. -- Stephan
Re: std.(experimental.)logger voting manager wanted
On Sunday, 14 June 2015 at 08:36:16 UTC, extrawurst wrote: On Friday, 12 June 2015 at 12:58:46 UTC, Robert burner Schadek wrote: std.(experimental.)logger has been in phobos for one release. The idea was to mature stuff in experimental for one release and then have a vote on inclusion into phobos as std.logger. I would like to see this vote happen before 2.068. Unfortunately, Dicebot is not longer the review manager. Who wants to count yes/no/(my logger is better) votes in a forum thread? Could you please update the dub-package for the std.logger update to the current version ? as long as I have to support D<2067 for ldc/gdc I need to use the dub package of the logger and this is not api compatible to the one bundled with dmd2067.. -- Stephan Ok nevermind, the dub package does not support dmd<2067 either...
Re: std.(experimental.)logger voting manager wanted
On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: Yes, and it's an obvious issue. Some of the most frequently requested things are real tuple syntax, pattern matching, etc. Short of getting these into D itself(good luck,) any attempt at these will end up being an ugly hack. This is neither obvious issue, not a good solution. The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM).
Re: std.(experimental.)logger voting manager wanted
On Sunday, 14 June 2015 at 08:52:26 UTC, Dicebot wrote: On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: Yes, and it's an obvious issue. Some of the most frequently requested things are real tuple syntax, pattern matching, etc. Short of getting these into D itself(good luck,) any attempt at these will end up being an ugly hack. This is neither obvious issue, not a good solution. The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM). If you say so, nearly every reddit thread about D a top voted comment is about the lack of a real preprocessor/AST macros.
Re: std.(experimental.)logger voting manager wanted
On 2015-06-14 10:52, Dicebot wrote: The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM). I had plans to try and implement pattern matching as a library component. Although, to do that properly I need better introspection for templates. There's an open merge request for template introspection that's waiting. -- /Jacob Carlborg
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 08:14:21 UTC, weaselcat wrote: nobody uses general purpose linear matrix libraries for games/graphics for a reason, The reason is that C++ didn't provide anything. As a result each framework provide their own and you get N different libraries that are incompatible. There is no good reason for making small-matrix libraries incompatible with the rest of eco-system given the templating system you have in D. What you need is a library that supports multiple representations and can do the conversions. Of course, you'll do better if you also have term-rewriting/AST-macros.
Re: Phobos addition formal review: std.experimental.allocator
On 2015-06-14 02:24, Andrei Alexandrescu wrote: * 1 request to change names; * 3 requests to wank around the directory structure; * 0 of everything else. Sigh. These are things that are easy to see right away, without looking deep inside the code. You can interpret this as: 1. Either your implementation is already good enough 2. Or people haven't started to look at the implementation yet and are commenting on the things that they is right away Count me on the request to change the directory structure :) -- /Jacob Carlborg
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 09:07:19 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 08:14:21 UTC, weaselcat wrote: nobody uses general purpose linear matrix libraries for games/graphics for a reason, The reason is that C++ didn't provide anything. As a result each framework provide their own and you get N different libraries that are incompatible. There is no good reason for making small-matrix libraries incompatible with the rest of eco-system given the templating system you have in D. What you need is a library that supports multiple representations and can do the conversions. Of course, you'll do better if you also have term-rewriting/AST-macros. The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs. `opCast(T)` should be enough.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 09:19:19 UTC, Ilya Yaroshenko wrote: The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs. No, the reason is that LA-libraries are C-libraries that also deal with variable sized matrices. A good generic API can support both. You cannot create a good generic API in C. You can in D.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 12/06/2015 12:48 PM, Chris wrote: "man" is still used as a gender neutral pronoun in German, however, for some reason it's frowned upon these days, just like "one" in English. It's considered "arrogant" and old fashioned, but it's effin useful and solves a lot of problems. Mind you, decisions made by those who compile dictionaries and "standards" are not at all based on the reality of a given language. Double negation exists in English (and many other languages), but it's stigmati(s|z)ed as being "incorrect". The vote was 5 to 4 when this decision was made in England. The official reasoning behind it was that minus + minus = plus, i.e. "I don't have no money" would mean "I do have money", which is complete horsesh*t. Of course it means "I don't have money". The real reason, of course, was class snobbery and elitism: double negation was and still is commonly used in working class English in England (and the US, I think). Ironically enough, double negation is obligatory in standard French, while it is not used in colloquial French. This shows you how arbitrary these standards are. Don't take them too seriously, and don't start religious wars about some eggheads' decisions ;) The same goes for "ain't". There's no reason why "ain't" should be "bad English". "I ain't got no money" is perfectly fine, although it might make the odd Oxbridge fellow cringe and spill his tea. But what the Dickens, old chap! I must be rare, cos I ain't posh n' well educated but I deplore the use of double negatives in English. I might be heard t'say "I ain't got n' money" (cos it be true) but in that case the "n'" is the local dialect contraction of "any". Other areas of the UK can't use the same excuse, maybe they got it from us but didn't understand what we were say'n, which is very common, but am more inclined to blame ignorance. Don't know anything about double negative usage in French, but I do know that they are a way making super polite requests in Japanese. Lets all not not stop arguing the minutia. A...
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 12/06/2015 10:37 PM, Nick Sabalausky wrote: Yea, I'm fine with "ain't" being considered an actual word. Years ago, I used to hear a lot of "'Ain't' isn't a real word", but meh, it's used as a word, even the people who don't like it still know full-well exactly what it means, so...I ain't got a big problem with it :) But there was one particular argument in favor of "ain't" that I never liked: "It's a contraction for 'are not'." Well, no, it isn't a contraction for "are not" (maybe it originally was, I dunno). Because "I ain't going" vs "I are not going." So no, it may be a word, but it ain't a contraction for "are not". It is a contraction of "are not" because it originates from a time/dialect where the verb to-be was conjugated differently than today's English. Many of the irregularities of to-be are ignored in international English which gives rise to dialects among ESL speakers that sound wrong but endearing (at least to my ears). A...
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 09:25:25 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 09:19:19 UTC, Ilya Yaroshenko wrote: The reason is general purpose matrixes allocated at heap, but small graphic matrices are plain structs. No, the reason is that LA-libraries are C-libraries that also deal with variable sized matrices. A good generic API can support both. You cannot create a good generic API in C. You can in D. We need D own BLAS implementation to do it. Sight, DBLAS will be largest part of std.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 09:59:22 UTC, Ilya Yaroshenko wrote: We need D own BLAS implementation to do it. Why can't you use "version" for those that want to use a BLAS library for the implementation? Those who want replications of LAPACK/LINPACK APIs can use separate bindings? And those who want to use BLAS directly would not use phobos anyway, but a direct binding so they can switch implementation? I think a good generic higher level linear algebra library for D should aim to be equally useful for 2D Graphics, 3D/4D GPU graphics, CAD solid modelling, robotics, 3D raytracing, higher dimensional fractals, physics sims, image processing, signal processing, scientific computing (which is pretty wide) and more. The Phobos API should be user-level, not library-level like BLAS. IMO. You really want an API that look like this in Phobos? http://www.netlib.org/blas/ BLAS/LAPACK/LINPACK all originate in Fortran with a particular scientific tradition in mind, so I think one should rethink how D goes about this. Fortran has very primitive abstraction mechanisms. This stuff is stuck in the 80s…
Re: std.(experimental.)logger voting manager wanted
On Sun, 14 Jun 2015 08:58:12 +, weaselcat wrote: > On Sunday, 14 June 2015 at 08:52:26 UTC, Dicebot wrote: >> On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: >>> Yes, and it's an obvious issue. Some of the most frequently requested >>> things are real tuple syntax, pattern matching, etc. >>> Short of getting these into D itself(good luck,) any attempt at these >>> will end up being an ugly hack. >> >> This is neither obvious issue, not a good solution. >> >> The fact that no one will implement custom pattern matching until it >> comes into language officially is a Good Thing (TM). > > If you say so, nearly every reddit thread about D a top voted comment is > about the lack of a real preprocessor/AST macros. reddit herd are mostly monkeys which didn't even know D enough. signature.asc Description: PGP signature
Re: version: multiple conditions
On Saturday, 13 June 2015 at 21:51:43 UTC, bitwise wrote:
On Sat, 13 Jun 2015 17:29:17 -0400, Xiaoxi
wrote:
On Saturday, 13 June 2015 at 21:19:28 UTC, bitwise wrote:
On Sat, 13 Jun 2015 17:16:04 -0400, weaselcat
wrote:>
iirc this falls under the "walter dislikes it so we won't
have it" category.
As Andrei said at DConf though, consensus requires at least 3
people ;)
Bit
The current design encourages using more finegrained features
instead of the more blunt Os level versions.
version(iOS) { version = pthread;}
version(Android) { version = pthread;}
In the rest of the file simply check for pthread instead of OS.
That _sounds_ nice, but consider this:
version (linux) {
import core.sys.linux.dlfcn;
version = use_dlopen;
}
else version (FreeBSD) {
import core.sys.freebsd.dlfcn;
version = use_dlopen;
}
version(linux || FreeBSD) {
//version(linux || FreeBSD) {
version(use_dlopen) {
dlopen(...)
}
I shouldn't have to add another version just for that last
dlopen block. It's not "finegrained" control, it's cruft.
It does require more definitions, but it's worth it. A simple
example like yours may seem excusable, but there's no way to
limit such logic to just simple instances. Walter is coming from
long experience with this, and even with my limited experience
with such logic, I'm grateful for it, as dealing with more
complex versions of such logic is a royal PITA.
Re: DIP80: phobos additions
I think there might be a disconnection in this thread. D only, or D frontend? There are hardware vendor and commercial libraries that are heavily optimized for particular hardware configurations. There is no way a D-only solution can beat those. As an example Apple provides various implementations for their own machines, so an old program on a new machine can run faster than a static D-only library solution. What D can provide is a unifying abstraction, but to get there one need to analyze what exists. Like Apple's Accelerate framework: https://developer.apple.com/library/prerelease/ios/documentation/Accelerate/Reference/AccelerateFWRef/index.html#//apple_ref/doc/uid/TP40009465 That goes beyond BLAS. We also need to look at vDSP etc. You'll find similar things for Microsoft/Intel/AMD/ARM etc…
Re: std.(experimental.)logger voting manager wanted
On Sunday, 14 June 2015 at 10:16:18 UTC, ketmar wrote: On Sun, 14 Jun 2015 08:58:12 +, weaselcat wrote: On Sunday, 14 June 2015 at 08:52:26 UTC, Dicebot wrote: On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: Yes, and it's an obvious issue. Some of the most frequently requested things are real tuple syntax, pattern matching, etc. Short of getting these into D itself(good luck,) any attempt at these will end up being an ugly hack. This is neither obvious issue, not a good solution. The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM). If you say so, nearly every reddit thread about D a top voted comment is about the lack of a real preprocessor/AST macros. reddit herd are mostly monkeys which didn't even know D enough. avoid success at all costs
Re: Phobos addition formal review: std.experimental.allocator
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu wrote: So we have: * 1 request to change names; * 3 requests to wank around the directory structure; * 0 of everything else. Sigh. Andrei How about this: AllocatorList.allocate() calls AllocatorList.owns(), but only if you don't compile with -release. Check the assert statement. AllocatorList.owns() is non-const, so the for loops of these two functions start rearranging the root pointers and end up in an infinite loop in debug builds.
Re: Question about garbage collection specification
On Saturday, 13 June 2015 at 22:07:26 UTC, deadalnix wrote:
On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
http://dlang.org/garbage.html
Do not take advantage of alignment of pointers to store bit
flags in the low order bits:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
if this restriction is actually imposed - why does
std.bitmanip.tagged{ClassRef,Pointer} even exist?
That seems like an arbitrary limitation. This will create an
interior pointer, which the GC needs to recognize anyway.
The doc need to be updated.
I see David Nadlinger already said so in the PR, but that's how I
understand it:
AFAIU the purpose of this restriction is to allow the GC to take
advantage of alignment: a pointer with the lowest bit set cannot
point to a 4-byte aligned struct, for example. The GC doc [1]
mentions alignment several times, among them:
"Do not misalign pointers if those pointers may point into the GC
heap"
As for arbitrary pointer arithmetic being allowed, I guess that's
because the language doesn't distinguish between GC and non-GC
pointers. And note that it is un-@safe anyway.
[1] http://dlang.org/garbage.html
Re: version: multiple conditions
On Sun, 14 Jun 2015 10:35:30 +, Joakim wrote: > It does require more definitions, but it's worth it. A simple example > like yours may seem excusable, but there's no way to limit such logic to > just simple instances. Walter is coming from long experience with this, > and even with my limited experience with such logic, I'm grateful for > it, as dealing with more complex versions of such logic is a royal PITA. honestly, if i'll want to have a limited language, i'll take Go. removing a power only 'cause it can be abused is not in a "spirit of D", at least as i see it. templates can be enormously abused, but noone claims that they should be removed, as code without templates sometimes easier to follow, and abusing templates can be a PITA. signature.asc Description: PGP signature
Re: version: multiple conditions
p.s. i.e. it boils down to simple thing: Walter don't like it. period. any rationalizing of that is pointless. signature.asc Description: PGP signature
Re: std.(experimental.)logger voting manager wanted
On Sun, 14 Jun 2015 10:46:27 +, weaselcat wrote: > On Sunday, 14 June 2015 at 10:16:18 UTC, ketmar wrote: >> On Sun, 14 Jun 2015 08:58:12 +, weaselcat wrote: >> >>> On Sunday, 14 June 2015 at 08:52:26 UTC, Dicebot wrote: On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: > Yes, and it's an obvious issue. Some of the most frequently > requested things are real tuple syntax, pattern matching, etc. > Short of getting these into D itself(good luck,) any attempt at > these will end up being an ugly hack. This is neither obvious issue, not a good solution. The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM). >>> >>> If you say so, nearly every reddit thread about D a top voted comment >>> is about the lack of a real preprocessor/AST macros. >> >> reddit herd are mostly monkeys which didn't even know D enough. > > avoid success at all costs i honestly want reddit to be burnt. the only "good" thing i've seen from that is "no, we don't follow #breakourcode, as some reddit retard that doesn't even using D will complain about that!" signature.asc Description: PGP signature
Re: std.(experimental.)logger voting manager wanted
On Saturday, 13 June 2015 at 17:33:06 UTC, Andrei Alexandrescu wrote: On 6/13/15 9:22 AM, weaselcat wrote: "proper" reference counting would be trivial to implement with a real macro system. The true Scotsman, eh :o). Well we don't have a real macro system. -- Andrei At the risk of sounding like a broken record: "Proper" reference counting would also be trivial to implement with a working scope implementation.
Re: version: multiple conditions
On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote: p.s. i.e. it boils down to simple thing: Walter don't like it. period. any rationalizing of that is pointless. The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable.
Re: version: multiple conditions
On Sunday, 14 June 2015 at 11:26:23 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote: p.s. i.e. it boils down to simple thing: Walter don't like it. period. any rationalizing of that is pointless. The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable. Not all of them http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/
Re: Question about garbage collection specification
On Sunday, 14 June 2015 at 11:03:00 UTC, Marc Schütz wrote:
On Saturday, 13 June 2015 at 22:07:26 UTC, deadalnix wrote:
On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
http://dlang.org/garbage.html
Do not take advantage of alignment of pointers to store bit
flags in the low order bits:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
if this restriction is actually imposed - why does
std.bitmanip.tagged{ClassRef,Pointer} even exist?
That seems like an arbitrary limitation. This will create an
interior pointer, which the GC needs to recognize anyway.
The doc need to be updated.
I see David Nadlinger already said so in the PR, but that's how
I understand it:
AFAIU the purpose of this restriction is to allow the GC to
take advantage of alignment: a pointer with the lowest bit set
cannot point to a 4-byte aligned struct, for example. The GC
doc [1] mentions alignment several times, among them:
"Do not misalign pointers if those pointers may point into the
GC heap"
As for arbitrary pointer arithmetic being allowed, I guess
that's because the language doesn't distinguish between GC and
non-GC pointers. And note that it is un-@safe anyway.
[1] http://dlang.org/garbage.html
Wouldn't it make sense to do so?
Active Oberon, Modula-3 and .NET make such difference in their
pointer types.
I would imagine it could help in terms of what is possible for GC
improvements.
--
Paulo
Re: version: multiple conditions
On Sunday, 14 June 2015 at 11:33:52 UTC, Paulo Pinto wrote: Not all of them http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/ AFAIK in the discussions it becomes clear that just about everyone want the change, but some want the change to be saved for 2.0 out of SemVer principles, not because it affects actual code that is in production. I wouldn't use Rust until it hits 2.0, but then again, I also wait 1 year to install a new OS...
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 10:15:08 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 09:59:22 UTC, Ilya Yaroshenko wrote: We need D own BLAS implementation to do it. Why can't you use "version" for those that want to use a BLAS library for the implementation? Those who want replications of LAPACK/LINPACK APIs can use separate bindings? And those who want to use BLAS directly would not use phobos anyway, but a direct binding so they can switch implementation? I think a good generic higher level linear algebra library for D should aim to be equally useful for 2D Graphics, 3D/4D GPU graphics, CAD solid modelling, robotics, 3D raytracing, higher dimensional fractals, physics sims, image processing, signal processing, scientific computing (which is pretty wide) and more. The Phobos API should be user-level, not library-level like BLAS. IMO. You really want an API that look like this in Phobos? http://www.netlib.org/blas/ BLAS/LAPACK/LINPACK all originate in Fortran with a particular scientific tradition in mind, so I think one should rethink how D goes about this. Fortran has very primitive abstraction mechanisms. This stuff is stuck in the 80s… I am really don't understand what you mean with "generic" keyword. Do you want one matrix type that includes all cases??? I hope you does not. If not, yes it should be generic like all other Phobos. But we will have one module for 3D/4D geometric and 3D/4D matrix/vector multiplications, another module for general matrix (std.container.matrix) and another module with generic BLAS (std.numeric.blas) for general purpose matrixes. After all of that we can think about scripting like "m0 = m1*v*m2" features. I think LAPACK would not be implemented in Phobos, but we can use SciD instead.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 10:43:24 UTC, Ola Fosheim Grøstad wrote: I think there might be a disconnection in this thread. D only, or D frontend? There are hardware vendor and commercial libraries that are heavily optimized for particular hardware configurations. There is no way a D-only solution can beat those. As an example Apple provides various implementations for their own machines, so an old program on a new machine can run faster than a static D-only library solution. What D can provide is a unifying abstraction, but to get there one need to analyze what exists. Like Apple's Accelerate framework: https://developer.apple.com/library/prerelease/ios/documentation/Accelerate/Reference/AccelerateFWRef/index.html#//apple_ref/doc/uid/TP40009465 That goes beyond BLAS. We also need to look at vDSP etc. You'll find similar things for Microsoft/Intel/AMD/ARM etc… +1
Re: Question about garbage collection specification
On Sunday, 14 June 2015 at 11:36:59 UTC, Paulo Pinto wrote:
On Sunday, 14 June 2015 at 11:03:00 UTC, Marc Schütz wrote:
On Saturday, 13 June 2015 at 22:07:26 UTC, deadalnix wrote:
On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
http://dlang.org/garbage.html
Do not take advantage of alignment of pointers to store bit
flags in the low order bits:
p = cast(void*)(cast(int)p | 1); // error: undefined
behavior
if this restriction is actually imposed - why does
std.bitmanip.tagged{ClassRef,Pointer} even exist?
That seems like an arbitrary limitation. This will create an
interior pointer, which the GC needs to recognize anyway.
The doc need to be updated.
I see David Nadlinger already said so in the PR, but that's
how I understand it:
AFAIU the purpose of this restriction is to allow the GC to
take advantage of alignment: a pointer with the lowest bit set
cannot point to a 4-byte aligned struct, for example. The GC
doc [1] mentions alignment several times, among them:
"Do not misalign pointers if those pointers may point into the
GC heap"
As for arbitrary pointer arithmetic being allowed, I guess
that's because the language doesn't distinguish between GC and
non-GC pointers. And note that it is un-@safe anyway.
[1] http://dlang.org/garbage.html
Wouldn't it make sense to do so?
Active Oberon, Modula-3 and .NET make such difference in their
pointer types.
I would imagine it could help in terms of what is possible for
GC improvements.
--
Paulo
But a pointer can already point to a one byte aligned part of an
object and keep it alive because internal pointers must be
supported. The only alignment enforced is that pointers must be
aligned. This is an arbitrary restriction.
Re: Question about garbage collection specification
On Sunday, 14 June 2015 at 11:57:35 UTC, rsw0x wrote:
On Sunday, 14 June 2015 at 11:36:59 UTC, Paulo Pinto wrote:
On Sunday, 14 June 2015 at 11:03:00 UTC, Marc Schütz wrote:
On Saturday, 13 June 2015 at 22:07:26 UTC, deadalnix wrote:
On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
http://dlang.org/garbage.html
Do not take advantage of alignment of pointers to store bit
flags in the low order bits:
p = cast(void*)(cast(int)p | 1); // error: undefined
behavior
if this restriction is actually imposed - why does
std.bitmanip.tagged{ClassRef,Pointer} even exist?
That seems like an arbitrary limitation. This will create an
interior pointer, which the GC needs to recognize anyway.
The doc need to be updated.
I see David Nadlinger already said so in the PR, but that's
how I understand it:
AFAIU the purpose of this restriction is to allow the GC to
take advantage of alignment: a pointer with the lowest bit
set cannot point to a 4-byte aligned struct, for example. The
GC doc [1] mentions alignment several times, among them:
"Do not misalign pointers if those pointers may point into
the GC heap"
As for arbitrary pointer arithmetic being allowed, I guess
that's because the language doesn't distinguish between GC
and non-GC pointers. And note that it is un-@safe anyway.
[1] http://dlang.org/garbage.html
Wouldn't it make sense to do so?
Active Oberon, Modula-3 and .NET make such difference in their
pointer types.
I would imagine it could help in terms of what is possible for
GC improvements.
--
Paulo
But a pointer can already point to a one byte aligned part of
an object and keep it alive because internal pointers must be
supported. The only alignment enforced is that pointers must be
aligned. This is an arbitrary restriction.
Woops, replied to the wrong person. My bad.
And yes, you're right that the GC could improve if we went
towards "d pointers" like Go did.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 11:43:46 UTC, Ilya Yaroshenko wrote: I am really don't understand what you mean with "generic" keyword. Do you want one matrix type that includes all cases??? I hope you does not. Yes, that is what generic programming is about. The type should signify the semantics, not exact representation. Then you alias common types "float4x4" etc. It does take a lot of abstraction design work. I've done some of it in C++ for sliced views over memory and arrays and I'd say you need many iterations to get it right. If not, yes it should be generic like all other Phobos. But we will have one module for 3D/4D geometric and 3D/4D matrix/vector multiplications, another module for general matrix (std.container.matrix) and another module with generic BLAS (std.numeric.blas) for general purpose matrixes. After all of that we can think about scripting like "m0 = m1*v*m2" features. All I can say is that I have a strong incentive to avoid using Phobos features if D does not automatically utilize the best OS/CPU vendor provided libraries in a portable manner and with easy-to-read high level abstractions. D's strength compared to C++/Rust is that D can evolve to be easier to use than those languages. C++/Rust are hard to use by nature. But usability takes a lot of API design effort, so it won't come easy. D's strength compared to Go is that it can better take advantage of hardware and provide better library abstractions, Go appears to deliberately avoid it. They probably want to stay nimble with very limited hardware-interfacing so that you can easily move it around in the cloud.
Re: version: multiple conditions
On Sunday, 14 June 2015 at 11:33:52 UTC, Paulo Pinto wrote: On Sunday, 14 June 2015 at 11:26:23 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote: p.s. i.e. it boils down to simple thing: Walter don't like it. period. any rationalizing of that is pointless. The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable. Not all of them http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/ not really surprising considering rust was rushed out the door, there were no breaks on that hype train.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 12:01:47 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 11:43:46 UTC, Ilya Yaroshenko wrote: I am really don't understand what you mean with "generic" keyword. Do you want one matrix type that includes all cases??? I hope you does not. Yes, that is what generic programming is about. The type should signify the semantics, not exact representation. Then you alias common types "float4x4" etc. std.range has a lot of types + D arrays. The power in unified API (structural type system). For matrixes this API is very simple: operations like m1[] += m2, transposed, etc. Ilya
Re: Question about garbage collection specification
On Sunday, 14 June 2015 at 11:36:59 UTC, Paulo Pinto wrote: On Sunday, 14 June 2015 at 11:03:00 UTC, Marc Schütz wrote: As for arbitrary pointer arithmetic being allowed, I guess that's because the language doesn't distinguish between GC and non-GC pointers. And note that it is un-@safe anyway. [1] http://dlang.org/garbage.html Wouldn't it make sense to do so? Active Oberon, Modula-3 and .NET make such difference in their pointer types. I would imagine it could help in terms of what is possible for GC improvements. Definitely, but I don't see how it could reasonably be added to the language now.
DConf 2015 Video
Hi, Any news of the release date for the video from DConf 2015?
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 12:18:39 UTC, Ilya Yaroshenko wrote: std.range has a lot of types + D arrays. The power in unified API (structural type system). Yeah, I agree that templates in C++/D more or less makes those type systems structural-like, even though C is using nominal typing. I've also found that although the combinatorial explosion is a possibility, most applications I write have a "types.h" file that define the subset I want to use for that application. So the combinatorial explosion is not such a big deal after all. But one need to be patient and add lots of static_asserts… since the template type system is weak. For matrixes this API is very simple: operations like m1[] += m2, transposed, etc. I think it is a bit more complicated than that. You also need to think about alignment, padding, strides, convolutions, identiy matrices, invertible matrices, windows on a stream, higher order matrices etc…
Re: version: multiple conditions
bitwise wrote:
> for at least adding "||" so that code can be shared between platforms?
Sureley it is a pita to write:
version( iOS) version= iOS;
else version( Android) version= Android;
else version= neither;
version( neither) version= neither;
else version=iOSorAndroid;
version( iOSorAndroid){
// ...
}
-manfred
Re: std.(experimental.)logger voting manager wanted
On 6/14/15 1:58 AM, weaselcat wrote: On Sunday, 14 June 2015 at 08:52:26 UTC, Dicebot wrote: On Saturday, 13 June 2015 at 18:50:33 UTC, weaselcat wrote: Yes, and it's an obvious issue. Some of the most frequently requested things are real tuple syntax, pattern matching, etc. Short of getting these into D itself(good luck,) any attempt at these will end up being an ugly hack. This is neither obvious issue, not a good solution. The fact that no one will implement custom pattern matching until it comes into language officially is a Good Thing (TM). If you say so, nearly every reddit thread about D a top voted comment is about the lack of a real preprocessor/AST macros. No. It's about the GC and tooling. -- Andrei
Re: version: multiple conditions
On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
bitwise wrote:
for at least adding "||" so that code can be shared between
platforms?
Sureley it is a pita to write:
version( iOS) version= iOS;
else version( Android) version= Android;
else version= neither;
version( neither) version= neither;
else version=iOSorAndroid;
version( iOSorAndroid){
// ...
}
It is, but it is only a 0.0001% source code increase that can be
hidden in a config file.
I really hope that the next two release will focus on bugfixes,
transitioning to D and refactoring.
If DMD source code was lean D code, it would attract more
developers to the compiler. So avoiding changes now would pay off
in terms of long term evolution.
You cannot both transition to D and focus on changes. Freeze the
feature set...
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 12:52:52 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 12:18:39 UTC, Ilya Yaroshenko wrote: std.range has a lot of types + D arrays. The power in unified API (structural type system). Yeah, I agree that templates in C++/D more or less makes those type systems structural-like, even though C is using nominal typing. I've also found that although the combinatorial explosion is a possibility, most applications I write have a "types.h" file that define the subset I want to use for that application. So the combinatorial explosion is not such a big deal after all. But one need to be patient and add lots of static_asserts… since the template type system is weak. For matrixes this API is very simple: operations like m1[] += m2, transposed, etc. I think it is a bit more complicated than that. You also need to think about alignment, padding, strides, convolutions, identiy matrices, invertible matrices, windows on a stream, higher order matrices etc… Alignment, strides (windows on a stream - I understand it like Sliding Windows) are not a problem. Convolutions, identiy matrices, invertible matrices are stuff I don't want to see in Phobos. They are about "MathD" not about (big) standard library. For hight order slices see https://github.com/D-Programming-Language/phobos/pull/3397
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 13:48:23 UTC, Ilya Yaroshenko wrote: Alignment, strides (windows on a stream - I understand it like Sliding Windows) are not a problem. It isn't a problem if you use the best possible abstraction from the start. It is a problem if you don't focus on it from the start. Convolutions, identiy matrices, invertible matrices are stuff I don't want to see in Phobos. They are about "MathD" not about (big) standard library. I don't see how you can get good performance without special casing identity matrices, transposed matrices and so on. You surely need to support matrix inversion, Gauss-Jordan elimination (or the equivalent) etc?
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 14:02:59 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 14 June 2015 at 13:48:23 UTC, Ilya Yaroshenko wrote:
Alignment, strides (windows on a stream - I understand it like
Sliding Windows) are not a problem.
It isn't a problem if you use the best possible abstraction
from the start. It is a problem if you don't focus on it from
the start.
I am sorry for this trolling:
Lisp is the best abstraction, thought.
Sometimes I find very cool abstract libraries, with relatively
small number of users.
For example many programmers don't want to use Boost only because
it's abstractions makes them crazy.
Convolutions, identiy matrices, invertible matrices are stuff
I don't want to see in Phobos. They are about "MathD" not
about (big) standard library.
I don't see how you can get good performance without special
casing identity matrices, transposed matrices and so on. You
surely need to support matrix inversion, Gauss-Jordan
elimination (or the equivalent) etc?
For daily scientific purposes - yes.
For R/Matlab like mathematical library - yes.
For real world application - no. Engineer can achieve best
performance without special cases by lowering "abstraction" down.
Simplicity and transparency ("how it works") is more important in
this case.
Re: DConf 2015 Video
On 6/14/15 5:42 AM, Frank Fuente wrote: Any news of the release date for the video from DConf 2015? Got word from Chuck that they've had an urgent project until now. They're starting working on the videos this week and will make them available one by one as each is ready. -- Andrei
Re: version: multiple conditions
On Sunday, 14 June 2015 at 11:03:49 UTC, ketmar wrote: On Sun, 14 Jun 2015 10:35:30 +, Joakim wrote: It does require more definitions, but it's worth it. A simple example like yours may seem excusable, but there's no way to limit such logic to just simple instances. Walter is coming from long experience with this, and even with my limited experience with such logic, I'm grateful for it, as dealing with more complex versions of such logic is a royal PITA. honestly, if i'll want to have a limited language, i'll take Go. removing a power only 'cause it can be abused is not in a "spirit of D", at least as i see it. templates can be enormously abused, but noone claims that they should be removed, as code without templates sometimes easier to follow, and abusing templates can be a PITA. Walter explained his thinking behind this decision in five comments on this PR: https://github.com/D-Programming-Language/dlang.org/pull/243#issuecomment-12883555 I agree with him. You shouldn't be using such logic at the point the code is inserted or elided. It can get very confusing as you layer on logic and is extremely brittle for anything approaching even a medium-sized codebase. You may be able to get away with it for a small codebase, but then you really can't complain about repetition, because there isn't much code in the first place. ;) Of course, there's always a way out: use static if like Etienne did in his linked file. But that's not a good practice and it's good that Walter is to discouraging it.
Re: Phobos addition formal review: std.experimental.allocator
On 6/14/15 4:00 AM, Brian Schott wrote: On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu wrote: So we have: * 1 request to change names; * 3 requests to wank around the directory structure; * 0 of everything else. Sigh. Andrei How about this: AllocatorList.allocate() calls AllocatorList.owns(), but only if you don't compile with -release. Check the assert statement. AllocatorList.owns() is non-const, so the for loops of these two functions start rearranging the root pointers and end up in an infinite loop in debug builds. Interesting. Do you have a repro for this? Thanks! -- Andrei
Re: Phobos addition formal review: std.experimental.allocator
On 6/13/15 11:49 PM, Dicebot wrote: On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu wrote: So we have: * 1 request to change names; * 3 requests to wank around the directory structure; * 0 of everything else. Sigh. That is to be expected and intended for formal Phobos review. Implementation is not of much interest - it can be fixed at any point. Most important thing is to ensure that API feels right, documentation feels clear and people are in general comfortable with using proposed modules as they are. I will do more in-depth review but it will _all_ be about API and docs and naming. Suggestions for better names are welcome as addenda, and I will act on some, but they're no substitute for competent reviews. We need as a community to learn how to do good reviews. Anyone can put a finger on a name of a thing and say they like another name better. ANYONE. Real review of a library is figuring out how well the proposed library's abstractions fulfill its charter and intended use cases. Andrei
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 14:25:11 UTC, Ilya Yaroshenko wrote:
I am sorry for this trolling:
Lisp is the best abstraction, thought.
Even it if was, it does not provide the meta info and alignment
type constraints that makes it possible to hardware/SIMD optimize
it behind the scenes.
For example many programmers don't want to use Boost only
because it's abstractions makes them crazy.
Yes, C++ templates are a hard nut to crack, if D had added
excellent pattern matching to its meta programming repertoire the
I think this would be enough to put D in a different league.
Application programmers should not have to deal with lots of type
parameters, they can use the simplified version (aliases). That's
what I do in my C++ libs, using templated aliasing to make a
complicated type composition easy to use while still getting the
benefits generic pattern matching and generic programming.
Convolutions, identiy matrices, invertible matrices are stuff
For daily scientific purposes - yes.
For R/Matlab like mathematical library - yes.
For real world application - no. Engineer can achieve best
performance without special cases by lowering "abstraction"
down. Simplicity and transparency ("how it works") is more
important in this case.
Getting platform optimized versions of frequently used heavy
operations is the primary reason for why I would use a builtin
library over rolling my own. Especially if the compiler has
builtin high-level optimizations for the algebra.
A naive basic matrix library is simple to write, I don't need
standard library support for that + I get it to work the way I
want by using SIMD registers directly... => I probably would not
use it if I could implement it in less than 10 hours.
Re: version: multiple conditions
On Sunday, 14 June 2015 at 12:06:03 UTC, weaselcat wrote: not really surprising considering rust was rushed out the door, there were no breaks on that hype train. I dunno if it was rushed. They have slashed the feature set quite a lot over the years. At some point it makes a lot of sense to set a fixed deadline and stick to it at the expense of expanding the feature set and strongly encouraging bug fixing. If anything the discussion around SemVer in the Rust community suggests that a lot of people there take language stability very seriously.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 14:46:36 UTC, Ola Fosheim Grøstad wrote: Yes, C++ templates are a hard nut to crack, if D had added excellent pattern matching to its meta programming repertoire the I think this would be enough to put D in a different league. https://github.com/solodon4/Mach7
Re: DIP80: phobos additions
A naive basic matrix library is simple to write, I don't need standard library support for that + I get it to work the way I want by using SIMD registers directly... => I probably would not use it if I could implement it in less than 10 hours. A naive std.algorithm and std.range is easy to write too.
Re: DConf 2015 Video
On Sunday, 14 June 2015 at 14:27:57 UTC, Andrei Alexandrescu wrote: On 6/14/15 5:42 AM, Frank Fuente wrote: Any news of the release date for the video from DConf 2015? Got word from Chuck that they've had an urgent project until now. They're starting working on the videos this week and will make them available one by one as each is ready. -- Andrei Excellent. That's great news.
Re: version: multiple conditions
On Sun, 14 Jun 2015 14:26:25 +, Joakim wrote: > Walter explained his thinking behind this decision in five comments on > this PR: exactly what i told: "I don't like it, so abandon all hope". signature.asc Description: PGP signature
Re: version: multiple conditions
On Sunday, 14 June 2015 at 15:46:39 UTC, ketmar wrote: On Sun, 14 Jun 2015 11:26:21 +, Ola Fosheim Grøstad wrote: I'm sure Walter will be much more open to changes if there is a proven demand for it only if he like it. or at least indifferent to it. "This is true IF you are trying to use version blocks in the same way one does in C. However, that is the stylistically wrong way to do it in D." that's all. it doesn't matter how loud people would complian, it's "syntactically wrong". period. "a proven demand" is just a kind way of describing "an emerging fork"... ;^)
Re: version: multiple conditions
p.s. sorry, "stylistically", of course. mea maxima culpa. signature.asc Description: PGP signature
Re: version: multiple conditions
On Sun, 14 Jun 2015 15:49:40 +, Ola Fosheim Grøstad wrote: > On Sunday, 14 June 2015 at 15:46:39 UTC, ketmar wrote: >> On Sun, 14 Jun 2015 11:26:21 +, Ola Fosheim Grøstad wrote: >> >>> I'm sure Walter will be much more open to changes if there is a proven >>> demand for it >> >> only if he like it. or at least indifferent to it. >> >> "This is true IF you are trying to use version blocks in the same way >> one does in C. However, that is the stylistically wrong way to do it in >> D." >> >> that's all. it doesn't matter how loud people would complian, it's >> "syntactically wrong". period. > > "a proven demand" is just a kind way of describing "an emerging fork"... > > ;^) any D fork is doomed to die. community is too small, there are simply not enough developers to make a split. i'm doing Aliced for my own favor, yet i never thought that it can be a competitor for vanilla. signature.asc Description: PGP signature
Re: version: multiple conditions
On Sun, 14 Jun 2015 11:26:21 +, Ola Fosheim Grøstad wrote: > I'm sure Walter will be much more open to changes if there is a proven > demand for it only if he like it. or at least indifferent to it. "This is true IF you are trying to use version blocks in the same way one does in C. However, that is the stylistically wrong way to do it in D." that's all. it doesn't matter how loud people would complian, it's "syntactically wrong". period. signature.asc Description: PGP signature
Re: version: multiple conditions
On Sun, 14 Jun 2015 10:26:25 -0400, Joakim wrote: Walter explained his thinking behind this decision in five comments on this PR: Thanks for the link ;) Bit
Re: DMD memory management
On Sunday, 14 June 2015 at 16:37:19 UTC, bitwise wrote: I'm trying to mod dmd, and I'm totally confused about what's goin on. -some things are allocated with 'new' and some are allocated with 'mem.malloc' -most things don't ever seem to be freed -no RAII is used for cleanup -no clear ownership of pointers How does memory get cleaned up? Is it just assumed that the process is short-lived, and that memory can just be left dangling until it terminates? Thanks, Bit to answer all your questions at once: it doesn't
Re: DMD memory management
On Sun, 14 Jun 2015 12:37:18 -0400, bitwise wrote: > How does memory get cleaned up? yes. by OS when process terminates. http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 a small quote: "DMD does memory allocation in a bit of a sneaky way. Since compilers are short-lived programs, and speed is of the essence, DMD just mallocs away, and never frees." so it's by design. signature.asc Description: PGP signature
Re: version: multiple conditions
On Sun, 14 Jun 2015 09:36:17 -0400, Ola Fosheim Grøstad
wrote:
On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
bitwise wrote:
for at least adding "||" so that code can be shared between platforms?
Sureley it is a pita to write:
version( iOS) version= iOS;
else version( Android) version= Android;
else version= neither;
version( neither) version= neither;
else version=iOSorAndroid;
version( iOSorAndroid){
// ...
}
It is, but it is only a 0.0001% source code increase that can be hidden
in a config file.
It's not just about the code increase though. What if I need AndroidOrWP8,
and I also need Win32OrWin64? This can quickly become a much larger pita.
I really hope that the next two release will focus on bugfixes,
transitioning to D and refactoring.
If DMD source code was lean D code, it would attract more developers to
the compiler. So avoiding changes now would pay off in terms of long
term evolution.
You cannot both transition to D and focus on changes. Freeze the feature
set...
True. Maybe I'm underestimating the amount of effort that is going into
this. I admit I don't know much about whats going on with the DDMD stuff.
Bit
Re: version: multiple conditions
On Sun, 14 Jun 2015 06:35:30 -0400, Joakim wrote: Walter is coming from long experience with this,and even with my limited experience with such logic, I'm grateful for it, as dealing with more complex versions of such logic is a royal PITA. He's an expert, no doubt, but I've learned not to put people on a pedestal because of their level of experience. Anyone can be wrong, or change their mind. Bit
Re: DMD memory management
On Sun, 14 Jun 2015 12:52:47 -0400, ketmar wrote: On Sun, 14 Jun 2015 12:37:18 -0400, bitwise wrote: How does memory get cleaned up? yes. by OS when process terminates. http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 a small quote: "DMD does memory allocation in a bit of a sneaky way. Since compilers are short-lived programs, and speed is of the essence, DMD just mallocs away, and never frees." so it's by design. Ok, makes sense ;) Bit
Comparison page on wikibooks C++ Programming/Programming Languages/Comparisons/D
Today, as I was browsing around the C++ Programming pages on wikibooks looking for inspiration, I noticed that the comparison page between C++ and D was quite outdated: https://en.wikibooks.org/w/index.php?title=C%2B%2B_Programming/Programming_Languages/Comparisons/D&oldid=2129832 So I decided to update it: https://en.wikibooks.org/w/index.php?title=C%2B%2B_Programming/Programming_Languages/Comparisons/D It's far from complete, but at least it is tolerable now :D If you find any issues you can report them in this thread, or you can fix them directly in the wiki. I am not a native English-speaker and my writing skills aren't good. Also this is my first (or at most second) time writing a wiki page, so there maybe other issues I didn't think of. I really enjoy using D, so I decided to help with this little thing :)
Re: version: multiple conditions
On Sunday, 14 June 2015 at 16:53:19 UTC, bitwise wrote: It's not just about the code increase though. What if I need AndroidOrWP8, and I also need Win32OrWin64? This can quickly become a much larger pita. Yes, I think this is related to person-specific experiences. Some people insist on keeping all OS-specific code in separate files, others don't… A person with this mindset would version(Windows) to get to a Windows file and then version on Win32 etc in that file… Not saying it is better, but I think that is why people think differently about this issue. True. Maybe I'm underestimating the amount of effort that is going into this. I admit I don't know much about whats going on with the DDMD stuff. Me neither. I just know that I have lost interest in the C++ version of DMD now that there is a move towards D. And I look forward to see an idiomatic D version. I guess only people who know the codebase very well can do that refactoring so let's not tempt them into fixing minor language issues, that's my thinking. Refactoring is kinda tedious… so I'm sure it would be easy to distract anyone into adding more features instead. ;-)
DMD memory management
I'm trying to mod dmd, and I'm totally confused about what's goin on. -some things are allocated with 'new' and some are allocated with 'mem.malloc' -most things don't ever seem to be freed -no RAII is used for cleanup -no clear ownership of pointers How does memory get cleaned up? Is it just assumed that the process is short-lived, and that memory can just be left dangling until it terminates? Thanks, Bit
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 15:15:38 UTC, Ilya Yaroshenko wrote: A naive basic matrix library is simple to write, I don't need standard library support for that + I get it to work the way I want by using SIMD registers directly... => I probably would not use it if I could implement it in less than 10 hours. A naive std.algorithm and std.range is easy to write too. I wouldn't know. People have different needs. Builtin for-each-loops, threads and SIMD support are more important to me than iterators (ranges). But the problem with linear algebra is that you might want to do SIMD optimized versions where you calculate 4 equations at the time, do reshuffling etc. So a library solution has to provide substantial benefits.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 18:05:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 15:15:38 UTC, Ilya Yaroshenko wrote: A naive basic matrix library is simple to write, I don't need standard library support for that + I get it to work the way I want by using SIMD registers directly... => I probably would not use it if I could implement it in less than 10 hours. A naive std.algorithm and std.range is easy to write too. I wouldn't know. People have different needs. Builtin for-each-loops, threads and SIMD support are more important to me than iterators (ranges). But the problem with linear algebra is that you might want to do SIMD optimized versions where you calculate 4 equations at the time, do reshuffling etc. So a library solution has to provide substantial benefits. Yes, but it would be hard to create SIMD optimised version. What do you think about this chain of steps? 1. Create generalised (only type template and my be flags) BLAS algorithms (probably slow) with CBLAS like API. 2. Allow users to use existing CBLAS libraries inside generalised BLAS. 3. Start to improve generalised BLAS with SIMD instructions. 4. And then continue discussion about type of matrixes we want...
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 10:03:06 UTC, Jonathan M Davis wrote: On Sunday, 7 June 2015 at 08:59:46 UTC, Iain Buclaw wrote: I wouldn't have thought that not moving to 2.067 would be a hold-up (there is nothing in that release that blocks building DDMD as it is *now*). The biggest problem is that releasing a ddmd which is compiled with dmd is unacceptable, because it incurs too large a performance hit (~20% IIRC), so we need either ldc or gdc to be at 2.067 so that we can use that to compile the release build of ddmd. after playing around with ddmd built with ldc, it's still a solid 30-40% slower than current dmd(with optimization flags, obv.) after profiling, it spends most of its time swapping and handling page faults. Enabling the GC seems to crash it, oh well. Maybe 20-30% of the actual time is doing non-allocation related things.
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 18:49:21 UTC, Ilya Yaroshenko wrote: Yes, but it would be hard to create SIMD optimised version. Then again clang is getting better at this stuff. What do you think about this chain of steps? 1. Create generalised (only type template and my be flags) BLAS algorithms (probably slow) with CBLAS like API. 2. Allow users to use existing CBLAS libraries inside generalised BLAS. 3. Start to improve generalised BLAS with SIMD instructions. 4. And then continue discussion about type of matrixes we want... Hmm… I don't know. In general I think the best thing to do is to develop libraries with a project and then turn it into something more abstract. If I had more time I think I would have made the assumption that we could make LDC produce whatever next version of clang can do with pragmas/GCC-extensions and used that assumption for building some prototypes. So I would: 1. protoype typical constructs in C, compile it with next version of llvm/clang (with e.g. 4xloop-unrolling and try different optimization/vectorizing options) the look at the output in LLVM IR and assembly mnemonic code. 2. Then write similar code with hardware optimized BLAS and benchmark where the overhead between pure C/LLVM and BLAS calls balance out to even. Then you have a rough idea of what the limitations of the current infrastructure looks like, and can start modelling the template types in D? I'm not sure that you should use SIMD directly, but align the memory for it. Like, on iOS you end up using LLVM subsets because of the new bitcode requirements. Ditto for PNACL. Just a thought, but that's what I would I do.
Re: DIP80: phobos additions
Another thing worth noting is that I believe Intel has put some effort into next gen (?) LLVM/Clang for autovectorizing into AVX2. It might be worth looking into as it uses a mask that allows the CPU to skip computations that would lead to no change, but I think it is only available on last gen Intel CPUs. Also worth keeping in mind is that future versions of LLVM will have to deal with GCC extensions and perhaps also Clang pragmas. So maybe take a look at: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors and http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations ?
Re: Honey, I shrunk the build times
I think the way is fix all memory operations which cause UB and enable GC.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote: On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote: Generally, if we stick to the pay-as-you-go approach most features of D runtime (even exceptions and RTTI) can be ported. They will not imply any costs when not used, but will be ready to use out-of-the-box when they're needed. I haven't had a pay-as-you-go experience with RTTI. In fact TypeInfo has become my mortal enemy [1]. I submitted a bug report for now [2]. [1] TypeInfo not garbage collected (discussion) - http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org [2] TypeInfo not garbage collected (bug report) - http://bugzilla.gdcproject.org/show_bug.cgi?id=184 There is an implementation of an -fno-rtti switch [3], but unfortunately, I have found it compromises on a few things (slicing, postblit, and maybe others). I think the best way forward is to move TypeInfo to the runtime as described in [4]. I'm currently working on an initial pull request for it, but I have to admit that I don't know much about what I'm doing in the compiler and am struggling with it. But I'm afraid if I don't do it, it won't happen. I can't even continue with my work without it. [3] -fno-rtti implementation - https://github.com/D-Programming-GDC/GDC/pull/100 [4] Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270 If there's anything I can help with, let me know. My experience with GDC is close to non-existent (I managed to make some one-line hacks to make it compile for AVR or to show the sizes of TypeInfos, but that was pretty easy), and I didn't even bother to build LDC, but I want to write stuff for STMs in D so I'm motivated to learn by doing. I'll try to push this work on github later this week. I look forward to seeing it. It's encouraging to see more interest in using D for this Domain. Here it is: https://github.com/epi/dirt It's just a playground where I try adding different features by trial and error, so it's very far from being as clean and organized as your projects. I wouldn't even start without your and Adam Ruppe's work, so thank you for that. Apart from first steps towards formatted print and exception support I mentioned earlier, there's a try on running static constructors (which is most likely broken anyway) in the correct order. The machinery used to make it work wastes some text and data memory to do it in run time, but since we're linking everything statically in the end, I wonder if the linker could be forced to put it all together instead.
Re: Tip: unittest-only artifacts should not be version(unittest) if used across modules
On Friday, 12 June 2015 at 19:20:41 UTC, Jeremy Powers wrote: On Thu, Jun 11, 2015 at 11:09 PM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: Just ran into this with Phobos: https://github.com/D-Programming-Language/phobos/pull/3403 If unittest-only artifacts are not constrained to just unittest builds, does this not make them open to be not unittest-only? That is to say, if there is a method or whatever that is just for tests, without marking it 'version(unittest)' how do you ensure it is not actually used in the regular, shipped code? Not sure best way to solve the across-module problem and still keep test code restricted to tests... maybe instead put the shared test code in its own module, and import with version(unittest). I encountered a similar problem a few days ago and what Jeremy proposes seems the most reasonable solution for me.
Re: std.(experimental.)logger voting manager wanted
I've started exploring the use of std.experimental.logger for my std.database work. Presumably it would get in before std.database. What does "finalize reference counting" mean? (discussion thread?) Is it about RefCounted? I'm using that extensively. erik
Re: DIP80: phobos additions
1. Create generalised (only type template and my be flags) BLAS algorithms (probably slow) with CBLAS like API. See [1] (the Matmul benchmark) Julia Native is probably backed with Intel MKL or OpenBLAS. D version was optimized by Martin Nowak [2] and is still _much_ slower. 2. Allow users to use existing CBLAS libraries inside generalised BLAS. I think a good interface is more important than speed of default implementation (at least for e.g large matrix multiplication). Just use existing code for speed... Goto's papers about his BLAS: [3][4] Having something a competitive in D would be great but probably a lot of work. Without a good D interface dstep + openBLAS/Atlas header will not look that bad. Note I am not talking about small matrices/graphics. 3. Start to improve generalised BLAS with SIMD instructions. nice, but not really important. Good interface to existing high quality BLAS seems more important to me than fast D linear algebra implementation + CBLAS like interface. 4. And then continue discussion about type of matrixes we want... +1 2. Then write similar code with hardware optimized BLAS and benchmark where the overhead between pure C/LLVM and BLAS calls balance out to even. may there are more important / beneficial things to work on - assuming total time of contributors is fix and used for other D stuff:) [1] https://github.com/kostya/benchmarks [2] https://github.com/kostya/benchmarks/pull/6 [3] http://www.cs.utexas.edu/users/flame/pubs/GotoTOMS2.pdf [4] http://www.cs.utexas.edu/users/pingali/CS378/2008sp/papers/gotoPaper.pdf
Re: DIP80: phobos additions
On Sunday, 14 June 2015 at 21:31:53 UTC, anonymous wrote: 2. Then write similar code with hardware optimized BLAS and benchmark where the overhead between pure C/LLVM and BLAS calls balance out to even. may there are more important / beneficial things to work on - assuming total time of contributors is fix and used for other D stuff:) Sure, but that is what I'd do if I had the time. Get a baseline for what kind of NxN sizes D can reasonably be expected to deal with in a "naive brute force" manner. Then consider pushing anything beyond that over to something more specialized. *shrugs*
Re: Scaling rdmd up: build package at a time
On Saturday, 6 June 2015 at 20:27:12 UTC, anonymous wrote: The seemingly obvious thing to do: Pass the source files that need rebuilding and the object files of other modules to one dmd invocation. I implemented this. Preliminary pull request: https://github.com/D-Programming-Language/tools/pull/170
Re: Phobos addition formal review: std.experimental.allocator
On Sunday, 14 June 2015 at 14:30:00 UTC, Andrei Alexandrescu
wrote:
Interesting. Do you have a repro for this? Thanks! -- Andrei
Not yet, but while looking for one I found that this code
triggers an assertion in Region.expand()
```
module test;
import std.experimental.allocator;
import std.stdio;
private alias AllocatorType = CAllocatorImpl!(AllocatorList!(
n => Region!Mallocator(1024 * 4), NullAllocator));
struct Big {
ubyte[1024] bytes;
}
void main(string[] args){
auto a = new AllocatorType;
foreach (i; 0 .. 100) {
a.make!Big();
writeln(i);
}
}
```
Current D grammar
With my favorite LALR-CompilerCompiler I analyzed the current D grammar. After preliminary eliminating the RR-conflicts around 1800 states remained, from which around 100 states are still contaminated with SR-conflicts. Two possibilities: 1) Those ambiguities are not in DMD but introduced by excerpting the grammar from DMD 2) Those ambiguities do exist in DMD. Which one do you prefer? Is the grammar usable? -manfred
Re: Honey, I shrunk the build times
On Sunday, 14 June 2015 at 19:02:59 UTC, weaselcat wrote: after playing around with ddmd built with ldc, it's still a solid 30-40% slower than current dmd(with optimization flags, obv.) How did you build it? This is especially important given that DDMD straight from the repo does not build with LDC right now as it tries to override the druntime memory allocation functions, which works only due to the way DMD's -lib is implemented. On a system with 64 GiB RAM, Daniel and I could not measure any performance difference to the C++ version when building the Phobos unittests. - David
Re: Comparison page on wikibooks C++ Programming/Programming Languages/Comparisons/D
On Sunday, 14 June 2015 at 17:23:56 UTC, ZombineDev wrote: Today, as I was browsing around the C++ Programming pages on wikibooks looking for inspiration, I noticed that the comparison page between C++ and D was quite outdated: https://en.wikibooks.org/w/index.php?title=C%2B%2B_Programming/Programming_Languages/Comparisons/D&oldid=2129832 So I decided to update it: https://en.wikibooks.org/w/index.php?title=C%2B%2B_Programming/Programming_Languages/Comparisons/D It's far from complete, but at least it is tolerable now :D If you find any issues you can report them in this thread, or you can fix them directly in the wiki. I am not a native English-speaker and my writing skills aren't good. Also this is my first (or at most second) time writing a wiki page, so there maybe other issues I didn't think of. I really enjoy using D, so I decided to help with this little thing :) Nice work! D-related wiki definitely needs some love. Do you have any plans on improving actual D article (https://en.wikipedia.org/wiki/D_%28programming_language%29)
Re: Current D grammar
On Monday, 15 June 2015 at 00:05:59 UTC, Manfred Nowak wrote: With my favorite LALR-CompilerCompiler I analyzed the current D grammar. After preliminary eliminating the RR-conflicts around Isn't the parser LL(*) or something? You could try ANTLR which generate LL(*) parsers.
