![\"\"](\"http:\/\/dlang.org\/blog\/wp-content\/uploads\/2016\/08\/d6.png\")
<\/p>\n<\/p>\n
The D Language Foundation is happy to announce DMD 2.077.0. This latest release of the reference compiler for the D programming language is available from the dlang.org Downloads page<\/a>. Among the usual slate of bug and regression fixes<\/a>, this release brings a couple of particulary beneficial enhancements that will have an immediate impact on some existing projects.<\/p>\n Thanks to Rainer Sch\u00fctze, the compiler now produces significantly smaller mangled names in situations where they had begun to get out of control, particularly in the case of IFTI (Implicit Function Template Instantiation) where Voldemort types are involved. That may call for a bit of a detour here.<\/p>\n Voldemort types<\/a> are perhaps one of D\u2019s more interesting features. They look like this:<\/p>\n Here we have an auto function<\/a>, a function for which the return type is inferred, returning an instance of a type declared inside the function. It\u2019s possible to access public members on the instance even though its type can never be named outside of the function where it was declared. Coupled with type inference in variable declarations, it\u2019s possible to store the returned instance and reuse it. This serves as an extra level of encapsulation where it\u2019s desired.<\/p>\n In D, for any given API, as far as the world outside of a module is concerned, module private<\/em> is the lowest level of encapsulation.<\/p>\n Here, the type Sometimes you just may not want One unforeseen consequence of Voldemort types that was first reported<\/a> in mid\u20132016 was that, when used in templated functions, they caused a serious explosion in the size of the mangled function names (in some cases up to 1 MB!), making for some massive object files. There was a good bit of forum discussion on how to trim them down, with a number of ideas tossed around. Ultimately, Rainer Sch\u00fctze took it on. His persistence has resulted in shorter mangled names all around, but the wins are particularly impressive when it comes to IFTI and Voldemort types. (Rainer is also the maintainer of Visual D<\/a>, the D programming language plugin for Visual Studio)<\/p>\n D\u2019s name-mangling scheme is detailed in the ABI documentation<\/a>. The description of the new enhancement is in the section titled \u2018Back references\u2019<\/a>.<\/p>\n D has long supported array operations such as element-wise addtion, multiplication, etc. For example:<\/p>\n In some cases, such operations could be vectorized. The reason it was some<\/em> cases and not all<\/em> cases is because dedicated assembly routines were used to achieve the vectorization and they weren\u2019t implemented for every case.<\/p>\n With 2.077.0, that\u2019s no longer true. Vectorization is now templated so that all array operations benefit. Any codebase out there using array operations that were not previously vectorized can expect a sizable performance increase for those operations thanks to the increased throughput (though whether an application benefits overall is of course context-dependent). How the benefit is received depends on the compiler being used. From the changelog:<\/p>\n For GDC\/LDC the implementation relies on auto-vectorization, for DMD the implementation performs the vectorization itself. Support for vector operations with DMD is determined statically (-mcpu=native, -mcpu=avx2) to avoid binary bloat and the small test overhead. DMD enables SSE2 for 64-bit targets by default.<\/p><\/blockquote>\n Note that the changelog initially showed DMD\u2019s implementation is implemented in terms of The changelog also notes that there\u2019s a potential for division performed on float arrays in existing code to see a performance decrease in exchange for an increase in precision.<\/p>\n The implementation no longer weakens floating point divisions (e.g. Just the other day, someone asked in the forums if DMD supports reproducible builds<\/a>. As of 2.077.0, the answer is affirmative. DMD now ensures that compilation is deterministic such that given the same source code and the same compiler version, the binaries produced will be identical. If this is important to you, be sure not to use any of the non-determistic lexer tokens ( DMD\u2019s Cutting symbol bloat<\/h3>\n
The types that shall not be named<\/h4>\n
auto getHeWhoShallNotBeNamed() \r\n{\r\n struct NoName \r\n {\r\n void castSpell() \r\n {\r\n import std.stdio : writeln;\r\n writeln(\"Crucio!\");\r\n } \r\n }\r\n return NoName();\r\n}\r\n\r\nvoid main() \r\n{\r\n auto voldemort = getHeWhoShallNotBeNamed();\r\n voldemort.castSpell();\r\n}<\/pre>\nmodule foobar;\r\n\r\nprivate struct Foo\r\n{\r\n int x;\r\n}\r\n\r\nstruct Bar \r\n{\r\n private int y;\r\n int z;\r\n}<\/pre>\nFoo<\/code> is module private. Bar<\/code> is shown here for completeness, as those new to D are often surprised to learn that private members of an aggregate type are also module private (D\u2019s equivalent of the C++ friend<\/code> relationship). There is no keyword that indicates a lower level of encapsulation.<\/p>\nFoo<\/code> to be visible to the entire module. While it\u2019s true that anyone making a breaking change to Foo\u2019s interface also has access to the parts of the module that break (which is the rationale behind module-private members), there are times when you may not want the entire module to have access to Foo<\/code> at all. Voldemort types fill that role of hiding details not just from the world, but from the rest of the module.<\/p>\nThe evil side of Voldemort types<\/h4>\n
Improved vectorization<\/h3>\n
int[] arr1 = [0, 1, 2];\r\nint[] arr2 = [3, 4, 5];\r\nint[3] arr3 = arr1[] + arr2[];\r\nassert(arr3 == [3, 5, 7]);<\/pre>\n
-march<\/code> instead of -mcpu<\/code> in the quoted lines, and the updated version had not yet been posted when this announcement was published.<\/em><\/p>\ncore.simd<\/code><\/a>, which is also part of DRuntime\u2019s public API<\/a>.<\/p>\nary[] \/ scalar<\/code>) to multiplication (ary[] * (1.0 \/ scalar)<\/code>) as that may reduce precision. To preserve the higher performance of float multiplication when loss of precision is acceptable, use either -ffast-math<\/code> with GDC\/LDC or manually rewrite your code to multiply by (1.0 \/ scalar<\/code>) for DMD.<\/p><\/blockquote>\nOther assorted treats<\/h3>\n
__DATE__<\/code>, __TIME__<\/code>, and __TIMESTAMP__<\/code>) in your code.<\/p>\n-betterC<\/code> command line option gets some more love in this release. When it’s enabled, DRuntime is not available. Library authors can now use the predefined version<\/a>\u00a0D_BetterC<\/code> to determine when that is the case so that, where it\u2019s feasible, they can more conveniently support applications with and without the runtime. Also, the option\u2019s behavior is now documented<\/a>, so it\u2019s no longer necessary to go to the forums or parse through search results to figure out what is and isn\u2019t actually supported in BetterC mode.<\/p>\n