Re: TechEmpower Web Framework Performance Comparison Round 13 -- vibe.d non-starter?
On Thursday, 17 November 2016 at 17:49:09 UTC, sanjayss wrote: https://www.techempower.com/benchmarks/#section=data-r13&hw=ph&test=json anyone know why vibe.d is shown as "Did not complete" in all tests? So I have investigated it and find out the reason is probably some memory leak. It is impossible to run vibed test. Every time it is killed by oom killer or there is a exception about unable to allocate memory. But when I enable VibeManualMemoryManagement version it works ok (2GB+ -> 600MB)
Re: OT: for (;;) {} vs while (true) {}
Why you consider only 2 options?
Use "do {} while (true);" :-)
Re: ESA's Schiaparelli Mars probe crashed because of integer overflow
On Thursday, 24 November 2016 at 20:22:00 UTC, Timon Gehr wrote: On 24.11.2016 20:49, qznc wrote: Although, the article [0] does not say that literally, it sounds like an integer overflow: After trawling through mountains of data, the European Space Agency said Wednesday that while much of the mission went according to plan, a computer that measured the rotation of the lander hit a maximum reading, knocking other calculations off track. That led the navigation system to think the lander was much lower than it was, causing its parachute and braking thrusters to be deployed prematurely. "The erroneous information generated an estimated altitude that was negative—that is, below ground level," the ESA said in a statement. That is why we need CheckedInt, folks. Reminder End. ;) [0] http://phys.org/news/2016-11-glitch-blamed-european-mars-lander.html I don't think overflow is what happened. Rather, the statistical model they used to filter the sensor data didn't match reality. It put too much trust into a malfunctioning sensor -- I assume the sensor readings were extremely implausible. Hey, sounds suspicously similar to Ariane 5 explosion. Does ESA not learn from its errors or am I only reading too much in it (probably)?
Re: OT: for (;;) {} vs while (true) {}
On 11/24/2016 05:09 PM, Dennis Ritchie wrote:
On Thursday, 24 November 2016 at 22:04:00 UTC, LiNbO3 wrote:
As you can see [1] the `while (true)` is lowered into `for (;true;)`
so it's all about what construct pleases you the most.
[1]
https://github.com/dlang/dmd/blob/cd451ceae40d04f7371e46df1c955fd914f3085f/src/statementsem.d#L357
OK, thanks.
The next question is:
What principles guided when choosing between `for (;;) { ... }` and
`while (true) { ... }` ?
For example, there are two options:
https://github.com/dlang/phobos/blob/master/std/algorithm/sorting.d
I wouldn't ding anyone in a code review for using one vs the other. --
Andrei
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 08:36:41 UTC, Andrea Fontana wrote: On Wednesday, 23 November 2016 at 17:31:58 UTC, Kagamin wrote: On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei Alexandrescu wrote: Interesting. Could you please add a couple of links about that? -- Andrei http://xoroshiro.di.unimi.it/ Very short public domain implementation: http://xoroshiro.di.unimi.it/xoroshiro128plus.c Implementation in D, written during DConf 2016 ;-) https://github.com/WebDrake/dxorshift
Re: OT: for (;;) {} vs while (true) {}
On Thursday, 24 November 2016 at 22:04:00 UTC, LiNbO3 wrote:
As you can see [1] the `while (true)` is lowered into `for
(;true;)` so it's all about what construct pleases you the most.
[1]
https://github.com/dlang/dmd/blob/cd451ceae40d04f7371e46df1c955fd914f3085f/src/statementsem.d#L357
OK, thanks.
The next question is:
What principles guided when choosing between `for (;;) { ... }`
and `while (true) { ... }` ?
For example, there are two options:
https://github.com/dlang/phobos/blob/master/std/algorithm/sorting.d
Re: OT: for (;;) {} vs while (true) {}
On Thursday, 24 November 2016 at 21:57:15 UTC, Dennis Ritchie
wrote:
Hi all,
In the source code, written in D, is often used in the design
of the `for (;;) { ... }`
Maybe someone has specific examples of translation of code in
asm, where `while (true) { ... }` or `for (;;) { ... }` affect
the performance or cross-platform programs.
It would be interesting to see samples.
As you can see [1] the `while (true)` is lowered into `for
(;true;)` so it's all about what construct pleases you the most.
[1]
https://github.com/dlang/dmd/blob/cd451ceae40d04f7371e46df1c955fd914f3085f/src/statementsem.d#L357
OT: for (;;) {} vs while (true) {}
Hi all,
In the source code, written in D, is often used in the design of
the `for (;;) { ... }`
Maybe someone has specific examples of translation of code in
asm, where `while (true) { ... }` or `for (;;) { ... }` affect
the performance or cross-platform programs.
It would be interesting to see samples.
Re: ESA's Schiaparelli Mars probe crashed because of integer overflow
On 24.11.2016 20:49, qznc wrote: Although, the article [0] does not say that literally, it sounds like an integer overflow: After trawling through mountains of data, the European Space Agency said Wednesday that while much of the mission went according to plan, a computer that measured the rotation of the lander hit a maximum reading, knocking other calculations off track. That led the navigation system to think the lander was much lower than it was, causing its parachute and braking thrusters to be deployed prematurely. "The erroneous information generated an estimated altitude that was negative—that is, below ground level," the ESA said in a statement. That is why we need CheckedInt, folks. Reminder End. ;) [0] http://phys.org/news/2016-11-glitch-blamed-european-mars-lander.html I don't think overflow is what happened. Rather, the statistical model they used to filter the sensor data didn't match reality. It put too much trust into a malfunctioning sensor -- I assume the sensor readings were extremely implausible.
ESA's Schiaparelli Mars probe crashed because of integer overflow
Although, the article [0] does not say that literally, it sounds like an integer overflow: After trawling through mountains of data, the European Space Agency said Wednesday that while much of the mission went according to plan, a computer that measured the rotation of the lander hit a maximum reading, knocking other calculations off track. That led the navigation system to think the lander was much lower than it was, causing its parachute and braking thrusters to be deployed prematurely. "The erroneous information generated an estimated altitude that was negative—that is, below ground level," the ESA said in a statement. That is why we need CheckedInt, folks. Reminder End. ;) [0] http://phys.org/news/2016-11-glitch-blamed-european-mars-lander.html
Re: Mir Random [WIP]
On 24.11.2016 14:50, Kagamin wrote: On Thursday, 24 November 2016 at 12:02:22 UTC, John Colvin wrote: Because it's correct. If a.length is larger than int.max then cast(int)a.length will half the time be negative and therefore a simple rightshift would not be equivalent to division by 2. It can't be possibly correct when a.length is larger than int.max because it doesn't recover information lost in a narrowing conversion. The code does not specify that this information should be recovered. Why is this the compiler's problem?
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 17:04:43 UTC, John Colvin wrote: If druntime was initialised by default using __attribute__((constructor)) for static and linker .init for shared libraries, would that be good enough for you*? I feel like you're limiting your design choices because of a relatively small and simple implementation shortcoming. * remember, we don't currently guarantee ABI compatibility between compiler versions even if you don't use druntime/phobos. No, it should work without DRuntime. Nicholas wrote that it will work on GPU using dcompute :-) BetterC is the goal for the future Mir-Phobos, hehe
Re: CTFE Status
I have just discovered breakage of basic operations. I will need regression tests, some time soon.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 16:09:23 UTC, Ilya Yaroshenko wrote: On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis wrote: Alternatively, you could just do rndGen().take(1).front, and as long as rndGen() gives you a reference type, it works just fine. Unfortunately, std.random did not use reference types for its ranges. _That_ is the big mistake of std.random and the main item that needs to be fixed. There are some other subtleties (e.g. it's useful to be able to save the state of a random number generating range, but you don't necessarily really want it to be a forward range), but those are minor in comparison to the mistake of std.random using value types rather than reference types for ranges. - Jonathan M Davis The fix is opCall syntax. Reference types are classes, which would not work without linking DRuntime and Phobos (BetterC). If druntime was initialised by default using __attribute__((constructor)) for static and linker .init for shared libraries, would that be good enough for you*? I feel like you're limiting your design choices because of a relatively small and simple implementation shortcoming. * remember, we don't currently guarantee ABI compatibility between compiler versions even if you don't use druntime/phobos.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis wrote: Alternatively, you could just do rndGen().take(1).front, and as long as rndGen() gives you a reference type, it works just fine. Unfortunately, std.random did not use reference types for its ranges. _That_ is the big mistake of std.random and the main item that needs to be fixed. There are some other subtleties (e.g. it's useful to be able to save the state of a random number generating range, but you don't necessarily really want it to be a forward range), but those are minor in comparison to the mistake of std.random using value types rather than reference types for ranges. - Jonathan M Davis The fix is opCall syntax. Reference types are classes, which would not work without linking DRuntime and Phobos (BetterC). Refcounting is to slow to implement for users. Note, that Engines is only backend RNGs. There are also nonuniform distributions (WIP). See the example of users code: https://forum.dlang.org/post/nyvtoejvmsaolzaqy...@forum.dlang.org . It is very difficult to implement both user random variable and Engine using Range API. Note, that code should work without DRuntime and should be simple (the example is user code). Ilya
Re: Detect that a child is waiting for input
The program which stops even run without "&":
#!/usr/bin/rdmd
import std.stdio;
import std.file;
import std.string;
import core.sys.posix.unistd;
import core.stdc.errno;
import core.stdc.string;
void main()
{
int res = core.sys.posix.unistd.tcsetpgrp(0, getppid());
if (res != 0)
{
writefln("tcsetpgrp error: %s",
fromStringz(strerror(errno)).idup());
return;
}
foreach (line; stdin.byLine)
{
writefln(line);
}
}
But really it is not decision.. The program stops not because
where is no input, but because there is other process reading
terminal..
It is not that I need..
Re: Mir Random [WIP]
On Thursday, November 24, 2016 13:54:50 Kagamin via Digitalmars-d wrote: > On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis > > wrote: > > How so? Because someone might call range.front again without > > bothering to call popFront? > > That's what everything in std.algorithm does. Then call popFront or drop before passing it along if you're paranoid about it. If it's a serious concern that this be fixed in general, then the obvious fix to that would be to make it so that rndGen() just called popFront before returning it. Heck, if rndGen() were guaranteed to call popFront when it was called rather than simply returning the range, then you could just do rndGen().front whenever you wanted the equivalent of rand(), making it trivial to use rndGen() both for cases where you wanted a single number and for cases where you wanted a range of them - and without worrying about front being stale. - Jonathan M Davis
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 13:45:40 UTC, Jonathan M Davis wrote: How so? Because someone might call range.front again without bothering to call popFront? That's what everything in std.algorithm does.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 12:02:22 UTC, John Colvin wrote: Because it's correct. If a.length is larger than int.max then cast(int)a.length will half the time be negative and therefore a simple rightshift would not be equivalent to division by 2. It can't be possibly correct when a.length is larger than int.max because it doesn't recover information lost in a narrowing conversion.
Re: Mir Random [WIP]
On Thursday, November 24, 2016 09:05:34 Kagamin via Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 21:33:53 UTC, Jonathan M Davis
>
> wrote:
> > though I think that using the comma operator like that is
> > deprecated now. Adding a helper function such as
> >
> > auto getNext(R)(ref R range)
> > if(isInputRange!R)
> > {
> > range.popFront();
> > return range.front;
> > }
> >
> > would solve that problem.
>
> It's the same behavior and suffers from the same problem of reuse
> of RNG output.
How so? Because someone might call range.front again without bothering to
call popFront? If you're paranoid about that, then it can call popFront
again before returning (though that would be wasteful).
My take on it is that if you just call popFront before using the random
number generator range, then you don't have to worry about what any other
code that used it did.
Regardless, the range API is _way_ more useful in general than something
like rand(). And if anyone is trying to avoid ranges with random numbers, I
think that they're just making their life harder. Occasionally, it's useful
to get just one random number, in which case, having to deal with the range
API over rand() is kind of annoying, but in general, it's not a problem, and
the wrapper function that I suggested basically gives you rand() from a
range of random numbers.
Alternatively, you could just do rndGen().take(1).front, and as long as
rndGen() gives you a reference type, it works just fine. Unfortunately,
std.random did not use reference types for its ranges. _That_ is the big
mistake of std.random and the main item that needs to be fixed. There are
some other subtleties (e.g. it's useful to be able to save the state of a
random number generating range, but you don't necessarily really want it to
be a forward range), but those are minor in comparison to the mistake of
std.random using value types rather than reference types for ranges.
- Jonathan M Davis
Re: Detect that a child is waiting for input
You can detect whether another process received a signal by ptracing it. If you are only ptracing for signals, then the performance penalty shouldn't be too severe. Shachar On 24/11/16 12:35, unDEFER wrote: On Wednesday, 23 November 2016 at 07:18:27 UTC, Shachar Shemesh wrote: The shell does that for background processes. I think it takes away the TTY from its children, and this way, when they try to read from stdin, they get SIGSTOP from the system. I'm not sure what the precise mechanism is. There are flags passed to wait which will cause it to report when a child gets SIGSTOP. Hope this helps, Shachar So, I have found with strace, this signal is SIGTTIN is special signal which sends to _background_ task when it tries to read from terminal. So it is possible such detect when I will write not simple pipeProcess, but will write terminal emulator. Thank you.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 10:41:44 UTC, Kagamin wrote: On Thursday, 24 November 2016 at 10:16:11 UTC, John Colvin wrote: I was talking about andrei's example. He has a cast(int) in it before the division. And you think that compilation of cast(int)a.length/2 to 3 instructions is optimized just fine? How is it better that one shift? Because it's correct. If a.length is larger than int.max then cast(int)a.length will half the time be negative and therefore a simple rightshift would not be equivalent to division by 2.
Re: Detect that a child is waiting for input
Here is good information about difference between foreground process groups and background: https://www.win.tue.nl/~aeb/linux/lk/lk-10.html Shortly, there is only one process group which is foreground, you can get it with tcgetpgrp(fd) or set it with tcsetpgrp(fd,pgrp). To setup process group of the process use setpgid(pid, pgid);
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 10:16:11 UTC, John Colvin wrote: I was talking about andrei's example. He has a cast(int) in it before the division. And you think that compilation of cast(int)a.length/2 to 3 instructions is optimized just fine? How is it better that one shift?
Re: Detect that a child is waiting for input
On Wednesday, 23 November 2016 at 07:18:27 UTC, Shachar Shemesh wrote: The shell does that for background processes. I think it takes away the TTY from its children, and this way, when they try to read from stdin, they get SIGSTOP from the system. I'm not sure what the precise mechanism is. There are flags passed to wait which will cause it to report when a child gets SIGSTOP. Hope this helps, Shachar So, I have found with strace, this signal is SIGTTIN is special signal which sends to _background_ task when it tries to read from terminal. So it is possible such detect when I will write not simple pipeProcess, but will write terminal emulator. Thank you.
Re: CTFE Status
On Monday, 21 November 2016 at 19:19:50 UTC, Stefan Koch wrote: On Monday, 21 November 2016 at 19:11:58 UTC, Anonymouse wrote: On Sunday, 20 November 2016 at 09:02:30 UTC, Stefan Koch wrote: On Saturday, 19 November 2016 at 11:22:18 UTC, Stefan Koch wrote: [...] I would buy you a beer but the Internet is in the way. I appreciate the offer. During the next days I will hopefully be able to have the first arrays of structures working. Those are a bit tricky since they require doubly-indirected RMW. Progress is still stalled on this. It is very important to get pointers and handling of other qusi-references right. There are still known bugs in switch processing, also the llvm-backend need to be fixed.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 10:14:27 UTC, Kagamin wrote: On Thursday, 24 November 2016 at 09:46:16 UTC, John Colvin wrote: That's because of the cast(int), dividing by two is optimised just fine. What about Andrei's example? I was talking about andrei's example. He has a cast(int) in it before the division.
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 09:46:16 UTC, John Colvin wrote: That's because of the cast(int), dividing by two is optimised just fine. What about Andrei's example?
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 08:55:18 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei
Alexandrescu wrote:
[Details needed]
I just took a look https://godbolt.org/g/EMy6X4, it's
happening.
That's three instructions instead of one shr eax,1
That's because of the cast(int), dividing by two is optimised
just fine. You can even do this:
int foo(int a) { return a / 2; }
uint foo(uint a) { return a / 2; }
int bar(int a)
{
if (a > 0) return a / 2;
else assert(0);
}
and get
int example.foo(int): // slow, to deal with sign
mov eax, edi
shr eax, 31
add eax, edi
sar eax
ret
uint example.foo(uint): // fast because no sign
mov eax, edi
shr eax
ret
int example.bar(int): // single shift because sign always 0
testedi, edi
jle .L8
mov eax, edi
sar eax
ret
.L8:
ud2
This should help explain why the extra/different instructions are
necessary for signed:
int foo0(int a)
{
asm
{
naked;
mov EAX, EDI;
shr EAX, 31;
add EAX, EDI;
sar EAX, 1;
ret;
}
}
int foo1(int a)
{
asm
{
naked;
mov EAX, EDI;
sar EAX, 1;
ret;
}
}
int foo2(int a)
{
asm
{
naked;
mov EAX, EDI;
shr EAX, 1;
ret;
}
}
void main()
{
import std.stdio;
foreach(i; [int.min, -1, 0, 1, int.max])
writeln(foo0(i), ' ', foo1(i), ' ', foo2(i));
}
output:
-1073741824 -1073741824 1073741824
0 -1 2147483647
0 0 0
0 0 0
1073741823 1073741823 1073741823
Re: Mir Random [WIP]
On 23.11.2016 00:55, Andrei Alexandrescu wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to C++)
This seems like a gratuitous departure from common D practice. Random
number generators are most naturally modeled in D as infinite ranges. --
Andrei
I would posit that it is not actually natural to model random numbers as
ranges. Not every random object is a sequence. Different samples are
(ideally) independent, so there is little conceptual motivation to group
them together -- it just increases the logistic overhead needed to get
at the single samples. I.e., the most natural way to use a PRNG range is
as follows:
PRNG range;
auto sample(){
auto r=range.front;
range.popFront();
return r;
}
PRNGs are an example where global state is actually desirable, because
in contrast to most other programming tasks, usually less predictability
is good.
Re: Mir Random [WIP]
On Wednesday, 23 November 2016 at 16:54:44 UTC, Andrei Alexandrescu wrote: On 11/23/2016 10:52 AM, Ilya Yaroshenko wrote: I started with Engines as basis. The library will be very different comparing with Phobos and _any_ other RNG libraries in terms of floating point generation quality. All FP generation I have seen are not saturated (amount of possible unique FP values are very small comparing with ideal situation because of IEEE arithmetic). I have not found the idea described by others, so it may be an article in the future. Is this a design matter, or an implementation matter? Could you implement the superior FP generation on the existing std.random API? Real uniform `rand` (-2^^exp, +2^^exp) and real UniformVariable [a, b) was added. `rand` dose not use IEEE arithmetic to generate a real random number. --Ilya
Re: Mir Random [WIP]
On Thursday, 24 November 2016 at 08:59:03 UTC, Kagamin wrote: On Wednesday, 23 November 2016 at 19:40:47 UTC, Ilya Yaroshenko wrote: Current adaptor should be used in a function scope. (Would be great to have a DIP for that kind of semantic check). An RC adaptor can be added too. First we need to find a real world use case where we need to store a random range outside of a function. -- Ilya You want to instantiate and seed Mt every time you call a function that may need random numbers? A function can use a global RNG defined by a user or accepts RNG by reference. Range adaptor stores pointer, not value.
Re: Mir Random [WIP]
On 24.11.2016 09:55, Kagamin wrote: On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei Alexandrescu wrote: [Details needed] I just took a look https://godbolt.org/g/EMy6X4, it's happening. That's three instructions instead of one shr eax,1 That would be wrong code. Cast to int after dividing.
Re: Mir Random [WIP]
On Wednesday, 23 November 2016 at 21:33:53 UTC, Jonathan M Davis
wrote:
though I think that using the comma operator like that is
deprecated now. Adding a helper function such as
auto getNext(R)(ref R range)
if(isInputRange!R)
{
range.popFront();
return range.front;
}
would solve that problem.
It's the same behavior and suffers from the same problem of reuse
of RNG output.
Re: Mir Random [WIP]
On Wednesday, 23 November 2016 at 19:40:47 UTC, Ilya Yaroshenko wrote: Current adaptor should be used in a function scope. (Would be great to have a DIP for that kind of semantic check). An RC adaptor can be added too. First we need to find a real world use case where we need to store a random range outside of a function. -- Ilya You want to instantiate and seed Mt every time you call a function that may need random numbers?
Re: Mir Random [WIP]
On Wednesday, 23 November 2016 at 21:18:27 UTC, Andrei Alexandrescu wrote: [Details needed] I just took a look https://godbolt.org/g/EMy6X4, it's happening. That's three instructions instead of one shr eax,1
Re: How do we accelerate the development of precise GC, RC and so on?
So, who wants to do a good deed and make some money? We can create an issue and start fundraising on Bountysource. We can also donate to the D Language Foundation, but I personally would like to see the funds were used to develop precise GC and DIP74 (https://wiki.dlang.org/DIP74).
Re: Mir Random [WIP]
On Wednesday, 23 November 2016 at 17:31:58 UTC, Kagamin wrote: On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei Alexandrescu wrote: Interesting. Could you please add a couple of links about that? -- Andrei http://xoroshiro.di.unimi.it/ Very short public domain implementation: http://xoroshiro.di.unimi.it/xoroshiro128plus.c
