Re: Minor Bug
The hidden camera detector which can be got from http://www.detectorall.com/categories/Radio-Frequency-Detector/ can be called vehicle inspection which have a good function of detecting metals and even some potential danger signals. They can bring much safety and convenience to people's life. We have to admit that the advanced technology always gives us surprise and joy.
Re: C++ Binding Generator
On 17 February 2014 06:05, Abdulhaq wrote: > On Sunday, 16 February 2014 at 02:37:50 UTC, michaelc37 wrote: > >> >>> The code is tested and just-about one-click build. Currently it's >>> in a subversion repository but I plan to move to github. I'd love >>> someone to use Smidgen to try wrapping a small C++ library as I >>> think it would make the job quite easy, if anyone reads this >>> (since I have not formally announced the thing yet) then please >>> let me know and I'll get the code out there). >>> >>> yes github please.. i'd like to check this out. >> > > OK I believe that smidgen is now fully hosted on github. > > Using smidgen as it stands I would hope that you could wrap a simple C++ > library. However, no-one else has tried it yet so there are bound to be a > few teething problems, please feel free to email me (anyone trying it out > or just taking a look) at alynch4047 at gmail dot com if you have any > questions / problems. Alternatively perhaps we could use one of the forums > here?? > > I have not yet uploaded the initial Qt5 wrapping (or VTK), I'll try to do > that over the next day or two. > This is awesome. I have a comprehensive game engine, and I've been looking for a solution to auto-generate my D bindings, but so far, I haven't found anything capable of doing a proper job. I'll definitely be checking this out. I maintain bindings by hand currently, and I'm often fighting with keeping them in sync. I have a couple of interesting requirements, I'll be curious to see how it works out in practise.
Re: DIP56 Provide pragma to control function inlining
On Feb 24, 2014 2:10 AM, "Walter Bright" wrote: > > 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); Also known as, hot and cold functions. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: DIP56 Provide pragma to control function inlining
On Feb 24, 2014 1:15 AM, "Andrei Alexandrescu" < seewebsiteforem...@erdani.org> wrote: > > 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 > GDC already has both of these as a compiler extended attribute (need to document these!!!) import gcc.attribute; @attribute("forceinline") ... Being backend attributes, you can't enforce that these attributes actually take effect in user code (no static asserts!) - but you have some guarantee in that the backend will complain if it can't apply the attribute - this is good because the compiler will always produce a better diagnostic than some user static assert, always. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Strategy for Traction
On Sun, 2014-02-23 at 19:53 +, bearophile wrote: > 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. ShedSkin certainly isn't keeping up with the programme and working with Python 3 so I have never tried it. Julia is a system I keep up with, it is splendid. And there is even now a London Julia user group. User group activity is likely a measure of involvement: Java and JVM technology groups have no problem having meetings with attenders. Go went from 20 → 120 attenders per month in a year. Python has activity. Julia has a new user group. I suspect D has no user group activity because it is a 10 year old language very few people have heard about. It needs a marketing reboot so as to be new and exciting and attract people to attend meetings. -- 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: Open Source Report Card
>> And I realized I meant symmetrical. IIRC reflexive means you're your own >> friend. >> That would be a very sad message from osrc: the coder you're the most close >> is... yourself. Go hide under a rock! > > > http://osrc.dfm.io/MartinNowak > >> Martin's developer personality is very similar to Martin Nowak's >> It seems like Martin is—or should be—friends with Martin Nowak. Come on, we all know Martin is exceptional. This proves it!
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 8:26 PM, Vladimir Panteleev wrote: On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu wrote: I'll add an anecdote - in HHVM we owe a lot of speedups to the careful use of "never inline" and "always inline" gcc pragmas IN ADDITION TO the usual "inline" directives. We have factual proof that gcc makes the wrong inline decisions BOTH WAYS if left to decide. If we define pragmas for inlining, "always inline" must mean always inline no questions asked and "never inline" must mean always prevent inlining no questions asked. Anything else would be a frustrating waste of time. I think there is another, distinct use case for an inline pragma where "try to inline" is useful - namely, turning on the equivalent of the compiler "-inline" switch for just one function. I believe this is the original rationale behind the DIP (enabling inlining for certain functions even in debug builds, because otherwise the debug builds become so slow as to be unusable). In this case, whether the compiler actually succeeds at inlining the function doesn't matter as long as it does the same thing as for an optimized (-inline) build. Thus, I think there should be "try to inline" (same as -inline) and "always inline" (failure stops compilation). Sounds fair enough. Andrei
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 02:05:31 UTC, Walter Bright wrote: 1. It provides information to the compiler about runtime frequency that it cannot obtain otherwise. This is very useful information for generating better code. This answers to your own previous question: this is what makes "inline" a special optimization. 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. Honestrly, in the small profiling I've done in my life, at least inlining never made my code slower. But I do realize this is not relevant to the discussion. 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); Yes, I think "inline" carries huge expectations: the expectation for the compiler to comply. If the plan is hinting frequency information, then "usage" makes way more sense. It might be used in if blocks and in switch cases too, when branch prediction might be sloppy or unoptimal.
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 6:05 PM, Walter Bright wrote: 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. In HHVM we plainly ask for specific decisions on inlining or not. We have a reasonably good understanding of how and where our code has trouble with ICache misses, and adjust our inline decisions and validate using experiments. A decision to force inlining or against it already indicates a failure of the compiler's heuristics to address the situation. Keeping it an option is insisting on failing. 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); That's an interesting unrelated idea. But if we defined pragmas to "force inline" and "never inline" we must damn sure make sure the compiler always does that. It's "listen to your customers" as plainly as it gets. Andrei
Re: DIP56 Provide pragma to control function inlining
On Monday, 24 February 2014 at 04:14:08 UTC, Andrei Alexandrescu wrote: I'll add an anecdote - in HHVM we owe a lot of speedups to the careful use of "never inline" and "always inline" gcc pragmas IN ADDITION TO the usual "inline" directives. We have factual proof that gcc makes the wrong inline decisions BOTH WAYS if left to decide. If we define pragmas for inlining, "always inline" must mean always inline no questions asked and "never inline" must mean always prevent inlining no questions asked. Anything else would be a frustrating waste of time. I think there is another, distinct use case for an inline pragma where "try to inline" is useful - namely, turning on the equivalent of the compiler "-inline" switch for just one function. I believe this is the original rationale behind the DIP (enabling inlining for certain functions even in debug builds, because otherwise the debug builds become so slow as to be unusable). In this case, whether the compiler actually succeeds at inlining the function doesn't matter as long as it does the same thing as for an optimized (-inline) build. Thus, I think there should be "try to inline" (same as -inline) and "always inline" (failure stops compilation).
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 5:55 PM, bearophile wrote: 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? Compile-time error, no two ways about it. Andrei
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 6:12 PM, Walter Bright wrote: 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. Decision to inline at line 2000 may be caused by a pragma in line 2. Andrei
Re: Permission to migrate "How-tos"->"Tech Tips" to the wiki
On 2/23/2014 7:15 PM, Mike wrote: The "How-tos"->"Tech Tips" on dlang.org link to http://digitalmars.com/techtips/index.html. I would like to move these to the wiki in an effort to elicit more community participation in maintaining D's documentation. However, these are copyright Digital Mars. May I have permission to move these to the wiki? Yes, feel free.
Re: DIP56 Provide pragma to control function inlining
On 2/23/14, 4:33 PM, Walter Bright wrote: 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? I'll add an anecdote - in HHVM we owe a lot of speedups to the careful use of "never inline" and "always inline" gcc pragmas IN ADDITION TO the usual "inline" directives. We have factual proof that gcc makes the wrong inline decisions BOTH WAYS if left to decide. If we define pragmas for inlining, "always inline" must mean always inline no questions asked and "never inline" must mean always prevent inlining no questions asked. Anything else would be a frustrating waste of time. Andrei
Permission to migrate "How-tos"->"Tech Tips" to the wiki
The "How-tos"->"Tech Tips" on dlang.org link to http://digitalmars.com/techtips/index.html. I would like to move these to the wiki in an effort to elicit more community participation in maintaining D's documentation. However, these are copyright Digital Mars. May I have permission to move these to the wiki? Thanks, Mike
Re: DIP56 Provide pragma to control function inlining
On Sun, 23 Feb 2014 21:05:32 -0500, Walter Bright wrote: 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. But you are under-utilizing the message. There is the case that one wants inlining, even when -inline isn't passed to the compiler, for functions that would have been inlined if -inline was specified. That is your case, right? But there is a case where the compiler for some reason has decided that inlining a function is not worth it, so even with -inline it doesn't do it. However, without the inlining, the function becomes horrendously slow. For example, functions that contain lazy parameters. 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. This is not a problem. The whole point is, if the compiler doesn't support the inlining, the code is useless. I WANT it to fail, there is no reason to version it out. 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. Huh? Then why even have the feature if the compiler is going to ignore your request! This feature sounds completely useless to me, it certainly adds no real value that warrants adding a pragma. It may as well be called pragma(please_inline_pretty_pretty_please_ill_be_your_best_friend) 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. Compilers are not infallible. They may make mistakes, or not have enough information, which is the point of this feature. What is to say they don't make mistakes even with the correct amount of information? And the reason I use a compiler rather than assembler is because I hate writing assembler :) 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); This is totally the wrong tack. First, I may have no idea how often a function will be used. Second, usage frequency has nothing to do with how inlining may affect the performance of an individual call. If an inlined function always executes faster than calling the function, I always want to inline. For example, foo: void foo(ref int x) { ++x; } -Steve
Re: DIP56 Provide pragma to control function inlining
On 23/02/14 20: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. void A() { } void B() { pragma(inline, true) A(); } void C() { B(); } Reading that code, I would guess that within B(), the call to A() would get inlined. Reading the DIP, it appears that the pragma controls whether B() gets inlined. When the pragma is used outside of the scope at the function declaration it would work more like "inline" or "__inline" in C++, correct? L.
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.
Re: DIP56 Provide pragma to control function inlining
On 2/23/2014 5:47 PM, Lionello Lunesu wrote: 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? Yes, but the are also expressions. default is not.
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
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 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
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 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: 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 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: Open Source Report Card
On 2/22/14, 8:33, Andrej Mitrovic wrote: On 2/22/14, simendsjo 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/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: 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: 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
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: 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
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 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 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 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
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
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
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
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 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: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:32 PM, Francesco Cattoglio wrote: [...] I addressed these three messages in another reply to Dmitry.
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 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: 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 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 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 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: 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: 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: 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: 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: Move some guides to the DWiki - yay or nay?
On 2/23/14, Dicebot 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
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 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 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: 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: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: 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 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: 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: 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: 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: 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: 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: 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: Porting my Integer Sorting Algorithms to D
I guess this component would be integrated into std.algorithm when its ready, right?
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: 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: 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: 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: 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 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
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
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 4546878u
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
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: 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 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
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: 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
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 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
Re: DIP56 Provide pragma to control function inlining
On 23 February 2014 14:19, Tove 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 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: 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
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: [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
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: 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 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
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 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
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 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 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: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 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.)