Re: Channels for tasks?
On Thursday, 18 July 2013 at 17:55:36 UTC, Sean Kelly wrote: On Jul 18, 2013, at 8:28 AM, Matt wrote: Hi guys, I know this will have probably been answered before, but does D have a concept similar to Go's channels when it comes to tasks? I believe (according to a few forum posts hinting at it) that such a thing exists for threads, but not for the lightweight tasks provided by std.parallelism. Are there any plans to add such a feature to the library? Not as such. I'd like to make Fibers each have their own message queue in std.concurrency, but that means making TLS work at the fiber level, which is tricky. Yes please yes. Did I said yes yet ? I think there is value in the CSP model (ie. channels), but haven't done anything about it in terms of library work.
Re: Channels for tasks?
On Thursday, 18 July 2013 at 19:08:25 UTC, Sean Kelly wrote: Functionally, fibers are coroutines. They have their own stack and execute within the context of the calling thread. Most languages that scale to thousands or millions of concurrent threads/processes use fibers (often called "green threads" in this context) to pull it off. The obstacle for D is that global data is thread-local by default, so if we were to use fibers in the back-end to allow the creation of a large number of "threads", fibers would basically need their own TLS to avoid breaking code. We already do in-library TLS for OSX and so it shouldn't be terribly difficult to use this logic for fibers, but things get tricky once you consider dynamic libraries. It really should happen at some point though, for std.concurrency to operate at its full potential. My take is that we should keep fibers as they are. But change Thread (as the class in the runtime) to be Fibers with FLS and then let the runtime operate system thread and schedule Thread on them. The read system thread can still be provided in some dark corner of the standard lib or runtime.
Re: Deimos need some works
On Thursday, 18 July 2013 at 06:10:45 UTC, Joseph Rushton Wakeling wrote: On 07/17/2013 11:00 PM, Jonathan M Davis wrote: I think that my biggest gripe with how Deimos is set up is that the folks who manage the projects in there aren't in control of them. So, they can't merge anything themselves or do other git commands such as tagging or branching. Is it not possible to set up something where (i) Deimos library devs create a 'home repo' for their project, which can be a personal repo, a group repo, or even something not on GitHub if they prefer (ii) Deimos project repos just do a regular, automated clone/pull from the specified home repo. An alternative method is to use git submodules and let the people who wish to maintain bindings to have it as a submodule of a deimos repo. That way they are linked in nice forms from a central location.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote: This has turned into a monster. We've taken 2 or 3 wrong turns somewhere. Progressively, I start considering this as a not-so-bad idea. Anyway, the issue of @property should be cleared up. The current state of affairs is poisoning the language.
Re: SIMD ideas for Rust
Manu:
Interesting. Almost all his points are what we do already in D.
Always nice to see others come to the same conclusions :)
While trying to write a multiplication of two complex numbers
using SSE3 with LDC2 I have found about seven or more bugs, that
I will discuss elsewhere. But regarding the syntax, in nice code
like this D requires to add ".array" before all those subscripts
(code adapted from Fog):
double2 complexMult(in double2 a, in double2 b) pure nothrow {
double2 b_flip = [b.array[1], b.array[0]];
double2 a_im = [a.array[1], a.array[1]];
double2 a_re = [a.array[0], a.array[0]];
double2 aib = a_im * b_flip;
double2 arb = a_re * b;
return [arb.array[0] - aib.array[0], arb.array[1] +
aib.array[1]];
}
A line like this:
double2 b_flip = [b.array[1], b.array[0]];
becomes something like:
pshufd $238, %xmm1, %xmm3
Similarly all the other lines become single instructions (but the
last one, because LDC2 misses to use a addsubpd).
I vaguely remember you saying that slow SIMD operations shouldn't
have a too much short syntax to avoid giving an illusion of
efficiency. But given that "often" the CPU executes such array
subscripting and shuffling efficiently, isn't it nicer/enough to
support a simpler syntax like this in D?
double2 complexMult(in double2 a, in double2 b) pure nothrow {
double2 b_flip = [b[1], b[0]];
double2 a_im = [a[1], a[1]];
double2 a_re = [a[0], a[0]];
double2 aib = a_im * b_flip;
double2 arb = a_re * b;
return [arb[0] - aib[0], arb[1] + aib[1]];
}
Bye,
bearophile
Re: Interesting Research Paper on Constructors in OO Languages
On Thu, 18 Jul 2013 19:00:44 +0100, H. S. Teoh
wrote:
On Thu, Jul 18, 2013 at 10:13:58AM +0100, Regan Heath wrote:
On Wed, 17 Jul 2013 18:58:53 +0100, H. S. Teoh
wrote:
[...]
>I guess my point was that if we boil this down to the essentials,
>it's basically the same idea as a builder pattern, just implemented
>slightly differently. In the builder pattern, a separate object (or
>struct, or whatever) is used to encapsulate the state of the object
>that we'd like it to be in, which we then pass to the ctor to create
>the object in that state. The idea is the same, though: set up a
>bunch of values representing the desired initial state of the object,
>then, to borrow Perl's terminology, "bless" it into a full-fledged
>class instance.
It achieves the same ends, but does it differently. My idea requires
compiler support (which makes it unlikely to happen) and doesn't
require separate objects (which I think is a big plus).
Why would requiring separate objects be a problem?
It's not a problem, it's just better not to, if at all possible. K.I.S.S.
:)
In my case, the derived class ctor could manually set some of the fields
in Args before handing to the superclass. Of course, it's not as ideal,
since if user code already sets said fields, then they get silently
overridden.
That's the problem I was imagining.
Also, in your approach there isn't currently any enforcement that
the user sets all the mandatory parameters of Args, and this is
kinda the main issue my idea solves.
True. One workaround is to use Nullable and check that in the ctor. But
I suppose it's not as great as a compile-time check.
Yeah, I was angling for a static/compile time check, if at all possible.
>Whereas using my approach, you can simply reuse the Args struct
>several times:
>
>C.Args args;
>args.name = "test1";
>args.age = 12;
>args.school = "D Burg High School";
>auto obj1 = new C(args);
>
>args.name = "test2";
>auto obj2 = new C(args);
>
>args.name = "test3";
>auto obj3 = new C(args);
>
>... // etc.
Or.. you use a mixin, or better still you add a copy-constructor or
.dup method to your class to duplicate it :)
But then you end up with the problem of needing to call set methods
after the .dup
Which is no different to setting args.name beforehand, the same number of
assignments. In the example above it's N+1 assignments, N args or dup'ed
members and 1 more for 'name' before or after the construction.
which may complicate things if the set methods need to
do non-trivial initialization of internal structures (caches or internal
representations, etc.).
Ahh, yes, and in this case you'd want to use the idea below, where you
call a method to set the common parts and manually set the differences.
Whereas if you hadn't needed to .dup, you could
have gotten by without writing any set methods for your class, but now
you have to.
create-set-call <- 'set' is kinda an integral part of the whole thing :P
[...]
In my case you can call different functions in the initialisation
block, e.g.
void defineObject(C c)
{
c.school = "...);
}
C c = new C() {
defineObject()
}
:)
So the compiler has to recursively traverse function calls in the
initialization block in order to check that all required fields are set?
Yes. This was an off the cuff idea, but it /is/ a natural extension of
the idea for the compiler to traverse the setters called inside the
initialisation block, and ctors in the hierarchy, etc.
That could have entail some implementational issues, if said function
calls can be arbitrarily complex. (If you have complex control logic in
said functions, the compiler can't in general determine whether or not
some paths will/will not be taken that may assignment statements to the
object's fields, since that would be equivalent to the halting problem.
All true. The compiler has a couple of options to (re)solve these issues:
1. It could simply baulk at the complexity and error.
2. It could take the safe route and assume those member assignments it
cannot verify are uninitialised, forcing manual init.
In fact, erroring at complexity might make for better code in many ways.
You would have to perform your complex initialisation beforehand, store
the result in a variable, and then construct/initblock your object.
It does limit your choice of style, but create-set-call already does that
.. and I'm not immediately against style limitations assuming they
actually result in better code.
Worse, the compiler would have to track aliases of the object being set,
in order to know which assignment statements are setting fields in the
object, and which are just computations on the side.)
No, aliasing would simply be ignored. In fact, calling a setter on
another object in an initblock should probably be an error. Part of the
whole "don't mix initialisation" goal I started with. It does require
strict properties.
Furthermore, what if def
Re: Hopefully not-too-obvious observation
Am Wed, 17 Jul 2013 22:50:09 -0400
schrieb Jerry :
> Hi folks,
>
> I was looking at writing a hash-like class with a specific operator and
> disliking the syntax of:
>
> T opBinary(string op)(U key) if (op == "in") {}
>
> When it occurred to me that it could be simply tightened up as:
>
> T opBinary(string op : "in")(U key) {}
>
> Any thoughts? Is this bad style?
>
> Thanks
> Jerry
I write it like that, too. It's more readable with the "in"
closer to the method name.
--
Marco
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Thursday, 18 July 2013 at 10:26:24 UTC, Kagamin wrote: llvm should be platform-independent enough, so you have ldc. But the problem with D is that it has more features than C/C++, so if you output C code you can only use C features, or you have to implement druntime+phobos for the target platform, which doesn't come for free. I think a C backend would get us farther than an LLVM backend. Imagine targeting one of the ubiquitous ARM targets like Android, and its gazillion variants. LLVM has an ARM target I'm pretty sure, but the Android community uses GCC as their compiler. This puts LLVM/LDC on Android into a "may or may not work" category (unless they've done it already while I wasn't looking). Emitting C/C++ code and feeding it to the Android NDK though: that will work for sure, or at least land incredibly close. Rinse and repeat for PIC, Cypress, iPhone, XBox (any of them), Wii, Ouya, PS3, PS4, 3DS, and whatever else might come out a year from now. I suspect that LLVM will be missing support for a bunch of those, and lag new platforms significantly; not unless it just happens to exist in their "ecosystem". I think that LLVM might have a maintained C backend again. It had been unmaintained/unsupported for a while. If someone thinks that using LLVM's C backend makes more sense, then they should do it with LDC. I'd be really happy about it, because I want that functionality. I am not interested in using LLVM as my /first/ backend in xdc for a combination of the above reasons and their implications: .- LLVM emitting native code for xdc will require someone .knowledgable with LLVM to set things up and potentially .spend time on it if the target platform requires tweaking. .Getting handed a file full of C code requires only knowledge .of how to use the C compiler on the target system. .- LLVM emitting C code should probably be done by ldc instead. .- LLVM emitting C code would also add unnecessary layers: .D->AST->LLVM_IR->C vs D->AST->C. .This extra layer can lose information. You are right that druntime+phobos don't come for free. Doing complete ports of those to platform X is outside the scope of this project. I do intend to salvage whatever parts of them I can in a portable manner. Moreover, I intend xdc to have the capability to toggle druntime/phobos features on and off easily based on existing support for the intended platform. The C-Windows target would probably have more druntime/phobos features enabled than C-Android target. I'd like to make sure that anyone can use what's available, and if not, still be allowed to access the platform. I don't think it makes sense that I'd be completely unable to write iPhone code just because there isn't GC/threading code available for it in the runtime yet; I should be able to do some non-trivial things without those. Note that a reference-counting implementation would be portable everywhere that doesn't have a native GC, so you'd never have anything less than that (unless you intentionally ditched it, ex: memory limited microcontrollers where things are statically allocated anyways). To be more concrete, I intend to make it possible to invoke xdc with "hints", like so: xdc --emit=C89 --hostc=gcc --os=windows --threads=pthreads main.d # Breakdown: # --emit=C89 causes C89 compliant code to be emitted. # --hostc=gcc causes xdc to feed the C89 code to gcc (mingw). # --os=windows causes xdc to use WinAPI by default for # for implementing druntime and platform-specific language # features. # --threads=pthreads overrides the use of Windows threads; # posix threads are used instead. # This combination could probably land GC+threading and mesh well # with a mingw environment. Alternatively, it could be invoked like this: xdc --emit=C89 main.d # This will generate some very conservative C89 code. # You will have refcounting instead of GC, and thread spawning # won't work. # However, you'll have some really freakin' portable code! Even with a conservative target like C89-only, there are still an incredibly large number of extremely useful D features (OOP, templates, scope(exit), CTFE, mixins, ranges, op-overloading, etc) that DO come for free. These can be lowered into C code that does the same thing but looks uglier. Such lowered code would take much longer for a human to write and become tedious to maintain, but a compiler can do it tirelessly.
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote: Even with a conservative target like C89-only, there are still an incredibly large number of extremely useful D features (OOP, templates, scope(exit), CTFE, mixins, ranges, op-overloading, etc) that DO come for free. I love the idea behind xdc, but I would go with C99 instead, even MS as the last vendor(?), with VS2013 now finally committed to supporting C99, variable length arrays alone would make it worth it.
Re: SIMD ideas for Rust
On 19 July 2013 19:33, bearophile wrote:
> Manu:
>
> Interesting. Almost all his points are what we do already in D.
>> Always nice to see others come to the same conclusions :)
>>
>
> While trying to write a multiplication of two complex numbers using SSE3
> with LDC2 I have found about seven or more bugs, that I will discuss
> elsewhere. But regarding the syntax, in nice code like this D requires to
> add ".array" before all those subscripts (code adapted from Fog):
>
>
> double2 complexMult(in double2 a, in double2 b) pure nothrow {
> double2 b_flip = [b.array[1], b.array[0]];
> double2 a_im = [a.array[1], a.array[1]];
> double2 a_re = [a.array[0], a.array[0]];
> double2 aib = a_im * b_flip;
> double2 arb = a_re * b;
> return [arb.array[0] - aib.array[0], arb.array[1] + aib.array[1]];
> }
>
>
> A line like this:
>
> double2 b_flip = [b.array[1], b.array[0]];
>
> becomes something like:
>
> pshufd $238, %xmm1, %xmm3
>
> Similarly all the other lines become single instructions (but the last
> one, because LDC2 misses to use a addsubpd).
>
> I vaguely remember you saying that slow SIMD operations shouldn't have a
> too much short syntax to avoid giving an illusion of efficiency. But given
> that "often" the CPU executes such array subscripting and shuffling
> efficiently, isn't it nicer/enough to support a simpler syntax like this in
> D?
>
> double2 complexMult(in double2 a, in double2 b) pure nothrow {
> double2 b_flip = [b[1], b[0]];
> double2 a_im = [a[1], a[1]];
> double2 a_re = [a[0], a[0]];
> double2 aib = a_im * b_flip;
> double2 arb = a_re * b;
> return [arb[0] - aib[0], arb[1] + aib[1]];
> }
>
The point about eliminating the index operator is because it implies a
vector->float cast.
You want to perform a shuffle(/swizzle), but you are only really performing
the operation incidentally.
What you're really doing is casting a bunch of vector components to floats,
and then rebuilding a vector, and LLVM can helpfully deal with that.
I would suggest calling a spade a spade and using a swizzle function to
perform a swizzle, instead of code like what you wrote.
Wouldn't this be better:
double2 complexMult(in double2 a, in double2 b) pure nothrow {
double2 b_flip = b.yx; // or b.swizzle!"yx", if we don't want to
include an opDispatch in the basic type
double2 a_im = a.yy;
double2 a_re = a.xx;
double2 aib = a_im * b_flip;
double2 arb = a_re * b;
//return [arb[0] - aib[0], arb[1] + aib[1]]; // this final line is
tricky... it's not very portable.
// Maybe:
return select([-1, 0], arb-aib, arb+aib);
// Hopefully the x86 optimiser will generate the proper opcode. Or a
bunch of other options; a multi-vector shuffle, shift, swizzle, interleave.
}
I think that would be better. More portable, and it eliminates the code
that implies a vector->float->vector cast sequence, which I maintain,
should be syntactically discouraged at all costs.
You don't want to be giving people bad ideas that it's reasonable code to
write ;)
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote: Imagine targeting one of the ubiquitous ARM targets like Android, and its gazillion variants. LLVM has an ARM target I'm pretty sure, but the Android community uses GCC as their compiler. This puts LLVM/LDC on Android into a "may or may not work" category (unless they've done it already while I wasn't looking). A small correction, the Android NDK added clang/llvm support last November in revision 8c: http://developer.android.com/tools/sdk/ndk/index.html gcc is still the default, but clang is an alternative option. I don't think ldc has been ported to use whatever llvm libraries the NDK is providing, but there is some official support for llvm on Android now.
Re: Module visibility feature?
On Thursday, 18 July 2013 at 10:55:39 UTC, Dicebot wrote: On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote: So I was reading this: http://wiki.dlang.org/Access_specifiers_and_visibility ... How will it be any different from module foo.barstuff; package: // declarations This is how I handle this situation currently, and was actually part of the inspiration for this idea. Like Tommi said, it makes a very clear distinction between what the user should and shouldn't be able to interact with. A regular module can still be imported, even though everything it would contain has package visibility. Trying to import a package module and getting an error because of it is like having the compiler say, "There's nothing in here for you!" Also, having a way to specify that a module isn't publicly visible could be used for code completion features in IDE's. If foo.barstuff is a package module, typing "import foo." would show "foo.bar" as the onlyoption for modules they can import.
Re: GC.calloc
Am Thu, 18 Jul 2013 13:00:24 +0200 schrieb "Vladimir Panteleev" : > On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote: > > I use it all the time, e.g. I have an array of blocks > > (65536*12Byte) and > > I don't want the GC to care about this chunk of data (since it > > exists up > > to 961 times) but I can't just have it filled with random data > > -> > > calloc. Often when I was relativly new to C I always called > > malloc > > followed by a memset to 0, until I learned about calloc (but > > that's > > getting offtopic). > > calloc may still be useful as a stand-alone function. The > question is whether it makes sense to be part of the GC > interface, which all GCs need to implement. I think it only makes > sense if some GC implementations have knowledge that allows them > to return 0-filled memory without actually filling it all (e.g. > if it is known that the OS does it for them). The calloc implemented in Linux only works like the GC.calloc up to ~24 MiB or so. After that it does neither set anything to zero nor does it allocate physical memory. It just gives you X references to a read-only page filled with zeroes, that is marked copy-on-write. Thus with C calloc you can allocate gigabytes of "zero initialized" memory in an instant. But the real benefit with the C calloc > ~24 MiB is that the memory pages don't consume RAM until you write to them. -- Marco
Re: SIMD ideas for Rust
Manu:
What you're really doing is casting a bunch of vector
components to floats,
and then rebuilding a vector, and LLVM can helpfully deal with
that.
I would suggest calling a spade a spade and using a swizzle
function to
perform a swizzle, instead of code like what you wrote.
Wouldn't this be better:
double2 complexMult(in double2 a, in double2 b) pure nothrow {
double2 b_flip = b.yx; // or b.swizzle!"yx", if we don't
want to
include an opDispatch in the basic type
double2 a_im = a.yy;
double2 a_re = a.xx;
double2 aib = a_im * b_flip;
double2 arb = a_re * b;
I see and you are right.
(If I turn the basic type into a struct containing a double2
aliased-this to the whole structure, the generated code becomes
awful).
A YMM that already contains 8 floats, and probably SIMD registers
will keep growing, maybe to become 1024 bits long. So the swizzle
item names like x y z w will not suffice and some more general
naming scheme is needed.
//return [arb[0] - aib[0], arb[1] + aib[1]]; // this final
line is
tricky... it's not very portable.
// Maybe:
return select([-1, 0], arb-aib, arb+aib);
// Hopefully the x86 optimiser will generate the proper
opcode. Or a
bunch of other options; a multi-vector shuffle, shift, swizzle,
interleave.
}
I think that would be better. More portable, and it eliminates
the code
that implies a vector->float->vector cast sequence, which I
maintain,
should be syntactically discouraged at all costs.
You don't want to be giving people bad ideas that it's
reasonable code to
write ;)
My experience in writing such kind of code is limited. I will try
your select to see what kind of code LDC2-LLVM generates.
Bye,
bearophile
"Is the "D" programming language a better choice over c++?" on Reddit Gamedev
In case you haven't seen it yet. http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/ I did my small contribution referring to Manu's presentations http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/cb64r4l -- Paulo
Re: Official D Grammar
Status update: My parser is at a point where it can parse all of phobos (well, excluding c-style array declarations, which I'm convinced are broken and should be removed from the language). I've been updating the grammar definition as I worked on the parser. An HTML version is available for download here: https://raw.github.com/Hackerpilot/DGrammar/master/grammar.html Lexer, parser, and AST code is available here: https://github.com/Hackerpilot/Dscanner/tree/range-based-lexer/std/d. Bug reports and pull requests are welcome.
Re: Official D Grammar
On Friday, 19 July 2013 at 20:57:14 UTC, H. S. Teoh wrote: Really? Those still exist in Phobos? Shouldn't they be rewritten to the "native" style? Yes. https://github.com/D-Programming-Language/phobos/pull/1412/files
Re: Official D Grammar
On Friday, 19 July 2013 at 20:52:33 UTC, Mr. Anonymous wrote: https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html ;) I learn something new every day.
Re: "Is the "D" programming language a better choice over c++?" on Reddit Gamedev
On Friday, 19 July 2013 at 18:56:39 UTC, Paulo Pinto wrote: In case you haven't seen it yet. http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/ I did my small contribution referring to Manu's presentations http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/cb64r4l -- Paulo That's pretty exciting! Having people consider D a viable option for game development is very good exposure. I wonder how many people never heard of D until after they saw that post?
Re: Official D Grammar
On Friday, 19 July 2013 at 20:49:27 UTC, Brian Schott wrote: Status update: My parser is at a point where it can parse all of phobos (well, excluding c-style array declarations, which I'm convinced are broken and should be removed from the language). I've been updating the grammar definition as I worked on the parser. An HTML version is available for download here: https://raw.github.com/Hackerpilot/DGrammar/master/grammar.html Lexer, parser, and AST code is available here: https://github.com/Hackerpilot/Dscanner/tree/range-based-lexer/std/d. Bug reports and pull requests are welcome. https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html ;)
Re: Official D Grammar
On Fri, Jul 19, 2013 at 10:49:25PM +0200, Brian Schott wrote: > Status update: > > My parser is at a point where it can parse all of phobos (well, > excluding c-style array declarations, which I'm convinced are broken > and should be removed from the language). Really? Those still exist in Phobos? Shouldn't they be rewritten to the "native" style? > I've been updating the grammar definition as I worked on the parser. > An HTML version is available for download here: > https://raw.github.com/Hackerpilot/DGrammar/master/grammar.html > > Lexer, parser, and AST code is available here: > https://github.com/Hackerpilot/Dscanner/tree/range-based-lexer/std/d. > Bug reports and pull requests are welcome. Wonderful! I'll have to look into this sometime. I've been dreaming about writing a D pretty-printer, and this may be just the thing I need to get it going. :) (Well actually, I *wrote* a D pretty-printer, but I only got as far as lexing, with some token-matching rules for the pretty-printing. Needless to say, the results were rather underwhelming, since I didn't have an AST to work with.) T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Re: Official D Grammar
Am Fri, 19 Jul 2013 22:49:25 +0200 schrieb "Brian Schott" : > Status update: > > My parser is at a point where it can parse all of phobos (well, > excluding c-style array declarations, which I'm convinced are > broken and should be removed from the language). > > I've been updating the grammar definition as I worked on the > parser. An HTML version is available for download here: > https://raw.github.com/Hackerpilot/DGrammar/master/grammar.html > > Lexer, parser, and AST code is available here: > https://github.com/Hackerpilot/Dscanner/tree/range-based-lexer/std/d. > Bug reports and pull requests are welcome. Nice work! I guess you already tried druntime but did you also run your lexer and or parser against the dmd test suite? The test suite probably has quite some old legacy stuff like c-style array declarations so it might be a pita to run those tests but it might show some real problems as well. If you wanted to do more testing you could also run it on some well-maintained big D projects (GTKd, derelict3, ...) http://wiki.dlang.org/Libraries_and_Frameworks http://wiki.dlang.org/Open_Source_Projects It's also nice that we may finally get a correct and complete grammar. BTW: I think it might be a good idea to start a new thread for this update. This stuff is quite important for D/phobos and usually old threads tend to be ignored or get less attention.
Re: SIMD ideas for Rust
On 20 July 2013 03:43, bearophile wrote:
> Manu:
>
> What you're really doing is casting a bunch of vector components to
>> floats,
>> and then rebuilding a vector, and LLVM can helpfully deal with that.
>>
>> I would suggest calling a spade a spade and using a swizzle function to
>> perform a swizzle, instead of code like what you wrote.
>> Wouldn't this be better:
>>
>> double2 complexMult(in double2 a, in double2 b) pure nothrow {
>> double2 b_flip = b.yx; // or b.swizzle!"yx", if we don't want to
>> include an opDispatch in the basic type
>> double2 a_im = a.yy;
>> double2 a_re = a.xx;
>> double2 aib = a_im * b_flip;
>> double2 arb = a_re * b;
>>
>
> I see and you are right.
>
> (If I turn the basic type into a struct containing a double2
> aliased-this to the whole structure, the generated code becomes
> awful).
>
> A YMM that already contains 8 floats, and probably SIMD registers
> will keep growing, maybe to become 1024 bits long. So the swizzle
> item names like x y z w will not suffice and some more general
> naming scheme is needed.
Swizzling bytes already has that problem. Hexadecimal swizzle strings work
nicely up to 16 elements, but past that, I'd probably require the template
receive a tuple of int's.
These are trivial details. .xyzw are particularly useful for 2-4d vectors.
They can be removed for anything higher. The nicest/most preferred
interface can be decided with experience.
As yet there's not a lot of practical experience with >128bit registers,
and the sorts of patterns that appear frequently.
//return [arb[0] - aib[0], arb[1] + aib[1]]; // this final line is
>> tricky... it's not very portable.
>>
>> // Maybe:
>> return select([-1, 0], arb-aib, arb+aib);
>> // Hopefully the x86 optimiser will generate the proper opcode. Or a
>> bunch of other options; a multi-vector shuffle, shift, swizzle,
>> interleave.
>> }
>>
>> I think that would be better. More portable, and it eliminates the code
>> that implies a vector->float->vector cast sequence, which I maintain,
>> should be syntactically discouraged at all costs.
>> You don't want to be giving people bad ideas that it's reasonable code to
>> write ;)
>>
>
> My experience in writing such kind of code is limited. I will try
> your select to see what kind of code LDC2-LLVM generates.
>
It probably won't be good because I haven't paid attention to how it
optimises on SSE yet.
You need to encourage the compiler to generate ADDSUBPD for SSE, and any
(or none) of the possible expressions may result in it choosing the proper
opcode.
I'm apprehensive to add a helper function for that operation, since it's
dreadfully SSE-specific. It's the sort of thing where you might rather
carefully make sure the standard API will reliably encourage the optimiser
to do it.
If you can find a pattern of operations that optimises to ADDSUBPD, I'm
interested to know what the sequence(/s) are.
If not, we'll consider an explicit function. It can be emulated within
reason on other architectures, but I think it would be better to work a
different solution though. Ie, perform 2 (or 4) side by side (stream
processing)... That will work well on all architectures.
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 15:39:36 UTC, Tove wrote:
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote:
Even with a conservative target like C89-only, there are still
an incredibly large number of extremely useful D features
(OOP, templates, scope(exit), CTFE, mixins, ranges,
op-overloading, etc) that DO come for free.
I love the idea behind xdc, but I would go with C99 instead,
even MS as the last vendor(?), with VS2013 now finally
committed to supporting C99, variable length arrays alone would
make it worth it.
I am, in fact, totally willing to make --emit=C99 do cool things
once I discover what those cool things are. Otherwise it will
probably emit code that is both C89 and C99 compliant.
I feel that most of the D features that can be implemented with a
C99 compiler can be implemented with C89 as well, and C89 might
give more reach into esoteric targets like microcontrollers or
legacy systems.
Maybe I should ask this: what D features are you afraid of losing
due to lowering into C89?
...
I hate to sour whatever cheerful expectations you might have,
but, AFAIK, D doesn't have VLAs. Consequently, I don't think xdc
would need them. I hear that VLA support is becoming optional in
C11 as well, which doesn't bode well for its potential existance
in the future, see
http://en.wikipedia.org/wiki/Variable-length_array
"Programming languages that support VLAs include [...] C99 (and
subsequently in C11 relegated to a conditional feature which
implementations aren't required to support; ..."
It is important to note that even if D /did/ have VLAs, then it
would be possible to lower them into other constructs:
void foo(int n)
{
char[n] vla;
...
}
-= can be emulated by =-
void foo(int n)
{
char[] vla = (cast(char*)std.c.stdlib.malloc(n))[0..n];
scope(exit) std.c.stdlib.free(vla.ptr);
...
}
This would be important for emitting to any language without
VLAs. It could be used if someone wanted to add VLAs to xdc as
an (off-by-default) experimental feature. And of course it
should use "new T[n]" with core.memory.GC.free if the array
contains pointers, or stdlib is unavailable (ex: Java). I would
also expect --emit=C99 to avoid the heap allocation. alloca
might be usable with C89 in some cases, but is very dangerous (in
my experience).
I had a friend of mine who is an expert C programmer poke me
about this C89 vs C99 thing as well. It's strange to me because
I thought that emitting C89 was actually a strong selling point:
you're getting D which is so much more than C99, AND it will
reach all of the old C89 compilers.
If there are still things that you (community inclusive) are
afraid of missing, then I am pretty willing to do C99 instead and
skip C89. I will need to know what they are though, or it won't
make a difference anyway (I can't implement what I don't know
about!).
HTH.
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Friday, 19 July 2013 at 16:42:32 UTC, Joakim wrote: On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote: Imagine targeting one of the ubiquitous ARM targets like Android, and its gazillion variants. LLVM has an ARM target I'm pretty sure, but the Android community uses GCC as their compiler. This puts LLVM/LDC on Android into a "may or may not work" category (unless they've done it already while I wasn't looking). A small correction, the Android NDK added clang/llvm support last November in revision 8c: http://developer.android.com/tools/sdk/ndk/index.html gcc is still the default, but clang is an alternative option. I don't think ldc has been ported to use whatever llvm libraries the NDK is providing, but there is some official support for llvm on Android now. Cool, thanks for the info. It's been a while since I've looked at the Android NDK. It's just not fun to me without D being there ;)
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Thursday, 18 July 2013 at 03:26:10 UTC, Chad Joan wrote: [...] Is the input to xdc a semantically-analyzed D AST, or does semantic analysis occur during pattern-matching/lowering?
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Saturday, 20 July 2013 at 04:38:20 UTC, cal wrote: On Thursday, 18 July 2013 at 03:26:10 UTC, Chad Joan wrote: [...] Is the input to xdc a semantically-analyzed D AST, or does semantic analysis occur during pattern-matching/lowering? The latter. xdc would accept D code as text input (.d files) and parse it to produce its own AST. Semantic analysis is then done by matching patterns in the AST and doing substitutions until all that's left are the AST nodes the backend wants. The backend then matches patterns and emits the desired output (instead of substituting AST nodes).
Re: "Is the "D" programming language a better choice over c++?" on Reddit Gamedev
On Friday, 19 July 2013 at 20:12:21 UTC, Jeremy DeHaan wrote: On Friday, 19 July 2013 at 18:56:39 UTC, Paulo Pinto wrote: In case you haven't seen it yet. http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/ I did my small contribution referring to Manu's presentations http://www.reddit.com/r/gamedev/comments/1imyhy/is_the_d_programming_language_a_better_choice/cb64r4l -- Paulo That's pretty exciting! Having people consider D a viable option for game development is very good exposure. I wonder how many people never heard of D until after they saw that post? i don't wonder, here in my country(second world country if some can say so) people only know what is C#, C++, a bit of Python, a bit of Java, even less for fasm and others, maybe few other relatively new languages, and only very few enthusiasts(!) know and using D, though the others may knew about its existence they are VERY skeptical about it(sure, who needs another C++ done right when we have Java and C# ...). The entire industry here works for Windows and almost every company chooses easy path to use what Microsoft gives. No one really cares about result(though they shouting on every corner exactly opposed thing), process is a must they think. If you can drag and drop a button on a form this is a good language/ide/whatever they think, and i don't blame them, business is business, but that is why i left it for a good reason. I only wish that situation changes with come of solid tools like IDE's(for me now the only usable IDE is VisualD, mono-d is just pita to use at least on mac), major debuggers full support, UI toolkits(maybe even more than anything else) and so on.
Re: xdc: A hypothetical D cross-compiler and AST manipulation tool.
On Saturday, 20 July 2013 at 04:44:38 UTC, Chad Joan wrote: On Saturday, 20 July 2013 at 04:38:20 UTC, cal wrote: On Thursday, 18 July 2013 at 03:26:10 UTC, Chad Joan wrote: [...] Is the input to xdc a semantically-analyzed D AST, or does semantic analysis occur during pattern-matching/lowering? The latter. xdc would accept D code as text input (.d files) and parse it to produce its own AST. Semantic analysis is then done by matching patterns in the AST and doing substitutions until all that's left are the AST nodes the backend wants. The backend then matches patterns and emits the desired output (instead of substituting AST nodes). I'm not sure how you'll handle all compile time features.
