Re: DUB 0.9.21
Am 22.02.2014 13:07, schrieb Sönke Ludwig: Am 22.02.2014 12:24, schrieb Paulo Pinto: Am 22.02.2014 10:44, schrieb Sönke Ludwig: The Windows installer seems not to like being installed via UAC as the Administrator gets the PATH configured, not the user that started the installer. -- Paulo Going by the installer script, it should install to the global PATH (HKEY_LOCAL_MACHINE) variable, not to the user's (or Adminstrator's) one. Are you sure that the latter is the case for you? There is also a ticket to enable per-user installation from unprivileged accounts. I'll try to look into that topic, too, for the next release (need to read up on the proper NSIS options/plugins). Forget my previous post. Apparently it required a reboot to update the user's environment. Thanks again for the good work. -- Paulo
ApplyYourDLang - A YouTube channel for D introduction videos
The cat's out of the bag.. http://www.reddit.com/r/programming/comments/1ypg91/getting_started_with_d_and_vibed/ We didn't want to announce the site before we had more videos, but it has found its way to reddits frontpage.
Re: ApplyYourDLang - A YouTube channel for D introduction videos
On Sunday, 23 February 2014 at 22:07:39 UTC, simendsjo wrote: The cat's out of the bag.. http://www.reddit.com/r/programming/comments/1ypg91/getting_started_with_d_and_vibed/ We didn't want to announce the site before we had more videos, but it has found its way to reddits frontpage. I was really hoping to have ldap support for Cmsed and mysql support in dvorm before making more videos. But oh well :)
Re: Multi-associative array
On Sunday, 23 February 2014 at 07:10:32 UTC, Etienne Cimon wrote:
auto sorted = aa.sort!(Key.y = { a b })
You can't sort an AA, as AAs are unordered. Did you mean to sort
the keys?
auto sorted = aa.keys.sort!((a, b) = a.y b.y)();
auto filtered = aa.filter!
auto filtered = aa.keys.filter!(k = k.y 2).array;
foreach(x, y, z ; aa){
}
foreach (key, value; aa) with(key) {
... use x, y, z ...
}
assert vs. enforce in Phobos code
Hello all, This is a subject I think we've visited before, but I can't find the old discussion threads :-( As some of you know I'm working on a successor to std.random -- it's been put on hold the last 8 weeks or so by country/life/work changes, but now I'm back onto it. One of the things I'm examining in the course of that is the error checking. For example, a call to uniform(a, b) sees the function ensure that the interval is appropriate via an enforce(a = b). The result is that passing the wrong values to uniform() will bring your program down. There are many other comparable cases in the module. Part of me feels this is absolutely right and that such errors should be strictly objected to in this way. On the other hand, this seems a wrong approach given that these kinds of functions are surely going to be called deep within the program -- we're not verifying user input here, it would be a logical error in the program to pass wrong bounds to uniform() and so on. My inclination is to clean this stuff up, to generally replace enforce's with asserts, to provide in- and out-contracts where appropriate, and so on. Thoughts, remarks, ... ? Thanks best wishes, -- Joe
Re: Implement the unum representation in D ?
Hi I will ask my question again. Is there any interest in this format within the D community ? Nick
Re: Implement the unum representation in D ?
On 20 February 2014 22:46, bearophile bearophileh...@lycos.com wrote: Iain Buclaw: Most encoding formats use a form of discrete cosine transform, which involves floating point maths. I don't believe this much :-( :-( I looked up vorbis (very, very) briefly way of example. Most structs that deal with encoding/decoding use integers, floats and doubles to represent values such as decay, attenuation, thresholds, amplification etc.
Move some guides to the DWiki - yay or nay?
E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496
DIP56 Provide pragma to control function inlining
http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution.
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 yay!
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Is this a front-end thing or something specific to DMD? I'm wondering because I'd like something like this for GDC and LCD when targeting ARM microcontrollers. The inline keyword makes quite a significant performance improvement in one of my current C++ projects, and I anticipate the same result when I convert it to D. Any chance of adding a optimize, true/false pragma also to get around the lack of a volatile keyword? (Just a question, I don't mean to hijack this thread and turn into another volatile keyword debate). Mike
Re: DIP56 Provide pragma to control function inlining
Am 23.02.2014 13:07, schrieb Walter Bright: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Why a pragma? Can't we use a UDA and give it some special meaning inside the compiler?
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. yay, all for it! The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. Could we consider adding flatten in the same dip? quote from gcc Flatten Generally, inlining into a function is limited. For a function marked with this attribute, every call inside this function is inlined, if possible. Whether the function itself is considered for inlining depends on its size and the current inlining parameters.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:21 AM, Mike wrote: Is this a front-end thing or something specific to DMD? I'm wondering because I'd like something like this for GDC and LCD when targeting ARM microcontrollers. The inline keyword makes quite a significant performance improvement in one of my current C++ projects, and I anticipate the same result when I convert it to D. It's a hint to the compiler - the compiler is allowed to ignore it if it doesn't support it. Any chance of adding a optimize, true/false pragma also to get around the lack of a volatile keyword? (Just a question, I don't mean to hijack this thread and turn into another volatile keyword debate). Please start another thread with your proposal.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. What if you want to mark a series of functions to be inlined? E.g. in an entire module: - module fast; // ?? pragma(inline, true): Vec vecSum(); Vec vecMul(); - Seems like a solution would be preferred where this can be used for multiple functions. A UDA/@property of some sort.
Re: DIP56 Provide pragma to control function inlining
23-Feb-2014 16:07, Walter Bright пишет: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Why pragma? Also how exactly it is supposed to work: pragma(inline, true); ... //every declaration that follows is forcibly inlined? pragma(inline, false); ... //every declaration that follows is forcibly NOT inlined? How to return to normal state then? I think pragma is not attached to declaration. I'd strongly favor introducing a compiler-hint family of UDAs and force_inline/force_notinline as first among many. -- Dmitry Olshansky
Re: DIP56 Provide pragma to control function inlining
23-Feb-2014 16:25, Tove пишет: On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. yay, all for it! The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. Could we consider adding flatten in the same dip? quote from gcc Flatten Generally, inlining into a function is limited. For a function marked with this attribute, every call inside this function is inlined, if possible. Whether the function itself is considered for inlining depends on its size and the current inlining parameters. Yes, please. -- Dmitry Olshansky
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:25 AM, Benjamin Thaut wrote: Why a pragma? Can't we use a UDA and give it some special meaning inside the compiler? This shouldn't be an attribute, it's a hint to the compiler optimizer. Pragma is ideally suited to that.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
Not necessary when it's inside a function.
I'd strongly favor introducing a compiler-hint family of UDAs and
force_inline/force_notinline as first among many.
I don't see an advantage of that over pragma. It also seems like something that
should be inside a function, not outside. (After all, a function with no body
cannot be inlined.)
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:31 AM, Andrej Mitrovic wrote: What if you want to mark a series of functions to be inlined? E.g. in an entire module: - module fast; // ?? pragma(inline, true): Vec vecSum(); Vec vecMul(); - That can work because pragmas can have blocks associated with them.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer force-inline/force-not-inline at call site, but
realized the proposal will let me do it:
void myFun(bool inlined)(int arg)
{
static if (inlined)
pragma(inline, true);
else
pragma(inline, false);
}
Then inlining can be entirely explicit :)
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:53 AM, ponce wrote:
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never inlining. This DIP
proposes a simple solution.
This is great. I bet this will be useful.
I tend to prefer force-inline/force-not-inline at call site, but realized the
proposal will let me do it:
void myFun(bool inlined)(int arg)
{
static if (inlined)
pragma(inline, true);
else
pragma(inline, false);
}
Then inlining can be entirely explicit :)
Or better:
void myFun(bool inlined)(int arg)
{
pragma(inline, inlined);
}
:-)
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. I think there should be some way to force the compiler to inline a function. As a bonus, the error message can tell the programmer why the function could not be inlined, allowing them to make the necessary adjustments. Different compilers will have different inlining capabilities, however at the point where programmers are forcing inlining on or off, they are already micro-optimizing at a level which implies dependency on particular compiler implementations.
Re: DIP56 Provide pragma to control function inlining
Am 23.02.2014 13:38, schrieb Dmitry Olshansky: 23-Feb-2014 16:07, Walter Bright пОÑеÑ: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Why pragma? Also how exactly it is supposed to work: pragma(inline, true); ... //every declaration that follows is forcibly inlined? pragma(inline, false); ... //every declaration that follows is forcibly NOT inlined? How to return to normal state then? I think pragma is not attached to declaration. I'd strongly favor introducing a compiler-hint family of UDAs and force_inline/force_notinline as first among many. yea it feels strange - like naked in inline asm its a scope changer - that sits inside the scope it changes??? like writing public methods by putting public inside of the method - and public is also compiler relevant for the generated interface and aligne is also not a pragma - and still changes codegeneration its a function-(compile-)attribute but that does not mean it have to be a pragma btw: is the pragma way just easier to implement - or else i don't understand why this is handle so special?
Re: DIP56 Provide pragma to control function inlining
On 23/02/2014 13:07, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Sounds good in principle. So, if I understand right, a pragma(inline, true) anywhere inside a function adds a compiler hint to always inline this function, while with false it's a hint to _never_ do so, and no pragma at all gives the usual compiler-decides situation? Question: what happens if someone is daft enough to put both true and false inside the same function? In any case, could you possibly provide a slightly more detailed code example with accompanying explanation of what the intended results are?
Re: DIP56 Provide pragma to control function inlining
23-Feb-2014 16:57, Walter Bright пишет: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. It's going to be near useless if it doesn't make sure inlining happened. Part of the reason for forced inline is always inlining some core primitives, even in debug builds. The other point is what Vladimir mentioned - we already doing micro-optimization, hence it better error out then turn a blind eye on our tinkering. I wouldn't not like to ever have to get down and look at ASM for every function just to make sure it was inlined. -- Dmitry Olshansky
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote: It's going to be near useless if it doesn't make sure inlining happened. I completely agree.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2014-02-16 22:05:10 +, Walter Bright said: However, I agree that there may well be other reasons to not have them in Go, such as their simply not being especially useful in day-to-day programming; but I don't have enough experience with meta-programming to make such a judgment. Some years ago, I felt exactly the same way about generics. I have recently written some very interesting D programs, and I would have shocked my former self with nearly every function being a template. I could second this. When you have a strong type system as in D, it makes sense to have strong meta-programming to avoid rework. My current project reflects on all modules to look for classes which inherit from a particular base class -- and then wires those up for fast serialization and deserialization.This would be impossible to do at compile time in any other language, and impossible in most languages, and requiring slow run-time reflection in others. I've found a use for something similar to this in most projects I've done lately. In C# I use Linq Expressions to compile anonymous delegates at runtime to do something similar -- but the code is a nightmare. -S
Porting my Integer Sorting Algorithms to D
I have a couple of self-implemented C++ integer sort algorithms lying around in my codebase. I also have a parallel merge sort on top of them that uses Intel TBB to give some further speedups. I have tweaked them to also work for floats and doubles, through some interesting bit-fiddling tips I found on the net. Would anybody be interested in reviewing these to give suggestions on how to best port it to Phobos? /Per
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 +1
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. Would assert be feasible or difficult to implement with the current compiler design? static assert(pragma(inline, true));
Re: DIP56 Provide pragma to control function inlining
On 23 February 2014 14:19, Tove t...@fransson.se wrote: On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. Would assert be feasible or difficult to implement with the current compiler design? static assert(pragma(inline, true)); WAT!
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote: 23-Feb-2014 16:57, Walter Bright пишет: On 2/23/2014 4:25 AM, Tove wrote: The DIP should probably specify what happens if inlining fails, i.e. generate a compilation error. I suspect that may cause problems, because different compilers will have different inlining capabilities. I think it should be a 'recommendation' to the compiler. It's going to be near useless if it doesn't make sure inlining happened. Part of the reason for forced inline is always inlining some core primitives, even in debug builds. The other point is what Vladimir mentioned - we already doing micro-optimization, hence it better error out then turn a blind eye on our tinkering. I wouldn't not like to ever have to get down and look at ASM for every function just to make sure it was inlined. That is most likely when I would make use of the concept too. And a message from the compiler in its output telling me when such an inline request failed would be helpful. Joseph
structs as large stack allocated objects vs structs as pass by value objects.
Today I hit two problems essentially which got me thinking about how structs are used in D by most of the code I've seen so far. Both problems are in: http://d.puremagic.com/issues/show_bug.cgi?id=9513 So the RedBlackTree create excessive copies of large structs via binaryFun, that and the obvious workaround also necessitates use of a template. It seems that people use structs to indicate one of two things, they want a type they can pass around and return by copy such as vectors/matrices etc. or just a way to allocate something on the stack, usually because of the need for deterministic resource handling or for performance reasons. One of the great things about the D is that it allows you to specify with the type how it should be used by choosing struct vs class, so you can say at the same time whether the data should be stored on the heap and whether it should be passed by copy or by reference. It seems to me that it might nice also to have a sub-division within the struct to allow the user to indicate a struct that should be passed by reference also like a class. It could be the same in every way except it's always passed by reference and people would have to write their own dup or something for when they want to copy it. This could also solve the problem of: functionWithRefParams(LargeStruct.init, LargeStruct.init) These new structs would always be passed by reference, and I guess lvalues would be transformed to temporary stack objects by the compiler so that they never have to be copied. To me the scope ref proposal looks a bit like C++ rvalue references and I thought this might be simpler and more useful but I don't know it's probably not a good idea.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:50:58 UTC, Walter Bright wrote:
On 2/23/2014 4:38 AM, Dmitry Olshansky wrote:
Why pragma?
Answered in another post.
Also how exactly it is supposed to work:
T func(args)
{
...
pragma(inline, true);
...
}
How to return to normal state then?
Not necessary when it's inside a function.
I'd strongly favor introducing a compiler-hint family of UDAs
and
force_inline/force_notinline as first among many.
I don't see an advantage of that over pragma. It also seems
like something that should be inside a function, not outside.
(After all, a function with no body cannot be inlined.)
Thanks for the code example. That helped me better understand
what is being proposed.
I like the idea of using pragma since it is built specifically
for the purpose of sending information to the compiler from code.
Also, I like not having to add another keyword to a function
definition. Especially since I already have @safe pure nothrow
in as many places as possible, for inline-able functions I'd
prefer to not have to add inline to that list. Using a pragma
would mean it could be implemented right away without worrying
about breaking any existing code. The proposal also satisfies the
needs of both parties. Especially since D is a flexible language
it would be nice to give such ability to customize code
generation to the programmer.
Given the above I think this is a good idea.
Joseph
Strategy for Traction
As some of you will know Python is big in bioinformatics, HEP, finance, signal processing and many other computational areas. Originally (and still to some extent) Python was (and still is) used for coordination of Fortran and C++ computations, and for rendering the visualizations. Mathematica, R, Julia, Maple, etc. also have roles in this game. Those in the Python side of the game disliked C and C++ co much they created abstractions, ending up with NumPy, Cython, ShedSkin, Numba, SciPy and also PyPy to replace CPython. All attempts to write Python and gain native code speed of computation. C is definitely not the right tool for this. C++14 however may give a new impetus especially using Boost.Python. The question is whether the anti-C/C++ mindset, pro NumPy/Cython midset is now so embedded there is no other alternative. It would have been really nice to have had a D option since writing D makes writing C++ look like a labour of Sisyphus. I think it might be a very good idea to ensure that D is a really good tool for native code sub-systems within a Python system. Basically to try and remove the NumPy component, and also the Cython, ShedSkin and Numba ones. As we know from recent little experiments and email list threads, D can create C linkage shared libraries which is exactly what is needed for CPython usage (as PyPy sort of), and there is PyD for create CPython extensions. With a little tidying via annotations all the runtime initialization can be handled for C linkage shared libraries, PyD already handles all that for extensions. In a sense all that is needed is some good examples and thence marketing. However I think std.parallelism needs some work: the data parallelism offered is not yet low enough in overhead to really offer argument-free competition to NumPy. The goal needs to be for D + std.parallelism to be as fast of execution as C++ + TBB. Currently it is far from that. Also we need good ARM support so we can run D on RaspberryPis. OK so the GPU of a RaspberryPi is great and the CPU dreadful, but they are the platform of fashion just now. Python is the language of choice, except for those using Java or C and C++. So I suggest two directions to go: 1. Create a NumPy replacement. 2. Ensure D can be used on Raspberry Pis. If there is interest and resource for this then last year was the time to implement, so time is of the essence ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Porting my Integer Sorting Algorithms to D
On Sun, 2014-02-23 at 14:09 +, Nordlöw wrote: I have a couple of self-implemented C++ integer sort algorithms lying around in my codebase. What is the basic sort algorithm? Radix sort is generally seen as the best for sorting integer values currently. But that doesn't mean there is better, just that that is the one to beat. Which requires benchmarks. Which requires a framework for running benchmarks. As far as I am aware D hasn't got one of these as yet, but it needs one. Such things exists in Python (I am currently playing with benchmark) and , I am sure, other dynamic languages. It should be relatively easy to do something with D. I also have a parallel merge sort on top of them that uses Intel TBB to give some further speedups. std.parallelism needs some work to compete with TBB. Though I am not sure like is a term I would use for the TBB API. I have tweaked them to also work for floats and doubles, through some interesting bit-fiddling tips I found on the net. Would anybody be interested in reviewing these to give suggestions on how to best port it to Phobos? I guess I just volunteered. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: assert vs. enforce in Phobos code
On Sunday, 23 February 2014 at 09:55:29 UTC, Joseph Rushton Wakeling wrote: Hello all, This is a subject I think we've visited before, but I can't find the old discussion threads :-( As some of you know I'm working on a successor to std.random -- it's been put on hold the last 8 weeks or so by country/life/work changes, but now I'm back onto it. One of the things I'm examining in the course of that is the error checking. For example, a call to uniform(a, b) sees the function ensure that the interval is appropriate via an enforce(a = b). The result is that passing the wrong values to uniform() will bring your program down. There are many other comparable cases in the module. Part of me feels this is absolutely right and that such errors should be strictly objected to in this way. On the other hand, this seems a wrong approach given that these kinds of functions are surely going to be called deep within the program -- we're not verifying user input here, it would be a logical error in the program to pass wrong bounds to uniform() and so on. My inclination is to clean this stuff up, to generally replace enforce's with asserts, to provide in- and out-contracts where appropriate, and so on. Thoughts, remarks, ... ? Thanks best wishes, -- Joe As a rule of thumb, enforce is not necessarily for things user-input but for things outside the programmer's control eg: things that can legitimately fail, Notably, IO, threads, databases etc... If you see any phobos code that validates the range of its inputs via an enforce, please knock yourself out and assert it/contract it.
Re: Porting my Integer Sorting Algorithms to D
On Sunday, 23 February 2014 at 15:10:36 UTC, Russel Winder wrote: On Sun, 2014-02-23 at 14:09 +, Nordlöw wrote: I have a couple of self-implemented C++ integer sort algorithms lying around in my codebase. What is the basic sort algorithm? Radix sort is generally seen as the best for sorting integer values currently. But that doesn't mean there is better, just that that is the one to beat. Which requires benchmarks. Which requires a framework for running benchmarks. As far as I am aware D hasn't got one of these as yet, but it needs one. Such things exists in Python (I am currently playing with benchmark) and , I am sure, other dynamic languages. It should be relatively easy to do something with D. I also have a parallel merge sort on top of them that uses Intel TBB to give some further speedups. std.parallelism needs some work to compete with TBB. Though I am not sure like is a term I would use for the TBB API. I have tweaked them to also work for floats and doubles, through some interesting bit-fiddling tips I found on the net. Would anybody be interested in reviewing these to give suggestions on how to best port it to Phobos? I guess I just volunteered. The non-inplace radix sort algorithm is the most interesting. I have a test and benchmarking suite along with it. Here's an extract of it using GCC 4.8.2 with -O3 settings on my Intel Quad-Core with 8 Hyperthreads. Results are promising. These benchmarks have been verfied to produce correct results: Element Count: 100 Number of tries: 5 Do in place: 0 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float1947812us 16 4.27x 4.02x 4.87x 4.37x double 2022670us 16 2.30x 2.09x 3.25x 2.31x uint8_t 1673208us 8 10.4x 10.0x 9.32x 10.6x uint16_t 1800614us 16 10.1x 9.37x 9.52x 10.1x uint32_t 1936704us 16 5.45x 4.99x 5.77x 5.42x Should I place the code on a Github repo or send it to you by email? Thx, Per
Re: Porting my Integer Sorting Algorithms to D
On Sunday, 23 February 2014 at 16:16:48 UTC, Nordlöw wrote: On Sunday, 23 February 2014 at 15:10:36 UTC, Russel Winder wrote: On Sun, 2014-02-23 at 14:09 +, Nordlöw wrote: I have a couple of self-implemented C++ integer sort algorithms lying around in my codebase. What is the basic sort algorithm? Radix sort is generally seen as the best for sorting integer values currently. But that doesn't mean there is better, just that that is the one to beat. Which requires benchmarks. Which requires a framework for running benchmarks. As far as I am aware D hasn't got one of these as yet, but it needs one. Such things exists in Python (I am currently playing with benchmark) and , I am sure, other dynamic languages. It should be relatively easy to do something with D. I also have a parallel merge sort on top of them that uses Intel TBB to give some further speedups. std.parallelism needs some work to compete with TBB. Though I am not sure like is a term I would use for the TBB API. I have tweaked them to also work for floats and doubles, through some interesting bit-fiddling tips I found on the net. Would anybody be interested in reviewing these to give suggestions on how to best port it to Phobos? I guess I just volunteered. The non-inplace radix sort algorithm is the most interesting. I have a test and benchmarking suite along with it. Here's an extract of it using GCC 4.8.2 with -O3 settings on my Intel Quad-Core with 8 Hyperthreads. Results are promising. These benchmarks have been verfied to produce correct results: Element Count: 100 Number of tries: 5 Do in place: 0 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float1947812us 16 4.27x 4.02x 4.87x 4.37x double 2022670us 16 2.30x 2.09x 3.25x 2.31x uint8_t 1673208us 8 10.4x 10.0x 9.32x 10.6x uint16_t 1800614us 16 10.1x 9.37x 9.52x 10.1x uint32_t 1936704us 16 5.45x 4.99x 5.77x 5.42x Should I place the code on a Github repo or send it to you by email? Thx, Per After having take a look at algorithm.d I guess we should use CTFE-logic to autoconfigure to use radix sort when ElementType isInteger or float or double. string and real could probably be sorted aswell. To make this configuration optimal an optional pre-configuration benchmarking pass may be need in order to give optimal speeds. Such a pass should for each sort implementation figure out a suitable limit [low,high] for the size range being sorted. /Per
Re: Porting my Integer Sorting Algorithms to D
I did some more benchmarking: These are all using non-inplace radix sort. This can be useful in some cases where in-place is not needed. Performance gain increase with size input array compared to std::sort as radix sort in some regard is O(n) and quick sort is O(n*log n). Break sizes (when radix sort wins) for different element types: uint8: 1024 uint16: 1024 uint32: = 4096 float: = 8192 double: = 16384 Number of tries: 3 Do in place: 0 Element Count: 1024 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 2390us 16 0.483x 0.892x 0.386x 0.898x double 809us 16 0.152x 0.155x 0.059x 0.0822x uint8_t 1104us 8 10.9x 10.9x 1.65x 2.9x uint16_t 1813us 16 1.38x 1.4x 0.889x 1.44x uint32_t 707us 16 0.286x 0.281x 0.137x 0.231x Element Count: 2048 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 1511us 16 0.518x 0.513x 0.21x 0.28x double 1520us 16 0.268x 0.27x 0.0997x 0.144x uint8_t 2603us 8 11.8x 11.8x 3.81x 12.2x uint16_t 1451us 16 1.03x 1.1x 0.675x 1.03x uint32_t 1531us 16 0.592x 0.575x 0.44x 0.583x Element Count: 4096 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 3099us 16 0.939x 0.904x 0.785x 0.925x double 3411us 16 0.504x 0.483x 0.13x 0.392x uint8_t 2777us 8 6.69x 6.64x 1.7x 7.37x uint16_t 3133us 16 1.91x 1.9x 0.458x 1.46x uint32_t 3681us 16 1.15x 1.14x 0.229x 0.539x Element Count: 8192 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 6760us 16 1.49x 1.54x 0.422x 0.921x double 7285us 16 0.84x 0.825x 0.333x 0.897x uint8_t 5895us 8 7.19x 6.89x 5.59x 7.77x uint16_t 6730us 16 3.18x 3.23x 1.5x 3.52x uint32_t 7095us 16 1.75x 1.7x 0.4x 1.89x Element Count: 16384 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 14410us 16 2.28x 2.19x 0.732x 2.29x double 15066us 16 1.19x 1.08x 0.539x 1.23x uint8_t 12104us 8 7.8x 7.65x 7.22x 7.84x uint16_t 14570us 16 4.81x 4.69x 0.906x 4.96x uint32_t 15034us 16 2.61x 2.48x 0.537x 2.6x Element Count: 32768 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 30764us 16 2.82x 2.62x 2.61x 2.67x double 31569us 16 1.6x 1.46x 0.764x 1.58x uint8_t 26176us 8 8.23x 8.52x 2.8x 8.49x uint16_t 30947us 16 6.45x 6.13x 6.32x 6.91x uint32_t 32785us 16 3.53x 3.39x 1.09x 3.89x Element Count: 65536 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 63166us 16 3.24x 3.12x 2.12x 3.25x double 71154us 16 1.83x 1.81x 1.66x 2.02x uint8_t 56285us 8 8.52x 8.43x 4.22x 9.35x uint16_t 64761us 16 7.68x 8.02x 2.54x 8.32x uint32_t 68576us 16 4.16x 3.93x 2.45x 4.4x Element Count: 131072 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 137296us 16 3.42x 3.47x 3.13x 3.73x double 139881us 16 2.08x 1.85x 1.93x 2.08x uint8_t 111393us 8 9.04x 9.15x 5.99x 9.45x uint16_t 128848us 16 8.47x 8.12x 4.65x 8.53x uint32_t 134586us 16 4.64x 4.29x 2.37x 4.56x Element Count: 262144 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 275099us 16 3.87x 3.66x 3.02x 3.86x double 294763us 16 2.22x 1.93x 2.82x 2.18x uint8_t 233671us 8 9.53x 9.65x 5.06x 9.92x uint16_t 259553us 16 8.93x 8.43x 5.6x 9.33x uint32_t 282111us 16 5.16x 4.57x 4.37x 5.09x Element Count: 524288 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 573934us 16 3.96x 3.8x 3.25x 4.05x double 622996us 16 2.16x 2.05x 2.74x 2.29x uint8_t 482522us 8 10x 9.82x 5.71x 10.1x uint16_t 525446us 16 9.3x 8.76x 5.64x 9.49x uint32_t 595237us 16 5.42x 4.95x 4.86x 5.44x Element Count: 1048576 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 1202785us 16 4.22x 3.99x 4.9x 4.24x double 1322048us 16 2.39x 2.13x 3.51x 2.45x uint8_t 1009387us 8 10.3x 10.2x 8.83x 10.5x uint16_t 1070777us 16 9.6x 9x 9.45x 9.59x uint32_t 1242144us 16 5.37x 5.09x 6.07x 5.54x Element Count: 2097152 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 2539646us 16 4.42x 4.15x 5.77x 4.46x double 2686074us 16 2.46x 2.19x 3.64x 2.45x uint8_t 2136319us 8 10.8x 10.7x 9.93x 10.8x uint16_t 2199277us 16 9.7x 9x 11.1x 9.6x uint32_t 2619062us 16 5.78x 5.28x 7.01x 5.83x Element Count: 4194304 ElementType Reference(std::sort) Radix radix_sort descending_radix_sort parallel_radix_sort tbb_parallel_radix_sort float 5388683us 16 4.64x 4.46x 6.76x 4.72x double 5617282us 16 2.54x 2.29x 4x 2.56x uint8_t 4449453us 8 11.1x 10.9x 12.7x 11.2x uint16_t 4546878us 16
Re: Porting my Integer Sorting Algorithms to D
On Sun, 2014-02-23 at 16:16 +, Nordlöw wrote: […] Should I place the code on a Github repo or send it to you by email? BitBucket or GitHub work for me: if we keep this public others may join in… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Porting my Integer Sorting Algorithms to D
On Sun, 2014-02-23 at 16:59 +, Nordlöw wrote: I did some more benchmarking: We definitely need a benchmarking framework so as to ensure we can have multiple runs of each datapoint calculating mean and standard deviation for each data point, and for grouping and ANOVA. I am guessing there isn't already one. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Porting my Integer Sorting Algorithms to D
I guess working on a branch of Phobos (std.algorithm) is preferrable when we get to the D implementation right?
Re: Porting my Integer Sorting Algorithms to D
On Sun, 2014-02-23 at 17:33 +, Nordlöw wrote: I guess working on a branch of Phobos (std.algorithm) is preferrable when we get to the D implementation right? I just asked effectively that question re std.parallelism on the DMD Concurrency list, only to find I wasn't a member so the email is pending moderation. I am hoping there is a way of working on a self-contained component of Phobos without having to clone Phobos and do a feature branch. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: assert vs. enforce in Phobos code
On 23/02/2014 17:10, monarch_dodra wrote: As a rule of thumb, enforce is not necessarily for things user-input but for things outside the programmer's control eg: things that can legitimately fail, Notably, IO, threads, databases etc... It seems to me that enforce is used extensively in Phobos for other purposes than that, and quite often seems to be used for obligatory runtime checks. If you see any phobos code that validates the range of its inputs via an enforce, please knock yourself out and assert it/contract it. Well, these are some examples where it seems to me both understandable that someone wanted to really, really make sure the values were correct, and at the same time to fall outside the scope of things that can legitimately fail: https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L359-L360 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1253-L1255 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1334-L1335 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1345-L1347 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1357-L1359 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1629 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1703 https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L2061-L2070 I referred to checking user input because the only rationale I can see for these statements being enforce is if the values being checked were being treated as user input and therefore something that could legitimately fail. Or have I missed something about when enforce is appropriate? ;-) Assuming I'm right about these enforce statements being inappropriate, I'll make a patch.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 13:07:27 UTC, Dmitry Olshansky wrote: It's going to be near useless if it doesn't make sure inlining happened. Part of the reason for forced inline is always inlining some core primitives, even in debug builds. Optional recommendation for inlining already exists - it is current default. This pragma needs to result in compile-time error if used where inlining is not possible to be any useful. Other than that, looks fine.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote: Am 23.02.2014 13:07, schrieb Walter Bright: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Why a pragma? Can't we use a UDA and give it some special meaning inside the compiler? +1 I would also prefer an attribute which can be used as label. @inline(true): // ... @inline(false): // ... @inline(default):
Re: Porting my Integer Sorting Algorithms to D
I guess this component would be integrated into std.algorithm when its ready, right?
Re: Porting my Integer Sorting Algorithms to D
On Sunday, 23 February 2014 at 19:17:29 UTC, Nordlöw wrote: I guess this component would be integrated into std.algorithm when its ready, right? If you are happy with it being in there, if the algorithm has a nice behaviour, and it passes the existing test suite, I don't see why it would not!
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 Seems reasonable to me.
Re: Strategy for Traction
Russel Winder: Those in the Python side of the game disliked C and C++ co much they created abstractions, ending up with NumPy, Cython, ShedSkin, Unfortunately ShedSkin is now essentially dead. And Julia could replace Python in some usages, because of its performance. Bye, bearophile
Re: assert vs. enforce in Phobos code
On Sunday, 23 February 2014 at 17:51:34 UTC, Joseph Rushton Wakeling wrote: Assuming I'm right about these enforce statements being inappropriate, I'll make a patch. I believe you are correct, but the larger issue is that Phobos doesn't come with a debug build. So while they probably should be contracts, they will not be verified since the contracts will be compiled out.
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 Ok it seems people are ok with the change, so I've merged it. It should be easier to edit the wiki than to have to mess with DDOC and pull requests anyway.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:06 AM, Joseph Rushton Wakeling wrote: So, if I understand right, a pragma(inline, true) anywhere inside a function adds a compiler hint to always inline this function, while with false it's a hint to _never_ do so, and no pragma at all gives the usual compiler-decides situation? I'll add: pragma(inline); meaning revert to default behavior. Question: what happens if someone is daft enough to put both true and false inside the same function? The last one wins.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote: I'll add: pragma(inline); That's just going to confuse people, because they'll think *this* forces inlining. I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and pragma(default_inline) or something like that.
Re: Strategy for Traction
Am 23.02.2014 20:53, schrieb bearophile: Russel Winder: Those in the Python side of the game disliked C and C++ co much they created abstractions, ending up with NumPy, Cython, ShedSkin, Unfortunately ShedSkin is now essentially dead. And Julia could replace Python in some usages, because of its performance. Bye, bearophile And they keep improving it, http://julialang.org/blog/2013/03/efficient-aggregates/
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:01 AM, Vladimir Panteleev wrote: I think there should be some way to force the compiler to inline a function. As a bonus, the error message can tell the programmer why the function could not be inlined, allowing them to make the necessary adjustments. Different compilers will have different inlining capabilities, however at the point where programmers are forcing inlining on or off, they are already micro-optimizing at a level which implies dependency on particular compiler implementations. I think it would be a porting nuisance to error out when the compiler can't inline. The user would then fix it by versioning out for that compiler, and then the user is back to the same state as it being a recommendation. Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 11:04 AM, Dicebot wrote: Optional recommendation for inlining already exists - it is current default. That is not the point of the pragma. The point of always inlining is (as Manu explained) some functions need to be inlined even in debug mode, as the code would otherwise be too slow to even debug.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:07 AM, Dmitry Olshansky wrote: Part of the reason for forced inline is always inlining some core primitives, even in debug builds. Right - and if the compiler won't do it, how does the error message help? I wouldn't not like to ever have to get down and look at ASM for every function just to make sure it was inlined. By the time you get to the point of checking on inlining, you're already looking at the assembler output, because the function is on the top of the profile of time wasters, and that's how you take it to the next level of performance. The trouble with an error message, is what (as the user) can you do about it?
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 20:25:11 UTC, Andrej Mitrovic wrote: On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 Ok it seems people are ok with the change, so I've merged it. It should be easier to edit the wiki than to have to mess with DDOC and pull requests anyway. This. I'd prefer anything that is not part of official spec / source documentation to be in wiki - it is just easier and faster to improve that way.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote: Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful. Ok, you are at this point, check assembly and find out that compiler ignores your recommendation with no error messages / explanations. Next step?
Re: Move some guides to the DWiki - yay or nay?
On 2/23/14, Dicebot pub...@dicebot.lv wrote: This. I'd prefer anything that is not part of official spec / source documentation to be in wiki - it is just easier and faster to improve that way. I declare the DDOC DWiki porting season officially open!
Re: DIP56 Provide pragma to control function inlining
24-Feb-2014 00:46, Walter Bright пишет: On 2/23/2014 5:07 AM, Dmitry Olshansky wrote: Part of the reason for forced inline is always inlining some core primitives, even in debug builds. Right - and if the compiler won't do it, how does the error message help? That programmer is instantly aware that it can't be done due to some reason. Keep in mind that code changes with time and running profiler/disassembler on every tiny change to make sure the stuff is still inlined is highly counter-productive. I wouldn't not like to ever have to get down and look at ASM for every function just to make sure it was inlined. By the time you get to the point of checking on inlining, you're already looking at the assembler output, because the function is on the top of the profile of time wasters, and that's how you take it to the next level of performance. A one-off activity. Now what guarantees you will have that it will keep getting inlined? Right, nothing. The trouble with an error message, is what (as the user) can you do about it? Re-write till compiler loves it, that is what we do today anyway. Else we wouldn't mark it as force_inline in the first place. With error - yo get a huge advantage - an _instant_ feedback that it doesn't do what you want it to do. Otherwise it gets the extra pleasure of running disassembler to pinpoint your favorite call sites or observing that your profiler shows the same awful stats. -- Dmitry Olshansky
Re: DIP56 Provide pragma to control function inlining
24-Feb-2014 00:40, Walter Bright пишет: On 2/23/2014 5:01 AM, Vladimir Panteleev wrote: I think there should be some way to force the compiler to inline a function. As a bonus, the error message can tell the programmer why the function could not be inlined, allowing them to make the necessary adjustments. Different compilers will have different inlining capabilities, however at the point where programmers are forcing inlining on or off, they are already micro-optimizing at a level which implies dependency on particular compiler implementations. I think it would be a porting nuisance to error out when the compiler can't inline. The user would then fix it by versioning out for that compiler, and then the user is back to the same state as it being a recommendation. Porting across compilers you mean? While porting making temporary changes is fine, like turning off force_inline where it doesn't work. Without this error you are facing a silent performance disaster you still need to figure out. Fail fast for the win. Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful. Will save you the trouble of looking at the assembly window to begin with. Because you known ahead of time you wouldn't see what you like. -- Dmitry Olshansky
Re: assert vs. enforce in Phobos code
On Sunday, 23 February 2014 at 20:00:48 UTC, Jesse Phillips wrote: On Sunday, 23 February 2014 at 17:51:34 UTC, Joseph Rushton Wakeling wrote: Assuming I'm right about these enforce statements being inappropriate, I'll make a patch. I believe you are correct, but the larger issue is that Phobos doesn't come with a debug build. So while they probably should be contracts, they will not be verified since the contracts will be compiled out. It's less of an issue with phobos, which massivelly templated. Only very few things are non-template (AFAIK). The bigger issue is things such as druntime, which is basically 99% pre-compiled. That, and there's also the broader issue of the conditionality of contracts should be decided by the calling library.
Re: C++ Binding Generator
https://github.com/w0rp/dqt I have been working on my generator over the past few weeks, and extensively this weekend. It took many hours of work, but I just got generation of D source files from SMOKE data to work. Here is what it does and roughly how it works. 1. Earlier on, SMOKE is by a third party to generate a dynamic library. This library contains data held in a Smoke class defined in C++, which functions provided for creating, deleting, and getting a reference to the pointer for the class with what are *supposed* to be functions with C linkage. (I had to wrap them anyway with my own functions due to issues.) 2. Because the class members in Smoke are all C primitives, I can match the layout with a struct in D and load everything from the struct in D code. At the time of generation, I copy everything I need out of the struct into a saner representation in D, which I have called SmokeContainer. 3. SmokeContainer is supposed to tell you everything you need to know to make generation work. So I use that data and pass it to my class which handles generation of D source files, SmokeGenerator. It does all kinds of work to translate C++ classes from the SMOKE data to D code, with some ability for customisation like ignoring certain types or classes, replacing classes with different ones in D or just wrappers for generating them, etc. 4. The SmokeGenerator spits out the D source files and requires having a SmokeLoader defined in prefix D file, which loads the same SMOKE data again at runtime for finding the class method pointers needed to call C++ functions and so on. 5. You run a D program which uses the generated D source files and now you have C++ code being run from D. While my project is actually called DQt above and the motivation for it is to get Qt working in D, I have written it all in such a way as to make the Qt specific part of the code and the general case SMOKE binding stuff loosely coupled. The only Qt specific stuff now lies in some C++ code needed for certain circumstances, (like wrapping QString) a few pre-baked D source files used as finishing touches for the generation specific to Qt, and the current test programs which generate code and run Hello World respectively. I shouldn't have too much trouble moving most of this stuff into a dsmoke repository instead. If you want to try out running Hello World from the generated code yourself, and you're willing to work around my sloppy project structure, do this. 1. Build smokegen and smokeqt. I wrote two guides for Linux and Windows on this. 1. Linux: https://github.com/w0rp/dqt/blob/master/doc/smoke_linux_build_guide.rst 2. Windows: https://github.com/w0rp/dqt/blob/master/doc/smoke_win32_build_guide.rst 2. Use CMake to build my code. I think 'cmake . make' will do the job on Linux, if you're in my project directory. 3. Put 'libsmoke_cwrapper' in your library path. I make it easy on myself by copying it out of the lib/ directory into src/ and by running 'export LD_LIBRARY_PATH=.' Not the best way, but it's a quick way to get it going. 4. 'rdmd -g -Llibsmoke_cwrapper.so -d -debug -w new_test.d' Will run the generator and spit some stuff into src/dqt for now. 5. 'rdmd -Llibsmoke_cwrapper.so -d smoke_test.d' will now run the Hello World program, supposing everything else went well. I am going to continue working on this. There are some things to iron out and a lot of interesting work ahead. Hopefully I can get a somewhat usable Qt in D library out of this.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 20:40:44 UTC, Walter Bright wrote: Generally, when I optimize at that level, I have a window open on the assembler output of the compiler and I go back and forth on the source code until I get the shape of the assembler I need. Having compiler messages wouldn't be very helpful. Not everyone has time/knowledge for checking the ASM at every recompile. Personally I wouldn't be able to do something like this that much often, and yet I'd love to know that something is not working ASAP. Code changes, and it changes a lot during development. Having a way to make sure that one or more functions stay inlined is handy to have. If such a pragma doesn't guarantee inlining, that means we will have no way to check it quickly. Sometimes fail fast is really the best choice.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 12:31 PM, Andrej Mitrovic wrote: On Sunday, 23 February 2014 at 20:29:19 UTC, Walter Bright wrote: I'll add: pragma(inline); That's just going to confuse people, because they'll think *this* forces inlining. Perhaps, but there's precedent with how align works, and how default initialization of variables works. I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and pragma(default_inline) or something like that. That makes documentation with a sorted list of pragmas impractical.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 19:10:08 UTC, Namespace wrote: On Sunday, 23 February 2014 at 12:25:20 UTC, Benjamin Thaut wrote: Am 23.02.2014 13:07, schrieb Walter Bright: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. Why a pragma? Can't we use a UDA and give it some special meaning inside the compiler? +1 I would also prefer an attribute which can be used as label. @inline(true): // ... @inline(false): // ... @inline(default): I still prefer the attribute/UDA idea but in case of pragma: pragma(inline, true); pragma(inline, false); pragma(inline, default); ?
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some reason.
Keep in mind that code changes with time and running profiler/disassembler on
every tiny change to make sure the stuff is still inlined is highly
counter-productive.
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that line looks
awful.
By the time you get to the point of checking on inlining, you're already
looking at the assembler output, because the function is on the top of
the profile of time wasters, and that's how you take it to the next
level of performance.
A one-off activity. Now what guarantees you will have that it will keep getting
inlined? Right, nothing.
You're always going to have that issue when optimizing at that level, and it
will be for a large range of constructs. For example, you may need variable x to
be enregistered. You may need some construct to be implemented as a ROL
instruction. You may need a switch to be implemented as a binary search.
The trouble with an error message, is what (as the user) can you do
about it?
Re-write till compiler loves it, that is what we do today anyway. Else we
wouldn't mark it as force_inline in the first place.
In which case there will be two code paths selected with a version(BadCompiler).
I have a hard time seeing the value in supporting both code paths - the
programmer would just use the workaround code always.
With error - yo get a huge advantage - an _instant_ feedback that it doesn't do
what you want it to do. Otherwise it gets the extra pleasure of running
disassembler to pinpoint your favorite call sites or observing that your
profiler shows the same awful stats.
My point is you're going to have to look at the asm of the top functions on the
profiler stats anyway, or you're wasting your time trying to optimize the code.
(Speaking from considerable experience doing that.) There's a heluva lot more to
optimizing effectively than inlining, and it takes some back-and-forth tweaking
source code and looking at the assembler. I gave some examples of that above.
And yes, performance critical code often suffers from bit rot, and changes in
the compiler, and needs to be re-tuned now and then.
I suspect if the compiler errors out on a failed inline, it'll be much less
useful than one might think.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:38:46 UTC, Walter Bright wrote: On 2/23/2014 12:31 PM, Andrej Mitrovic wrote: I'd prefer 3 separate states. pragma(inline), pragma(no_inline), and pragma(default_inline) or something like that. That makes documentation with a sorted list of pragmas impractical. pragma(inline_always) pragma(inline_never) pragma(inline_default) or pragma(inline_force) pragma(inline_prevent) pragma(inline_default)
Re: Move some guides to the DWiki - yay or nay?
On Sunday, 23 February 2014 at 12:06:33 UTC, Andrej Mitrovic wrote: E.g. the win32 guide, see here: https://github.com/D-Programming-Language/dlang.org/pull/496 +1
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 1:32 PM, Francesco Cattoglio wrote: [...] I addressed these three messages in another reply to Dmitry.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due
to some reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make sure the stuff is still inlined is
highly
counter-productive.
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
Once one resorts to force_inline and similar micro-optimisations
he usually sticks to single good compiler as code gen needs to
be re-profiled for each compiler anyway.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 1:41 PM, Namespace wrote: pragma(inline, true); pragma(inline, false); pragma(inline, default); 'default' being a keyword makes for an ugly special case in how pragmas are parsed.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 1:53 PM, Walter Bright wrote: And yes, performance critical code often suffers from bit rot, and changes in the compiler, and needs to be re-tuned now and then. BTW, just to reiterate, there are *thousands* of optimizations the compiler may or may not do. And yes, performance critical code will often rely on them, and code is often tuned to 'tickle' certain ones. For example, I know a fellow years ago who thought he had invented a spectacular new string processing algorithm. He had the benchmarks to prove it, and published an article with his with/without benchmark. Unfortunately, the without benchmark contained an extra DIV instruction that, due to the vagaries of optimization, the compiler hadn't elided. That DIV had nothing to do with the algorithm, but the benchmark timing differences were totally due to its presence/absence. He would have spotted it if he'd ever looked at the asm generated, and saved himself from some embarrassment. I understand that in an ideal world one should never have to look at asm, but if you're writing high performance code and don't look at asm, the code is never going to beat the competition.
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:55:11 UTC, Walter Bright wrote: On 2/23/2014 1:32 PM, Francesco Cattoglio wrote: [...] I addressed these three messages in another reply to Dmitry. Read that, and you do make a point. I am no expert on optimization, but as far as I could tell, inlining is usually the easiest and most rewarding of the optimizations one can do. I know you kind of hate warnings, but perhaps we could at least get a warning if something cannot be inlined?
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler.
This is exactly what caused mess with http user agent info when
both browsers tried to present web pages better and web devs
tried to tune their pages to browsers with distinct features. Now
chrome says it's Mozilla, khtml, gecko and safari. But, is that
really a problem? I don't think much code relies on compiler
intrinsics. If it does perhaps a way to specify attributes in one
place and then reference those (like CUSTOM_INLINE define in C)
would help.
Re: DIP56 Provide pragma to control function inlining
As a compromise diagnostics about refused inlining can be added as special output category to https://github.com/D-Programming-Language/dmd/pull/645
Re: DIP56 Provide pragma to control function inlining
24-Feb-2014 01:53, Walter Bright пишет:
On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
That programmer is instantly aware that it can't be done due to some
reason.
Keep in mind that code changes with time and running
profiler/disassembler on
every tiny change to make sure the stuff is still inlined is highly
counter-productive.
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that line
looks awful.
You actually going against yourself with this argument - for porting you
typically suggest:
version(OS1)
...
else version(OS2)
...
else
static assert(0);
Why forced_inline is any different then other porting (where you want
fail fast).
By the time you get to the point of checking on inlining, you're already
looking at the assembler output, because the function is on the top of
the profile of time wasters, and that's how you take it to the next
level of performance.
A one-off activity. Now what guarantees you will have that it will
keep getting
inlined? Right, nothing.
You're always going to have that issue when optimizing at that level,
and it will be for a large range of constructs. For example, you may
need variable x to be enregistered. You may need some construct to be
implemented as a ROL instruction. You may need a switch to be
implemented as a binary search.
Let's not detract from original point. ROL is done as an instrinsic, and
there are different answers to many of these questions that are BETTER
then _always_ triple checking by hand and doing re-writes. Switch may
benefit from pragmas as well, and modern compiler allow tweaking it. In
fact LLVM allows assigning weights to specify which cases are more probable.
Almost all of listed issues could be addressed better then dancing
around disassembler and trying to please PARTICULAR COMPILER for many
cases you listed above.
Yes, looking at ASM is important but no not every single case should
require the painful cycle of:
compile-disassemble--re-write--compile--...
The trouble with an error message, is what (as the user) can you do
about it?
Re-write till compiler loves it, that is what we do today anyway. Else we
wouldn't mark it as force_inline in the first place.
In which case there will be two code paths selected with a
version(BadCompiler). I have a hard time seeing the value in supporting
both code paths - the programmer would just use the workaround code always.
Your nice tired and true way of doing things is EQUALLY FRAGILE (if not
more) and highly coupled to the compiler but only SILENTLY so.
With error - yo get a huge advantage - an _instant_ feedback that it
doesn't do
what you want it to do. Otherwise it gets the extra pleasure of running
disassembler to pinpoint your favorite call sites or observing that your
profiler shows the same awful stats.
My point is you're going to have to look at the asm of the top functions
on the profiler stats anyway, or you're wasting your time trying to
optimize the code.
Like I don't know already, getting in this discussion.
(Speaking from considerable experience doing that.)
And since you've come to enjoy it as is, you accept no improvements over
that process? So you known it's hard fighting the compiler and you
decidedly as a samurai reject any help messing with it. I seriously
don't get the point.
GCC has force inline, let's look at what GCC does with its always_inline:
http://gcc.gnu.org/ml/gcc-help/2007-01/msg00051.html
Quote of interest:
---
**5) Could there be any situation, where a function with always_inline
is _silently_ not embedded?
I hope not. I don't know of any.
---
There's a heluva lot more to optimizing effectively than inlining, and
it takes some back-and-forth tweaking source code and looking at the
assembler. I gave some examples of that above.
Just because there are other reasons to look at disassembly is not a
good reason to forcibly send people to double-check compiler for basic
inlining.
And yes, performance critical code often suffers from bit rot, and
changes in the compiler, and needs to be re-tuned now and then.
And you accept no safe-guards against this because that is the true old
way?
I suspect if the compiler errors out on a failed inline, it'll be much
less useful than one might think.
On the contrary, at least I may have to spent less time checking that
intended optimizations are being done in ASM listings.
--
Dmitry Olshansky
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 3:00 PM, Dmitry Olshansky wrote: You actually going against yourself with this argument - for porting you typically suggest: version(OS1) ... else version(OS2) ... else static assert(0); There's not much choice about that. I also suggest moving such code into separate modules. Your nice tired and true way of doing things is EQUALLY FRAGILE (if not more) and highly coupled to the compiler but only SILENTLY so. That's very true. Do you suggest the compiler emit a list of what optimizations it did or did not do? What makes inlining special, as opposed to, say, enregistering particular variables?
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 23:49:57 UTC, Walter Bright wrote: What makes inlining special, as opposed to, say, enregistering particular variables? The difference is it was explicitly told do do something and didn't. That's insubordination. Mike
Re: DIP56 Provide pragma to control function inlining
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that
line looks awful.
If I need to support multiple compilers and if one of them is not
good enough, I would first try to figure out which statement
causes it to fail, if left with no other alternatives: Manually
inline it in the common path for all compilers, _not_ create
version blocks.
Inspecting asm output doesn't scale well to huge projects.
Imagine simply updating the existing codebase to use a new
compiler version.
Based on my experience, even if we are profiling and benchmarking
a lot and have many performance based KPI:s, they will still
never be as fine-grained as the functional test coverage.
Also not forgetting, some performance issues may only be detected
in live usage scenarios on the other side of the earth as the
developers doesn't even have access to the needed
environment(only imperfect simulations), in those scenarios you
are quite grateful for every static compilation error/warning you
can get...
You are right in that there is nothing special about inlining,
but I'd rather add warnings for all other failed optimisation
opportunities than not to warn about failed inlining. RVCT for
instance has --diag_warning=optimizations, which gives many
helpful hints, such as alias issues: please add restrict, or
possible alignment issues etc.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 3:55 PM, Mike wrote: The difference is it was explicitly told do do something and didn't. That's insubordination. I view this as more in the manner of providing the equivalent of runtime profiling information to the optimizer, in indirectly saying how often a function is executed. Optimizing is a rather complicated process, and particular optimizations very often have weird and unpredictable interactions with other optimizations. For example, in the olden days, C compilers had a 'register' storage class. Optimizers' register allocation strategy was so primitive it needed help. Over time, however, it became apparent that uses of 'register' became bit-rotted due to maintenance, resulting in all the wrong variables being enregistered. Compiler register allocation got a lot better, almost always being better than the users'. Not only that, but with generic code, and optimization rewrites of code, many variables would disappear and new ones would take their place. Different CPUs needed different register allocation strategies. What to do with 'register' then? The result was compilers began to take the 'register' as a hint, and eventually moved to totally ignoring 'register', as it turned out to be a pessimization. I suspect that elevating one particular optimization hint to being an absolute command may not turn out well. Inlining already has performance issues, as it may increase the size of an inner loop beyond what will fit in the cache, for just one unexpected result. For another it may mess up the register allocation of the caller. Inlining makes it faster is not always true. Do you really want to weld this in as an absolute requirement in the language?
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 00:33:09 UTC, Walter Bright wrote: I suspect that elevating one particular optimization hint to being an absolute command may not turn out well. Inlining already has performance issues, as it may increase the size of an inner loop beyond what will fit in the cache, for just one unexpected result. For another it may mess up the register allocation of the caller. Inlining makes it faster is not always true. Do you really want to weld this in as an absolute requirement in the language? The fact that original C inline was designed in same permissive way and is almost unused in practice (as opposed to compiler-specific force_inline attributes) does say something. It is not feature that should be design for mass usage.
Re: DIP56 Provide pragma to control function inlining
Le 23/02/2014 13:07, Walter Bright a écrit : http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. I saw many times C++ developers works on applications doesn't need such level optimization puts inline keyword or implementation in headers files without doing any performance analysis!!! And as I saw they don't know X86 neither,... For those doesn't have necessary knowledge it's just counter productive and increase the compilation times without evidence of the interest. So my point is this kind of feature have to be hidden from newbies (like me) and other developers who are zealous.
Re: Multi-associative array
On 2/22/14, 11:10 PM, Etienne Cimon wrote:
On 2014-02-23 01:27, H. S. Teoh wrote:
You can just use a struct or tuple as the AA key to achieve the same
thing.
I thought of that but it's not immediately obvious how I could achieve
sorting or filtering by a certain field
e.g.
auto sorted = aa.sort!(Key.y = { a b })
auto filtered = aa.filter!
foreach(x, y, z ; aa){
}
I don't see a very simple way of doing this right now. I'm sure someone
thought of a library for this?
The way multiple binary tree (or rb-tree) indexes are achieved is by
storing multiple pointers with the same value. That way really multiple
threes are threaded using the same value nodes.
There's no trivial way to do this. It would be very valuable to
generalize RBTree to accept multiple predicates and build such multiple
indexes.
Andrei
Re: DIP56 Provide pragma to control function inlining
The fact that original C inline was designed in same permissive way and is almost unused in practice (as opposed to compiler-specific force_inline attributes) does say something. Do you mind to back up your fact with some numbers? Afaict 'inline' is more common than __attribute__((forceinline)). (Well ok for C code #define is even more common, but most C code is stuck in the 70ies anyway so that doesn't mean anything.)
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 4:21 PM, Tove wrote: Inspecting asm output doesn't scale well to huge projects. Imagine simply updating the existing codebase to use a new compiler version. Again, this is treating 'inline' as being the only optimization that matters? It's not even the most important - that would likely be register allocation. At some point, you're going to need to trust the compiler. You are right in that there is nothing special about inlining, but I'd rather add warnings for all other failed optimisation opportunities than not to warn about failed inlining. RVCT for instance has --diag_warning=optimizations, which gives many helpful hints, such as alias issues: please add restrict, or possible alignment issues etc. There are *thousands* of optimization patterns. Logging which ones were applied to each expression node would be utterly useless to anyone but a compiler writer. (You can turn this on in debug builds of the compiler and see for yourself.) The most effective log is to look at the asm output. There isn't a substitute. I know that doesn't scale, going back to my point that at some point you're going to have to spot check here and there and otherwise trust the compiler. I know that most programmers don't want to look at the asm output. Whether an error for failed inlining is or is not issued won't change the need to have a look now and then, if you want your code to be the fastest it can be. BTW, although the DIP says the compiler can ignore it, in practice there aren't going to be perverse compilers. Compiler writers want their compilers to be useful, and don't go out of their way to sneakily interpret the spec to do as bad a job as possible. Conversely, the history of programmer-supplied optimizer edicts (see 'register') is not a very good one, as programmers are often not terribly cognizant of the tradeoffs and tend to use overly simplistic rules when applying these edicts. As optimizers improve, they shouldn't be impeded by well-intentioned but wrong optimization edicts. (An early version of my C compiler had a long list of various optimization strategies that could be turned on/off. Never once was any appropriate use made of these. It's why dmd has evolved to simply have -O. -inline is a separate switch for reasons of symbolic debuggability.)
Re: Open Source Report Card
On 2/22/14, 8:33, Andrej Mitrovic wrote: On 2/22/14, simendsjo simend...@gmail.com wrote: Hehe.. simendsjo is an exceptional D coder. I think that page is created solely to feed our ego :) And it creates new compliments every time you refresh. Mirror mirror on the wall.. Jude's developer personality is very similar to Manu Evans's but Manu is less of a D aficionado. Lol i doubt that. But I'll take it!
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 4:07 AM, Walter Bright wrote: http://wiki.dlang.org/DIP56 Manu has needed always inlining, and I've needed never inlining. This DIP proposes a simple solution. This makes inlining dependent on previously-seen code. Would that make parallel compilation more difficult? I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions. Andrei
Re: structs as large stack allocated objects vs structs as pass by value objects.
On Sunday, 23 February 2014 at 14:36:36 UTC, Arlon Brandy wrote:
Today I hit two problems essentially which got me thinking
about how structs are used in D by most of the code I've seen
so far. Both problems are in:
http://d.puremagic.com/issues/show_bug.cgi?id=9513
So the RedBlackTree create excessive copies of large structs
via binaryFun, that and the obvious workaround also
necessitates use of a template. It seems that people use
structs to indicate one of two things, they want a type they
can pass around and return by copy such as vectors/matrices
etc. or just a way to allocate something on the stack, usually
because of the need for deterministic resource handling or for
performance reasons.
One of the great things about the D is that it allows you to
specify with the type how it should be used by choosing struct
vs class, so you can say at the same time whether the data
should be stored on the heap and whether it should be passed by
copy or by reference.
It seems to me that it might nice also to have a sub-division
within the struct to allow the user to indicate a struct that
should be passed by reference also like a class. It could be
the same in every way except it's always passed by reference
and people would have to write their own dup or something for
when they want to copy it.
This could also solve the problem of:
functionWithRefParams(LargeStruct.init, LargeStruct.init)
These new structs would always be passed by reference, and I
guess lvalues would be transformed to temporary stack objects
by the compiler so that they never have to be copied. To me the
scope ref proposal looks a bit like C++ rvalue references and
I thought this might be simpler and more useful but I don't
know it's probably not a good idea.
There is also a work around (I can't remember who posted it
originally) but to move a struct to heap its basically:
struct T {}
T t;
T* ptrT = [t].ptr;
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 01:12:56 UTC, Andrei Alexandrescu wrote: This makes inlining dependent on previously-seen code. Would that make parallel compilation more difficult? I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions. Andrei That seems to be how Rust does it, but I'm not really clear how attributes work in Rust. http://static.rust-lang.org/doc/master/rust.html#inline-attributes
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 5:05 PM, Walter Bright wrote: On 2/23/2014 4:21 PM, Tove wrote: Inspecting asm output doesn't scale well to huge projects. Imagine simply updating the existing codebase to use a new compiler version. Again, this is treating 'inline' as being the only optimization that matters? It's not even the most important - that would likely be register allocation. At some point, you're going to need to trust the compiler. At this point, you're starting to argue that the entire DIP isn't relevant. I agree with the majority that if you're going to have the directive, then it needs to be enforcement, not suggestion.
Re: DIP56 Provide pragma to control function inlining
On 24/02/14 06:12, Walter Bright wrote: On 2/23/2014 1:41 PM, Namespace wrote: pragma(inline, true); pragma(inline, false); pragma(inline, default); 'default' being a keyword makes for an ugly special case in how pragmas are parsed. Aren't true and false keywords as well?
Re: DIP56 Provide pragma to control function inlining
Andrei Alexandrescu: I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions. Seems good. And what do you think the D compiler should do when you use @forceinline and it can't inline? Bye, bearophile
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:45 PM, Brad Roberts wrote: At this point, you're starting to argue that the entire DIP isn't relevant. I agree with the majority that if you're going to have the directive, then it needs to be enforcement, not suggestion. 1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code. 2. Making it a hard requirement then means the user will have to put versioning in it. It becomes inherently non-portable. There is no way to predict what some other version of some other compiler on some other system will do. 3. In the end, the compiler should make the decision. Inlining does not always result in faster code, as I pointed out in another post. 4. I don't see that users really are asking for inlining or not. They are asking for the fastest code. As such, providing hints about usage frequencies are entirely appropriate. Micromanaging the method used is not so appropriate. After all, the reason one uses a compiler in the first place rather than assembler is to not micromanage the actual instructions. Perhaps the lesson is the word 'inline' carries certain expectations with it, and the feature would be better positioned as something like: pragma(usage, often); pragma(usage, rare);
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:12 PM, Andrei Alexandrescu wrote: This makes inlining dependent on previously-seen code. Would that make parallel compilation more difficult? I don't understand the question. Inlining always depends on the compiler having seen the function body. I've always thought the obvious/simple way would be an attribute such as @forceinline and @noinline that applies to individual functions. Since inlining can't be done without the function body, putting the pragma in the function body makes sense.
