[Issue 5900] std.math.radians(), std.math.degrees()
http://d.puremagic.com/issues/show_bug.cgi?id=5900 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2011-04-28 00:31:53 PDT --- It's worse than that. A bigger issue is that it encourages the wrong approach. These functions would encourage people to write wrong code like this: sin(degreesToRadians(360)); Which gives the wrong answer -- sin(360degrees) should be EXACTLY zero, not a small nonsense value like 1.4534e-17. I don't think it's fair to trick people like that. The correct way to do trig with degrees is: sin( ((x%360.0)/180)*PI ); I'll put this in the docs for std.math, since it's not obvious. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4372] type of enumerator values reduced to base type in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=4372 --- Comment #2 from Aldo Nunez aldonun...@gmail.com 2011-04-28 01:03:55 PDT --- I think I have a simpler fix. If we write a mostly blank LF_ENUM record with only the right name and the forward reference flag (128) in the property field, the linker merges it with the full LF_ENUM record written by EnumDeclaration::toDebug/cv4_Denum. Only one LF_ENUM record for each enum will appear in the debug info, and all references will be right. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4372] type of enumerator values reduced to base type in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=4372 Aldo Nunez aldonun...@gmail.com changed: What|Removed |Added Attachment #674 is|0 |1 obsolete|| --- Comment #3 from Aldo Nunez aldonun...@gmail.com 2011-04-28 01:05:28 PDT --- Created an attachment (id=951) Write a forward reference LF_ENUM record. I believe this patch also fixes the bug and is simpler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4372] type of enumerator values reduced to base type in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=4372 Aldo Nunez aldonun...@gmail.com changed: What|Removed |Added Attachment #951 is|0 |1 obsolete|| --- Comment #4 from Aldo Nunez aldonun...@gmail.com 2011-04-28 01:10:24 PDT --- Created an attachment (id=952) Write a forward reference LF_ENUM record. Let's try this again. I didn't mean for the patch to be in UTF-16. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4815] CodeView: Global and Static symbols should have unmangled names
http://d.puremagic.com/issues/show_bug.cgi?id=4815 --- Comment #1 from Aldo Nunez aldonun...@gmail.com 2011-04-28 01:14:05 PDT --- Created an attachment (id=953) Set and check prettyIdent. We can fix this by setting and checking symbol::prettyIdent in the right places. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4817] CodeView: Enum members should have simple names
http://d.puremagic.com/issues/show_bug.cgi?id=4817 --- Comment #1 from Aldo Nunez aldonun...@gmail.com 2011-04-28 01:18:42 PDT --- Created an attachment (id=954) Use toChars instead of toPrettyChars. We can fix this by using toChars instead of toPrettyChars when writing LF_ENUMERATE records in cv4_Denum. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5900] std.math.radians(), std.math.degrees()
http://d.puremagic.com/issues/show_bug.cgi?id=5900
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #3 from kenn...@gmail.com 2011-04-28 01:47:32 PDT ---
(In reply to comment #2)
It's worse than that. A bigger issue is that it encourages the wrong approach.
These functions would encourage people to write wrong code like this:
sin(degreesToRadians(360));
Which gives the wrong answer -- sin(360degrees) should be EXACTLY zero, not a
small nonsense value like 1.4534e-17.
I don't think it's fair to trick people like that.
The correct way to do trig with degrees is: sin( ((x%360.0)/180)*PI );
I'll put this in the docs for std.math, since it's not obvious.
Well maybe *this* is the function that should be added instead of degrees().
T degrees(alias f)(T theta) if (isFloatingPoint!T f is sin ...) {
return f( (theta % 360.0) / 180 * PI );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5590] ICE when using .values on enum which is associative array
http://d.puremagic.com/issues/show_bug.cgi?id=5590 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #3 from Don clugd...@yahoo.com.au 2011-04-28 08:41:30 PDT --- *** This issue has been marked as a duplicate of issue 4460 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4460] Regression(2.036) ICE(e2ir.c) when compiling foreach over associative array literal
http://d.puremagic.com/issues/show_bug.cgi?id=4460 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #7 from Don clugd...@yahoo.com.au 2011-04-28 08:41:30 PDT --- *** Issue 5590 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5059] String assignment in foreach loop breaks immutability
http://d.puremagic.com/issues/show_bug.cgi?id=5059 Jesse Phillips jesse.k.phillip...@gmail.com changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m --- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com 2011-04-28 10:13:09 PDT --- This is a bug in KeySequence's opApply. The function is reusing a char[] for every iteration, it then casts this to a string, but ends up being modified for each call to Reg_EnumKeyName_. https://github.com/D-Programming-Language/phobos/blob/master/std/windows/registry.d#L1870 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4817] CodeView: Enum members should have simple names
http://d.puremagic.com/issues/show_bug.cgi?id=4817 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-04-28 11:28:20 PDT --- https://github.com/D-Programming-Language/dmd/commit/a98c332a2ea6ad9b4b29926d8af4258e9e8b60c5 https://github.com/D-Programming-Language/dmd/commit/08c5424d5911f7161477786cfc41bb3e93097a16 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4053] To avoid struct ctor/opCall conflicts
http://d.puremagic.com/issues/show_bug.cgi?id=4053 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #4 from kenn...@gmail.com 2011-04-28 11:41:16 PDT --- Probably the same as issue 1840. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5903] New: Overloading template functions with typeof() parameter type fails.
http://d.puremagic.com/issues/show_bug.cgi?id=5903
Summary: Overloading template functions with typeof() parameter
type fails.
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-04-28 12:18:38 PDT ---
Test case:
---
static assert(is(int == typeof(0)));
void p()(int a) { pragma(msg, OK(p)); }
void p()() { pragma(msg, Err(p)); }
void r(R=typeof(0))(R a) { pragma(msg, OK(r)); }
void r()() { pragma(msg, Err(r)); }
void s()(typeof(0) a) { pragma(msg, OK(s)); }
void t(typeof(0) a) { }
void t() { }
void q()(typeof(0) a) { pragma(msg, OK(q)); }
void q()() { pragma(msg, Err(q)); }
void main() {
p!()(5);// without typeof() is ok
r!()(5);// put that typeof() elsewhere is ok
s!()(5);// no overloading is ok
t(5); // no template is ok
q!()(5);// Error
}
---
OK(p)
OK(r)
OK(s)
x.d(22): Error: template x.q() does not match any function template declaration
x.d(22): Error: template x.q() cannot deduce template function from argument
types !()(int)
x.d(22): Error: template instance errors instantiating template
---
Probably the same as issue 4413, except it affects more than typeof(this).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5904] New: std.json parseString doesn't handle chars outside the BMP
http://d.puremagic.com/issues/show_bug.cgi?id=5904 Summary: std.json parseString doesn't handle chars outside the BMP Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: s...@invisibleduck.org --- Comment #0 from Sean Kelly s...@invisibleduck.org 2011-04-28 12:24:48 PDT --- According to RFC 4627, characters outside the Basic Multilingual Plane (ie. those that require more than two bytes to represent) are encoded as a surrogate pair in JSON strings. In effect, what you have to do is test whether a \u value is = 0xD800 and = 0xDBFF. If so, then the next value should be another \u character representing the low surrogate. To verify this, the value should be = 0xDC00 and = 0xDFFF. If it isn't, then skip the preceding \u value (the high surrogate) as invalid and decode the following \u value as a standalone Unicode code-point (the RFC is actually unclear on this point, but this seems the most reasonable failure mode). Assuming that you have a valid high and low surrogate, stick them into a wchar[2] and convert to UTF8. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4424] Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424
--- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-04-28 12:53:39 PDT ---
Created an attachment (id=955)
test cases
Patch created:
https://github.com/9rnsr/dmd/compare/master...fix4424
Behaviors:
- if template opAssign exists, check it is identity opAssign.
- if template identity opAssign need, following opAsign build:
ref S opAsign(T:S)(T s) if (is(T == S))
{
T tmp = this; // bit copy
this = s; // bit copy
tmp.dtor();
return this;
}
- no changes with non tempate opAssign.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4197] __error iso assert failure in struct function in/out statement
http://d.puremagic.com/issues/show_bug.cgi?id=4197
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||clugd...@yahoo.com.au
Version|unspecified |D1 D2
OS/Version|Windows |All
Severity|normal |major
--- Comment #4 from Don clugd...@yahoo.com.au 2011-04-28 13:12:33 PDT ---
Original title was:
__error iso assert failure in struct function in/out statement
A reduced test case shows it is a very general ICE.
*Any* error inside an in() or out() contract in a function that is has its
semantic run through CTFE, has all errors gagged. This can result in a cryptic
error message (as in the original test case), or an ICE. This one is
ICE(glue.c), but I've also seen ICE(toir.c). It fails on both D1 and D2.
const Bug4197 s4197 = Bug4197();
int func4197()
in { undefined; }
body { return 0; }
struct Bug4197 {
static const int S2 = func4197();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3473] Mac 10.5: doc.c compiling is broken
http://d.puremagic.com/issues/show_bug.cgi?id=3473 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2011-04-28 13:25:39 PDT --- Fixed long ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|unspecified |D1 D2 Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235 --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2011-04-28 13:39:40 PDT --- BTW this is in TDPL now, with Walter's approval. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-04-28 13:44:27 PDT --- It's a good idea. Actually, file and line. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4460] Regression(2.036) ICE(e2ir.c) when compiling foreach over associative array literal
http://d.puremagic.com/issues/show_bug.cgi?id=4460 --- Comment #8 from Iain Buclaw ibuc...@ubuntu.com 2011-04-28 13:49:27 PDT --- You know I never actually checked to see if this patch worked in DMD... ... it doesn't work DMD. Now why would that be? Seems to because of a similar reason to issue5683 - backend is simply not getting the passing of the value right. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1840] Fix ambiguity errors over struct static opCall and regular opCall
http://d.puremagic.com/issues/show_bug.cgi?id=1840 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2011-04-28 14:50:10 PDT --- Bug 4053 seems similar or the same. Both have 1 (different) vote. This is an important issue I hit all the time in my code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5905] New: Error message with const fixed-size array
http://d.puremagic.com/issues/show_bug.cgi?id=5905
Summary: Error message with const fixed-size array
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-04-28 15:14:07 PDT ---
D2 code:
void main() {
const float[1] a;
const(float[1]) b;
const(float)[1] c;
}
DMD 2.052 shows the compile error messages:
test.d(2): Error: slice a[] is not mutable
test.d(3): Error: slice b[] is not mutable
test.d(4): Error: slice c[] is not mutable
I think such error messages are not clear enough.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5906] New: Just pre-conditions at compile-time when arguments are static
http://d.puremagic.com/issues/show_bug.cgi?id=5906
Summary: Just pre-conditions at compile-time when arguments are
static
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-04-28 16:19:57 PDT ---
This enhancement proposal was getting lost in a thread, so I have added it here
too.
DMD currently runs functions at compile time only if their call is in a context
where a compile-time value is expected, to avoid troubles (C++0X uses a keyword
to avoid those problems). This is OK.
Note: DMD is able to run contracts too at compile-time, as you see in this
program (at the r1 enum):
import std.ctype: isdigit;
int foo(string text, int x)
in {
assert(x = 0 x text.length);
foreach (c; text[0 .. x])
assert(isdigit(c));
} body {
return 0;
}
enum r1 = foo(123xxx, 4); // Error: assert(isdigit(cast(dchar)c)) failed
void main(string[] args) {
auto r2 = foo(args[2], (cast(int)args.length) - 5);
auto r3 = foo(123xxx, 4);
}
DMD 2.052 shows:
test.d(3): Error: assert(x 0) failed
test.d(7): Error: cannot evaluate foo(-1) at compile time
test.d(7): Error: cannot evaluate foo(-1) at compile time
This is my idea: when you call a function where all its arguments are known at
compile-time (as at the r3 variable) the compiler runs just the pre-condition
of that function at compile-time. Uf a pre-condition can't run at compile-time,
the compiler just ignores it silently, and later this pre-condition will run
normally at run-time.
Note that I am not suggesting to run the whole function, and not its
post-condition, just its pre-condition.
Running just the pre-condition is different from running the whole function
because:
- Pre-conditions are usually small or smaller than function bodies;
- Pre-conditions are usually meant to be fast (and not slower than the function
body), so they are probably not too much heavy to run. pre-conditions, unlike
debug{} code are meant to run often, sometimes even in normal usage of
programs;
- My pre-conditions are often pure. If this enhancement request gets accepted,
D programmers will be encouraged to write more pure preconditions. Even if a
function is not marked as pure, what matters in this discussion is to its
pre-condition to be CTFE-pure. (Functions can run at compile-time even if they
aren't pure. They need to be pure just in the code path run at compile time).
Walter:
Instead, we opted for a design that either must run at compile time, or
must run at run time. Not one that decides one way or the other in an
arbitrary, silent, and ever-changing manner.
The user must make an explicit choice if code is to be run at compile
time or run time.
This problem is important for the normally run CT functions, and I agree with
this decision. But it's much less important the idea presented here, because
finding bug is almost never a deterministic process, it's usually
probabilistic. People find only some bugs (people today find new bugs even in
old very-high-quality C code used by everyone), lint tools (including the
static analysis flag done by Clang) find only some other bugs, and usually
different lints find different bugs. One important thing for those tools is to
reduce false positives as much as possible (even if this increases false
negatives a little), and the idea presented here doesn't produce false alarms
(if the pre-conditions are correct).
This feature is useful because in your code I often have struct literals like
(I assume their constructor has a pre-condition):
Foo f1 = Foo(10, -20);
The compiler is able at compile-time to tell this line of code is wrong because
for example -20 is not acceptable. This is useful in many situations. This
feature works only if the arguments are known at compile-time, this is a strong
limitation of the idea presented here, but I think it's better to have it
anyway.
Even if this feature sometimes gets disabled by turning a CTFE-pure function
pre-condition into not CTFE-pure code, the programmer doesn't need to worry a
lot about this, because even if this change doesn't allow to catch this bug in
the code, other bugs too are not found by the compiler. All static analysis
tools do the same, they sometimes find a bug, but if you change the code in a
way they don't fully understand, they don't find the bug any more.
The feature I have proposed here is not a language feature, it's a compiler
feature (the only change is in user code, that's encouraged to create CTFE-pure
pre-conditions). This means that even if DMD doesn't want this idea, future D
compilers will be free to adopt it. I think this is a cheap but useful compiler
feature to add. It's a cheap feature because the compiler is kept simple (to
catch
[Issue 5907] New: CTFE: Ref assignments are noop at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=5907
Summary: CTFE: Ref assignments are noop at compile time
Product: D
Version: unspecified
Platform: Other
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-04-28
17:05:20 PDT ---
auto ok()
{
int[2] result;
foreach (index, ref sample; result)
{
result[index] = 1;
}
return result;
}
auto fail()
{
int[2] result;
foreach (index, ref sample; result)
{
sample = 1;
}
return result;
}
float[2] ctfe_ok = ok();
float[2] ctfe_fail = fail();
void main()
{
assert(ok == [1, 1]); // ok
assert(fail == [1, 1]); // ok
assert(ctfe_ok == [1, 1]);
assert(ctfe_fail == [1, 1]);// throws
}
Unfortunately they fail silently and then you have bugs in your code. I'm not
sure but maybe this bug was reported already? (or a fix is scheduled for the
next release?)
I couldn't be sure so I'm reporting it just in case.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-04-28 17:07:25 PDT --- Um, have to be careful about two unittests on the same line! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5907] CTFE: Ref assignments are noop at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=5907 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-04-28 17:07:42 PDT --- Oh btw sorry about using float[2] instead of int[2] there. I was quickly converting some existing code. The bug is still there if ctfe_ok and ctfe_fail are typed as ints. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2011-04-28 17:29:21 PDT --- (In reply to comment #2) Um, have to be careful about two unittests on the same line! __COLUMN__ ftw! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4393] Very good dotProduct
http://d.puremagic.com/issues/show_bug.cgi?id=4393
--- Comment #1 from bearophile_h...@eml.cc 2011-04-28 18:55:10 PDT ---
Some code I have written for arrays of floats:
float dot(float[] a, float[] b) {
enum size_t UNROLL_MASK = 0b111;
assert(a.length == b.length, dot(): the two array lengths differ.);
typeof(a[0]) tot = void;
auto a_ptr = a.ptr;
auto b_ptr = b.ptr;
assert((cast(size_t)a_ptr cast(size_t)0b) == 0,
dot(): the first array is not aligned to 16 bytes.);
assert((cast(size_t)b_ptr cast(size_t)0b) == 0,
dot(): the second array is not aligned to 16 bytes.);
size_t len = (a.length (~UNROLL_MASK)) * a[0].sizeof;
if (len) {
asm {
mov EAX, a_ptr;
mov ECX, b_ptr;
mov EDI, len;
xorps XMM0, XMM0;
xorps XMM3, XMM3;
xor EDX, EDX;
align 8;
LOOP_START:
movaps XMM1, [EAX + EDX];
mulps XMM1, [ECX + EDX];
movaps XMM2, [EAX + EDX + 16];
mulps XMM2, [ECX + EDX + 16];
add EDX, 32;
addps XMM0, XMM1;
cmp EDI, EDX;
addps XMM3, XMM2;
jne LOOP_START;
addps XMM0, XMM3;
// XMM0[0] = XMM0[0] + XMM0[1] + XMM0[2] + XMM0[3]
movhlps XMM1, XMM0;
addps XMM0, XMM1;
pshufd XMM1, XMM0, 0b01_01_01_01;
addss XMM0, XMM1;
movss tot, XMM0;
}
} else
tot = 0.0;
size_t left = a.length UNROLL_MASK;
for (size_t i = left; i 0; i--)
tot += a[$ - i] * b[$ - i];
return tot;
}
And for arrays of doubles:
import std.c.stdio;
void main() {
double[] A = [0.7644108908809033, 0.96458177717869509,
0.51166055832523683, 0.098840360055908461,
0.40813780586233483, 0.32285857447088551,
0.59137950751990331, 0.59518178287473289];
double[] B = [0.28061374331187983, 0.85036446787626108,
0.52498124274748326, 0.84170745998075014,
0.55819169392258683, 0.6258635477134,
0.43021720539707864, 0.652708603473523];
// sum(a*b for a,b in zip(A, B))
// 2.4593435789602185
if (A.length % 4 != 0) throw new Error();
double tot1 = void,
tot2 = void;
auto a_ptr = cast(double*)A.ptr;
auto b_ptr = cast(double*)B.ptr;
size_t len = A.length * double.sizeof;
asm {
mov EAX, a_ptr;
mov ECX, b_ptr;
mov EDI, len;
xorps XMM0, XMM0;
xorps XMM3, XMM3;
xor EDX, EDX;
align 8;
LOOP_START:
movapd XMM1, [EAX + EDX];
mulpd XMM1, [ECX + EDX];
movapd XMM2, [EAX + EDX + 16];
mulpd XMM2, [ECX + EDX + 16];
add EDX, 32;
addpd XMM0, XMM1;
cmp EDI, EDX;
addpd XMM3, XMM2;
jne LOOP_START;
addpd XMM0, XMM3; // XMM0 += XMM3
movhpd tot1, XMM0;
movlpd tot2, XMM0;
}
printf(%.15lf\n, tot1 + tot2);
}
See bug 5880 too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4393] Very good dotProduct
http://d.puremagic.com/issues/show_bug.cgi?id=4393 --- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2011-04-28 20:10:55 PDT --- Nice work. Got some benchmarks? Also, I wonder what version flag I should use to guard the assembler implementation. Don? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4393] Very good dotProduct
http://d.puremagic.com/issues/show_bug.cgi?id=4393 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #3 from David Simcha dsim...@yahoo.com 2011-04-28 20:12:06 PDT --- Looks rather interesting. Dot products are sufficiently universally useful that, if this is significantly faster than the current std.numeric implementation, inclusion is definitely justified. However, you'd greatly increase the chances of inclusion if you created some simple benchmarks (nothing fancy, just the obvious ones) and unit tests and submitted this as a pull request on Github. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4393] Very good dotProduct
http://d.puremagic.com/issues/show_bug.cgi?id=4393 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #4 from Don clugd...@yahoo.com.au 2011-04-28 21:36:38 PDT --- Did you test this on Intel, or AMD? Blas1 code is generally limited by memory access, and AMD has two load ports, so it has different bottlenecks and in these operations always does better than Intel. See also a discussion at: http://www.bealto.com/mp-dot_sse.html (I've talked to Eric Bealto before, he's happy for Phobos to use any of his stuff if we see anything we want). It's a bit misleading, though, because above a certain length, you become dominated by cache effects, so I don't know if unrolling by 4 is actually worthwhile in practice. I also have some optimized x87 dot product code (AMD 32 bit CPUs don't have SSE2, so they still need x87 for doubles). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
