[Issue 3738] MinstdRand0 and MinstdRand very poor performance
http://d.puremagic.com/issues/show_bug.cgi?id=3738
Witold Baryluk bary...@smp.if.uj.edu.pl changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #3 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-24
08:35:08 PST ---
One can observe that ?: line (branch2)
_x = (y v || y = 2147483647) ? ((y+1) 0x7fff_u) : y;
can be changed , first to not contain not needed yv, to (branch1)
_x = (y = 2147483647) ? ((y+1) 0x7fff_u) : y;
or even remove branch completly (branchlessA)
_x = (y 0x7fff_) + (y 31);
and possibly rearange terms (branchlessB)
_x = (y + (y 31)) 0x7fff_;
MinstdRnd0
standard: 44.65 s
inline: 41.11 s
standard with tricks (2 branches): 17.08 s
inline with tricks (2 branches): 17.04 s
standard with tricks (1 branch): 15.24 s
inline with tricks (1 branch): 13.59 s
standard with tricks (branchlesA): 16.50 s
inline with tricks (branchelesA): 15.82 s
standard with tricks (branchlesB): 17.74 s
inline with tricks (branchelesB): 15.30 s
MinstdRnd
standard: 44.95 s
inline: 41.17 s
standard with tricks (2 branch): 17.04 s
inline with tricks (2 branche): 17.03 s
standard with tricks (1 branch): 15.29 s
inline with tricks (1 branche): 13.54 s
standard with tricks (branchlesA): 16.46 s
inline with tricks (branchelessA): 15.88 s
standard with tricks (branchlesB): 18.10 s
inline with tricks (branchelessB): 15.31 s
So fastest is currently branch1 version.
Updated patch:
void popFront()
{
static if (m)
-_x = cast(UIntType) ((cast(ulong) a * _x + c) % m);
+static if (is(UIntType == uint) m == 4294967295uL) {
+ const ulong x = (cast(ulong) a * _x + c);
+ const ulong v = x 32;
+ const ulong w = (x 0x_uL);
+ const uint y = cast(uint)(v+w);
+ _x = (y v || y = 4294967295u) ? (y+1) : y;
+} else static if (is(UIntType == uint) m == 2147483647u) {
+ const ulong x = (cast(ulong) a * _x + c);
+ const ulong v = x 31;
+ const ulong w = (x 0x7fff_uL);
+ const uint y = cast(uint)(v+w);
+ _x = (y = 2147483647u) ? ((y+1) 0x7fff_u) : y;
+} else {
+_x = cast(UIntType) ((cast(ulong) a * _x + c) % m);
+}
else
_x = a * _x + c;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3739] Coding errors in LinearCongruentialEngine
http://d.puremagic.com/issues/show_bug.cgi?id=3739 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-01-24 09:25:41 PST --- Makes sense. I operated the changes and will commit soon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2008] Poor optimization of functions with ref parameters
http://d.puremagic.com/issues/show_bug.cgi?id=2008 Eldar Insafutdinov e.insafutdi...@gmail.com changed: What|Removed |Added CC||e.insafutdi...@gmail.com --- Comment #3 from Eldar Insafutdinov e.insafutdi...@gmail.com 2010-01-24 09:39:04 PST --- Recent change to dmd forced everybody to use opEquals with ref arguments. That leaves no other option than the poorly optimised one. Isn't it time to fix this bug? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3252] undefined reference to package function called from an interface
http://d.puremagic.com/issues/show_bug.cgi?id=3252 Alexey Ivanov aifg...@gmail.com changed: What|Removed |Added CC||aifg...@gmail.com OS/Version|Linux |All --- Comment #2 from Alexey Ivanov aifg...@gmail.com 2010-01-24 09:46:54 PST --- Same problem on windows -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3738] MinstdRand0 and MinstdRand very poor performance
http://d.puremagic.com/issues/show_bug.cgi?id=3738 --- Comment #5 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-24 12:03:20 PST --- All my tests pases on your version. 10_000_000_000 (more than all possibilities) passes (for MinstdRand0 and MinstdRand, it is possible that for other a it will fail, but i tested and done some calculation. and it should work for all a,cm. I also tested versions with slightly changed constants (like 30 instad of 31, or int.max-1, int.max-2, int.max-3, int.max+1 in multiple comibinations an allone), and all them fail. Shouldn't const uint y by immucatable y, just like in first static if? I think that our pretty optimised line, can be further optimalised: (1 branch sub) - _x = (y = int.max) ? ((y + 1) int.max) : y; + _x = (y = int.max) ? (y - int.max) : y; :) This gives: MinstdRand0: standard with tricks (1 branch sub): 15.25 inline with tricks (1 branch sub): 13.53 s MinstdRand: standard with tricks (1 branch sub): 15.26 inline with tricks (1 branch sub): 13.52 s It doesn't give much difference (maybe 2%). But i thinkg it is better to have one substraction, than one add and one binary and. I found few interesting materials about this m=2^^31-1 operation. One is http://www.firstpr.com.au/dsp/rand31/ I tested this Carta's versions: But they are only relevant for a=16807 (out Park-Miller's StdminRand0 generator), so pretty limited: Carta1 (original): uint lo = 16807*(_x 0xu); immutable uint hi = 16807*(_x 16); lo += (hi 0x7FFF) 16; lo += (hi 15); _x = (lo int.max) ? (lo - int.max) : lo; Carta3: uint lo = 16807*(_x 0xu); immutable uint hi = 16807*(_x 16); lo += ((hi 0x7FFF) 16) + (hi 15); _x = (lo int.max) ? (lo - int.max) : lo; Carta2: immutable uint hi = 16807*(_x 16), lo 16807*(_x 0xu) + ((hi 0x7FFF) 16) + (hi 15); _x = (lo int.max) ? (lo - int.max) : lo; Last lines can also be changed to branchles: _x = (lo int.max) ? (lo - int.max) : lo; Timings: Carta code1: 22.30 s Carta code1 branchless: 18.42 Carta code3: 21.84 s Carta code3 branchless: 18.19 s Carta code2: 23.84 s Carta code2 branchless: 19.84 s So it is slower in all cases, and it is only for speciall cases (c=0, a 2^^15). Of course answers are still correct. Performing uint*uint+uint - ulong is just faster than their tricks, and more general, and can be reused in many other places. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3723] Regression: forward referenced enum
http://d.puremagic.com/issues/show_bug.cgi?id=3723 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-01-24 15:02:43 PST --- Changeset 353 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2008] Poor optimization of functions with ref parameters
http://d.puremagic.com/issues/show_bug.cgi?id=2008 --- Comment #4 from David Simcha dsim...@yahoo.com 2010-01-24 16:00:12 PST --- (In reply to comment #3) Recent change to dmd forced everybody to use opEquals with ref arguments. That leaves no other option than the poorly optimised one. Isn't it time to fix this bug? I think the more important fix is to start allowing opEquals with non-ref arguments again. Only allowing ref arguments is ridiculous because it forces the argument to be an lvalue, thus creating a horribly ugly inconsistency with builtin types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2008] Poor optimization of functions with ref parameters
http://d.puremagic.com/issues/show_bug.cgi?id=2008 --- Comment #5 from Eldar Insafutdinov e.insafutdi...@gmail.com 2010-01-24 16:06:02 PST --- (In reply to comment #4) (In reply to comment #3) Recent change to dmd forced everybody to use opEquals with ref arguments. That leaves no other option than the poorly optimised one. Isn't it time to fix this bug? I think the more important fix is to start allowing opEquals with non-ref arguments again. Only allowing ref arguments is ridiculous because it forces the argument to be an lvalue, thus creating a horribly ugly inconsistency with builtin types. That's true. Perhaps functions with signature (const ref T) could accept rvalues as well, as the semantics is equivalent to (T)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 918] Template order matter, version block change something with typedef, and another template bug.
http://d.puremagic.com/issues/show_bug.cgi?id=918 --- Comment #5 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-24 20:44:41 PST --- I tested it today on 2.039 and regression dissapered, now all 3 versions give exactl the same correct answers: $ dmd2 -version=B -w a918.d ; ./a918 calling num wyk=22? num 22 calling int=4? int 4 calling alias=x=333? alias 333 $ It can be closed now I think, but still I will want to test it in DMD 1.x. Anyone knows what changes in compiler possibly made all this fixes, regression and fixes? I can try historical version and check which have what behaviour. I would not want to close error because it dissapered by random chance :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1650] Incorrect overload selected with IFTI
http://d.puremagic.com/issues/show_bug.cgi?id=1650
Witold Baryluk bary...@smp.if.uj.edu.pl changed:
What|Removed |Added
CC||bary...@smp.if.uj.edu.pl
--- Comment #12 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-24
21:09:31 PST ---
You should use probably something like this:
void proc(T : T[])(T[] val) {
}
Is there any reason this is still open?
I cheked documentation and there is such snippet:
void Foo(T, U=T*)(T t) { U p; ... }
int x;
Foo(x);// T is int, U is int*
Well, for me it is strange that comment says T is int, Foo is specialized and
recived T (int), but we give it a pointer. Something really wrong somewhere.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1659] template alias parameters are chosen over all but exact matches.
http://d.puremagic.com/issues/show_bug.cgi?id=1659 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #3 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-24 21:09:54 PST --- This problem is still present in DMD 2.039. It looks that from unknown reasons bug918 is solved (nobody comented what was source of regression and dissapiring of it). Probably it is different aspect here of template matching. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3736] corrupted struct returned by function with optimizations (-O)
http://d.puremagic.com/issues/show_bug.cgi?id=3736
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Version|2.030 |1.020
Severity|regression |critical
--- Comment #1 from Don clugd...@yahoo.com.au 2010-01-24 23:53:23 PST ---
This isn't actually a regression. It fails on D2.00, and D1.020, 1.041, 1.055
as well.
Reduced test case:
---
struct Foo
{
int x;
}
Foo getFoo(Foo irrelevant)
{
Foo p = Foo(400);
if ( p.x p.x )
return irrelevant;
else
return p;
}
void main()
{
assert(getFoo( Foo(0) ).x == 400);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
