Re: C header file: tagged enumerations
On Thursday, 28 April 2016 at 17:40:23 UTC, Jesse Phillips wrote:
enum tagINSTALLMESSAGE
{
// 12 others ...
INSTALLMESSAGE_INITIALIZE ,
INSTALLMESSAGE_TERMINATE ,
INSTALLMESSAGE_SHOWDIALOG ,
[greaterThan(500)]
INSTALLMESSAGE_PERFORMANCE,
[greaterThan(400)]
INSTALLMESSAGE_RMFILESINUSE ,
[greaterThan(450)]
INSTALLMESSAGE_INSTALLSTART ,
[greaterThan(450)]
INSTALLMESSAGE_INSTALLEND ,
}
mixin taggedEnum!tagINSTALLMESSAGE
FYI, that is a no since attributes can't be added to enumerations.
"Error: basic type expected, not @"
Re: C header file: tagged enumerations
On Thursday, 28 April 2016 at 08:54:45 UTC, Kagamin wrote:
enum
{
// 12 others ...
INSTALLMESSAGE_INITIALIZE ,
INSTALLMESSAGE_TERMINATE ,
INSTALLMESSAGE_SHOWDIALOG
}
static if(_WIN32_MSI >= 500)
enum INSTALLMESSAGE_PERFORMANCE=15;
static if(_WIN32_MSI >= 400)
enum INSTALLMESSAGE_RMFILESINUSE=16;
static if(_WIN32_MSI >= 450)
enum
{
INSTALLMESSAGE_INSTALLSTART=17,
INSTALLMESSAGE_INSTALLEND
}
This one doesn't get the values right for the different versions.
The other problem is functions are written as:
void* something(INSTALLMESSAGE arg);
So I could make all the functions take an int/uint or such, but
that is a lot of change for the header along with less
documenting.
Re: Constructing an enum using the members of an AliasSeq as enumerator names
On Wednesday, 27 April 2016 at 15:30:55 UTC, ag0aep6g wrote: That takes longer to compile, though. Probably needs more memory as well. Thanks! Added here https://github.com/nordlow/phobos-next/blob/master/src/typecons_ex.d#L425
Re: C header file: tagged enumerations
On Wednesday, 27 April 2016 at 16:04:13 UTC, Steven Schveighoffer
wrote:
BTW, this enumeration looks terrible. I would flag this as
blocking if it were a code review, even in C++.
-Steve
Yeah, I didn't even consider that different versions have
different enum values; that is going to be a really good way to
break backwards compatibility.
Hmm, I wonder if I can make use of UDA and a mixin something like
enum tagINSTALLMESSAGE
{
// 12 others ...
INSTALLMESSAGE_INITIALIZE ,
INSTALLMESSAGE_TERMINATE ,
INSTALLMESSAGE_SHOWDIALOG ,
[greaterThan(500)]
INSTALLMESSAGE_PERFORMANCE,
[greaterThan(400)]
INSTALLMESSAGE_RMFILESINUSE ,
[greaterThan(450)]
INSTALLMESSAGE_INSTALLSTART ,
[greaterThan(450)]
INSTALLMESSAGE_INSTALLEND ,
}
mixin taggedEnum!tagINSTALLMESSAGE
Re: relative benefit of .reserve and .length
On 4/28/16 9:09 AM, Basile B. wrote: Out of an appender I believe .reserve can be used to force page creation if you know that several pages will be allocated. For example for an ubyte[] when .length goes from 16 to 17 the memory block *really* allocated by realloc goes from 16 to 4096. Hm... I don't think that's the behavior that the GC did, but maybe it's changed. It should go in powers of 2 up to 4096. And there is extra data needed for determining the length. So really, it's from 15 to 16 (may be less now that the GC calls dtors), and it should go from 16 bytes to 32 with normal append. If you reserve, you can specify a higher starting point (e.g. 4096 if you wish). -Steve
Re: relative benefit of .reserve and .length
On 4/28/16 8:56 AM, Jay Norwood wrote: I timed some code recently and found that .reserve made almost no improvement when appending. It appears that the actual change to the length by the append had a very high overhead of something over 200 instructions executed, regardless if the .reserve was done. This was a simple append to an integer array. .reserve should make an improvement for large amount of appending, since you pre-allocate the data. However, the operation to append is still quite slow, it involves calling a druntime function that cannot be inlined, and must do a bunch of operations to lookup the current defined length in the array. The way I look at it is a compromise between efficiency and convenience (the fact that you can simply append to any slice anywhere is liberating). In my experience, the appending operation was slower before my changes to the runtime (and .reserve was added at that time). What .reserve does is prevent the incremental allocation growth and copying the data from one block to another (not to mention less strain on the GC). It does not reduce the function calls or the lookup of metadata. Let's say you are appending 100,000 integers to an array. At 50,000, it cannot extend any more, so it must allocate a new block. This means the GC must find a larger block (in addition to the ones it has already incrementally allocated to get to 50,000) to accommodate the data, and then copy all the data over. This is the operation that is saved with .reserve. The only way I found to avoid this was to set the length outside the loop and update the array values by index. That was on the order of 10x faster. This is ALWAYS going to be much faster, as setting an element is 2 instructions at the most. That vs. a runtime call is always going to win. If you can do it this way, I'd recommend doing so. Array appending operation is for convenience, at a reasonable performance. -Steve
Re: relative benefit of .reserve and .length
On Thursday, 28 April 2016 at 12:56:24 UTC, Jay Norwood wrote: I timed some code recently and found that .reserve made almost no improvement when appending. It appears that the actual change to the length by the append had a very high overhead of something over 200 instructions executed, regardless if the .reserve was done. This was a simple append to an integer array. The only way I found to avoid this was to set the length outside the loop and update the array values by index. That was on the order of 10x faster. Have you looked at the way .reserve is used in Appender ? In this struct reserving has a true impact. Exactly the opposite of what you've observed: if nothing is reserved in an appender then the Appender is not worth (unfortunately I have a benchmark for this but on another machine :/). Out of an appender I believe .reserve can be used to force page creation if you know that several pages will be allocated. For example for an ubyte[] when .length goes from 16 to 17 the memory block *really* allocated by realloc goes from 16 to 4096.
relative benefit of .reserve and .length
I timed some code recently and found that .reserve made almost no improvement when appending. It appears that the actual change to the length by the append had a very high overhead of something over 200 instructions executed, regardless if the .reserve was done. This was a simple append to an integer array. The only way I found to avoid this was to set the length outside the loop and update the array values by index. That was on the order of 10x faster.
Re: C header file: tagged enumerations
enum
{
// 12 others ...
INSTALLMESSAGE_INITIALIZE ,
INSTALLMESSAGE_TERMINATE ,
INSTALLMESSAGE_SHOWDIALOG
}
static if(_WIN32_MSI >= 500)
enum INSTALLMESSAGE_PERFORMANCE=15;
static if(_WIN32_MSI >= 400)
enum INSTALLMESSAGE_RMFILESINUSE=16;
static if(_WIN32_MSI >= 450)
enum
{
INSTALLMESSAGE_INSTALLSTART=17,
INSTALLMESSAGE_INSTALLEND
}
Re: vibe.d is blocking threads
On Wednesday, 27 April 2016 at 23:30:10 UTC, Nicholas Wilson
wrote:
On Wednesday, 27 April 2016 at 13:00:29 UTC, RuZzz wrote:
Code:
import std.concurrency;
import core.thread;
//import vibe.http.client; // If uncommented this
line, the thread "worker" does not start
void worker() {
foreach (i; 0 .. 5) {
Thread.sleep(500.msecs);
writeln(i, " (worker)");
}
}
void main() {
spawn();
foreach (i; 0 .. 5) {
Thread.sleep(300.msecs);
writeln(i, " (main)");
}
writeln("main is done.");
}
How to launch threads with vibe.d? It doesn't work at both
compilers.
You don't. vibe.d uses fibers (aka green threads).
That doesn't matter. Native threads should work just fine, I'm
using them without problems in a vibe.d app.
Could it be that your main() function is never called at all? Try
to insert a writeln() at the beginning. If so, this could be
related to the "VibeDefaultMain" setting, see here:
http://vibed.org/docs#custom-main
