[Issue 5282] Use memcmp or other appropriate optimizations for array comparison where possible
http://d.puremagic.com/issues/show_bug.cgi?id=5282 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2010-11-28 03:20:18 PST --- (In reply to comment #0) What likely should be done is to use memcmp in cases where you don't actually need to call opEquals() on the individual elements of the arrays A simple solution for the string case: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=123044 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5281] Equality among arrays of Bigints
http://d.puremagic.com/issues/show_bug.cgi?id=5281
Matthias Walter xa...@xammy.homelinux.net changed:
What|Removed |Added
CC||xa...@xammy.homelinux.net
OS/Version|Windows |All
--- Comment #1 from Matthias Walter xa...@xammy.homelinux.net 2010-11-28
08:27:14 PST ---
More precisely, the issue is that in the following code, the opEquals method is
not called for the array comparison. As it seems, the only opEquals signature
working for array comparison is bool opEquals (ref const BigInt y) const,
making it impossible to have more versions to compare to different types.
struct BigInt
{
bool opEquals (Tdummy = void)(ref const BigInt y) const
{
writefln(BigInt.opEquals!void(BigInt) called);
return true;
}
bool opEquals (T: long) (long y) const
{
writefln(BigInt.opEquals!long called);
return true;
}
}
void main()
{
BigInt i,j;
writefln(i == j: %s, i == j);
writefln([i] == [j]: %s, [i] == [j]);
}
The output is:
BigInt.opEquals!void(BigInt) called
i == j: true
[i] == [j]: true
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2656] Remove octal literals
http://d.puremagic.com/issues/show_bug.cgi?id=2656 --- Comment #17 from Andrei Alexandrescu and...@metalanguage.com 2010-11-28 08:40:41 PST --- I wonder what people's experience with octal has been. http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2656] Remove octal literals
http://d.puremagic.com/issues/show_bug.cgi?id=2656 --- Comment #18 from bearophile_h...@eml.cc 2010-11-28 08:50:33 PST --- (In reply to comment #17) I wonder what people's experience with octal has been. http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal I have never had to use octals in D code so far, so I have no experience on that octal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5284] New: Array ops punch through const system
http://d.puremagic.com/issues/show_bug.cgi?id=5284
Summary: Array ops punch through const system
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dfj1es...@sneakemail.com
Blocks: 2573
--- Comment #0 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-28
09:00:08 PST ---
---
class A { int m=5; }
int main()
{
A[] a=new A[1];
immutable(A)[] b=[new immutable(A)];
assert(b[0].m==5);
a[]=b[]; //should not pass typecheck
a[0].m=10;
assert(b[0].m==5,fail); //line 18
return 0;
}
---
dmd -w -debug -run test.d
---
core.exception.asserter...@test.d(18): fail
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5282] Use memcmp or other appropriate optimizations for array comparison where possible
http://d.puremagic.com/issues/show_bug.cgi?id=5282 --- Comment #2 from bearophile_h...@eml.cc 2010-11-28 09:05:27 PST --- The solution I suggest for this problem is: when DMD knows at compile-time the length of one of the two strings to equate, and such length is small (like 6), then it may replace the string eq code like this: (c == TAC) With code like: (c.length == 3 c[0] == 'T' c[1] == 'A' c[2] == 'C') -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5284] Array ops punch through const system
http://d.puremagic.com/issues/show_bug.cgi?id=5284
--- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-28
09:13:10 PST ---
Interesting...
---
class A { int m=5; }
int main()
{
A[] a=new A[1];
int[] b=[0];
a[]=b[];
return 0;
}
---
this code gives error: cannot implicitly convert expression (b[]) of type int[]
to const(A[]). Seems like the compiler tries to cast right-hand expression to
const(typeof(left-hand expression)), then proceeds with copying.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4172] Improve varargs
http://d.puremagic.com/issues/show_bug.cgi?id=4172 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com Version|future |D1 AssignedTo|nob...@puremagic.com|bugzi...@digitalmars.com --- Comment #7 from Andrei Alexandrescu and...@metalanguage.com 2010-11-28 09:32:53 PST --- Marking this as a D1 only thing and leaving decision to Walter. My suggestion is to close this as a wontfix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2656] Remove octal literals
http://d.puremagic.com/issues/show_bug.cgi?id=2656 --- Comment #19 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-28 09:53:36 PST --- (In reply to comment #0) D should follow Python's lead in removing the archaic, subtle, and unintuitive format for octal literals. The obvious choices are of the form 0c45 and 0o45. The key argument used for the 0o format is here: http://mail.python.org/pipermail/python-dev/2006-February/060351.html and basically argues that since in printf(), %o is used for octal, whereas c is used for char, o is the natural choice. Haha, this printf argument is laughable. With printf %#x will prepend 0x prefix to hex number, you can't do this for octal and binary numbers. I think, 0o775 is ok (you can see it just here). He has a good point that it's leading zero that signals something nice is here and size of o is enough to figure out, what is this. 0c is just a syntactical hack in attempt to not use 0o. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4066] ICE(e2ir.c): enum AA get
http://d.puremagic.com/issues/show_bug.cgi?id=4066
Denis Derman denis.s...@gmail.com changed:
What|Removed |Added
CC||denis.s...@gmail.com
--- Comment #2 from Denis Derman denis.s...@gmail.com 2010-11-28 10:04:51 PST
---
A use case, where issue happens with 'static' instead of 'enum:
enum string[string] escapeCodes = [\n:\\n, \t:\\t]; // and many more
string escape(string s0) {
auto s1 = s0;
foreach (c,s ; escapeCodes)
s1 = s1.replace(c,s);
return s1;
}
==
Internal error: e2ir.c 4629
Only tried to use this because it seems impossible to have a func-static AA:
__trials__.d(16): Error: non-constant expression [\x0a:\\n,\x09:\\t]
Denis
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1077] writef and friends won't read/write from/to redirected std handles
http://d.puremagic.com/issues/show_bug.cgi?id=1077 --- Comment #2 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-11-28 11:00:30 PST --- In fact, I have a working plugin that retabifies source, passed to stdin, though, as I see it uses my io streams that I wrote in order to fix bug 2742 :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4172] Improve varargs
http://d.puremagic.com/issues/show_bug.cgi?id=4172 --- Comment #8 from Fawzi Mohamed fa...@gmx.ch 2010-11-28 12:53:12 PST --- I agree, I came to this from a discussion on the IRC, and I was thinking it was a GDC bug (which has a badly broken implementation. If implemented correctly, and with alignment info and size in the typeinfo it is perfectly workable. Not the most nice possible, but reasonably efficient and usable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5264] x86_64 changes for druntime 2
http://d.puremagic.com/issues/show_bug.cgi?id=5264 --- Comment #5 from Brad Roberts bra...@puremagic.com 2010-11-28 14:49:52 PST --- Looks like the cause of #1 is that only dmd 1 got one of the big vararg related change sets: http://www.dsource.org/projects/dmd/changeset/717 Walter's merging those into dmd2 soon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5286] New: To avoid a problem with Template syntax
http://d.puremagic.com/issues/show_bug.cgi?id=5286
Summary: To avoid a problem with Template syntax
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-11-28 15:14:06 PST ---
D has removed some cases of bug-prone C syntax, like:
int main() {
int* ptr1, ptr2;
return 0;
}
But D must avoid introducing new ones. D2 has introduced a handy shortcut to
define templates, but this shortcut must not cause ambiguity for the eyes of
the programmer that reads the code (I don't care if the syntax is perfectly
defined for the D compiler, here I am talking about human users and their
fallible nature. Because the same was true for some C syntax too, that is well
defined for the compiler).
So to avoid troubles this code raises a syntax error, this is good:
struct Foo(T) {}
Foo!Foo!int y;
void main() {}
test.d(2): multiple ! arguments are not allowed
But this D2 code too may be ambiguous for the person that reads it:
struct Foo(T) {}
Foo!int* x;
static assert(!is(typeof(x) == Foo!(int*)));
static assert(is(typeof(x) == Foo!(int)*));
void main() {}
In similar situations I'd like D to require parentheses (so Foo!int* x;
becomes a syntax error), so the programmer must write:
Foo!(int*)
or:
Foo!(int)*
And this possible source of confusion for the person that reads the code is
avoided.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5287] New: (crash mtype.c) on function with default argument
http://d.puremagic.com/issues/show_bug.cgi?id=5287
Summary: (crash mtype.c) on function with default argument
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-11-28 15:38:26 PST ---
This is wrong D2 code:
void foo(Bar* p=null) {}
void main() {
foo();
}
DMD 2.050 crashes on it:
bug.d(1): Error: identifier 'Bar' is not defined
bug.d(1): Error: Bar is used as a type
Assertion failure: 'tn-mod == MODimmutable' on line 880 in file 'mtype.c'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5287] (crash mtype.c) on function with default argument
http://d.puremagic.com/issues/show_bug.cgi?id=5287
--- Comment #1 from bearophile_h...@eml.cc 2010-11-28 15:39:50 PST ---
A shorter case:
void foo(Bar* p=null) {}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5282] Use memcmp or other appropriate optimizations for array comparison where possible
http://d.puremagic.com/issues/show_bug.cgi?id=5282 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #3 from Stewart Gordon s...@iname.com 2010-11-28 18:16:25 PST --- The conditions for memcmp working as a way of comparing structs are: - no opEquals of a compatible parameter type - no holes due to alignment - no members with reference semantics (dynamic arrays, AAs, classes) - all of this applies recursively to any struct or union members -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4423] TDPL enums of struct types
http://d.puremagic.com/issues/show_bug.cgi?id=4423 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Summary|enums of struct types |TDPL enums of struct types OS/Version|Linux |All Severity|enhancement |normal --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-28 20:48:56 PST --- I'm elevating this to a bug, since TDPL clearly says that you can have enums of struct types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5282] Optimize array comparison which use memcmp to something better and remove unnecessary indirections.
http://d.puremagic.com/issues/show_bug.cgi?id=5282
Rob Jacques sandf...@jhu.edu changed:
What|Removed |Added
Keywords||performance
CC||sandf...@jhu.edu
Summary|Use memcmp or other |Optimize array comparison
|appropriate optimizations |which use memcmp to
|for array comparison where |something better and remove
|possible|unnecessary indirections.
--- Comment #4 from Rob Jacques sandf...@jhu.edu 2010-11-28 21:59:20 PST ---
Here are two optimized routines for bit-wise comparing two arrays for equality,
for both the dynamic/dynamic and dynamic/static case. These are significantly
faster than memcmp (~2.5x) and D's built-in == operator (~3.3x) for the
dynamic/dynamic case in a micro-benchmark. (The static case is naturally even
faster) The difference between memcmp and '==' appears to be due to inlining:
calling memcmp via a member function of a class (instead of from a free
function) had approximately the same performance as D's '=='.
This seems to indicate that a) use of memcmp in druntime for equality tests
should be replaced with the below routine and b) DMD should be calling
free-function versions of these routines instead of using multiple
indirections.
(By the way, does anyone know where array comparisons live in D? I tried
modifying TypeInfo_Ag, but that didn't seem to work)
/// Returns: true if the contents of two arrays are bit-wise equal.
bool bitwiseEquality(T) (const T[] a, const T[] b) pure nothrow @trusted {
if(a.length != b.length )
return false;
if(a.ptr is b.ptr)
return true;
size_t byte_length = a.length*T.sizeof;
size_t alignment = byte_length % ulong.sizeof;
if(( (*(cast(ulong*)a.ptr) ^ *(cast(ulong*)b.ptr)) 8 *
(ulong.sizeof-alignment) ))
return false;
alignment += (!alignment) * ulong.sizeof;
auto pa = cast(ulong*)(cast(ubyte*)a.ptr + alignment);
auto pb = cast(ulong*)(cast(ubyte*)b.ptr + alignment);
auto pa_end = cast(ulong*)(cast(ubyte*)a.ptr + byte_length);
while (pa pa_end)
if(*pa++ != *pb++ )
return false;
return true;
}
/// Returns: true if the contents of two arrays are bit-wise equal.
bool bitwiseEquality(T, size_t N)(const T[] a, ref const T[N] b) pure nothrow
@trusted {
static if(T.sizeof*N = uint.sizeof) {
return a.length == N !( (*(cast(uint*)a.ptr) ^ *(cast(uint*)b.ptr))
(uint.max 8*(uint.sizeof - T.sizeof*N) ));
} else static if(T.sizeof*N = ulong.sizeof) {
return a.length == N !( (*(cast(ulong*)a.ptr) ^
*(cast(ulong*)b.ptr)) (ulong.max 8*(ulong.sizeof - T.sizeof*N) ));
} else { // Fall back to a loop
if(a.length != N || (*(cast(ulong*)a.ptr) != *(cast(ulong*)b.ptr)) )
return false;
enum alignment = T.sizeof*N % ulong.sizeof 0 ? T.sizeof*N %
ulong.sizeof : ulong.sizeof;
auto pa = cast(ulong*)(cast(ubyte*)a.ptr + alignment);
auto pb = cast(ulong*)(cast(ubyte*)b.ptr + alignment);
auto pa_end = cast(ulong*)(cast(ubyte*)a.ptr + T.sizeof*N);
while (pa pa_end) {
if(*pa++ != *pb++ ) return false;
}
return true;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5282] Optimize array comparison which use memcmp to something better and remove unnecessary indirections.
http://d.puremagic.com/issues/show_bug.cgi?id=5282 --- Comment #5 from Rob Jacques sandf...@jhu.edu 2010-11-28 22:17:11 PST --- (In reply to comment #4) P.S. The performance gain of bitwiseEquality does drop for very large files (as things become more I/O bound), but it still maintains a ~1.5x advantage over memcmp. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
