D tool
Walter Bright has just released version 1.067 and 2.052 of DMD which offers 64-bit support on Linux for the D language. Also there is a GDC for version 2 of the language which is not handled in the current D tool. I will do some development of a new D tool (based on the current one that is in the SCons core) as a separate tool so that others may test anything I develop very easily -- having to work with a branch of the core to work on a tool gets infuriatingly irritating -- even using Mercurial! The core version can be updated from the separate version once it is finished so there is no problem there -- though it would all be a lot easier if the core was in Mercurial not Subversion ;-) I guess this is notice for anyone interested in D that the core D tool should be considered deprecated. If there is anyone out there using SCons for D compilation/linking and they are willing to help develop and/or test do get in touch. It gets lonely working on one's own! The Mercurial repository of the new tool is at https://bitbucket.org/russel/scons_dmd_new Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
ICOOOLPS 2011
Hello, Just forwarding this information, thought some of you may be interested: Workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS) == Welcome to the sixth workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS) being held on July 26th, at ECOOP 2011 in Lancaster, UK. Brief Overview The ICOOOLPS workshop aims to address this crucial issue of optimization of languages, programs and systems. It intends to do so by bringing together researchers and practitioners working in the field of implementation and optimization of programing languages. Its main goals are identifying fundamental bases and key current issues pertaining to the efficient implementation, compilation and optimization of programming languages, and outlining future challenges and research directions. For more information please read the call for papers. Program Committee To cover the broad areas of interest to the ICOOOLPS workshop the program committee comprises 19 independent specialists in the design, implementation and optimization of programming languages and systems from around the world. Past ICOOOLPS This is 6th ICOOOLPS workshop building on the success of workshops. See the resource links for more information. == From this page are all interesting links: http://www.icooolps.info/ Just tell me if ever such "spam" is "unwelcome" on D's list. Denis -- _ vita es estrany spir.wikidot.com
DMD versions
What is the official way of programmatically determining the version number of the currently executing dmd? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD versions
On Fri, 18 Feb 2011 07:36:18 -0500, Russel Winder wrote: What is the official way of programmatically determining the version number of the currently executing dmd? Thanks. AFAIK, there isn't a way. You can only determine D2 vs D1. It would be a good feature to add to druntime though. Since druntime is inextricably linked with dmd, you could define an enum with the minor version. I remember Tango does this. -Steve
Re: DMD versions
Am 18.02.2011 13:51, schrieb Steven Schveighoffer: On Fri, 18 Feb 2011 07:36:18 -0500, Russel Winder wrote: What is the official way of programmatically determining the version number of the currently executing dmd? Thanks. AFAIK, there isn't a way. You can only determine D2 vs D1. It would be a good feature to add to druntime though. Since druntime is inextricably linked with dmd, you could define an enum with the minor version. I remember Tango does this. -Steve There is the special Token __VERSION__ which gives an integer. http://www.digitalmars.com/d/2.0/lex.html greets Matthias
Re: DMD versions
On Fri, 18 Feb 2011 07:56:46 -0500, Matthias Pleh wrote: There is the special Token __VERSION__ which gives an integer. http://www.digitalmars.com/d/2.0/lex.html That works ;) I looked on the "conditional compilation" page. -Steve
Re: DMD versions
On Fri, 18 Feb 2011 08:08:46 -0500, Steven Schveighoffer wrote: > On Fri, 18 Feb 2011 07:56:46 -0500, Matthias Pleh > wrote: > > >> >> There is the special Token __VERSION__ which gives an integer. >> >> http://www.digitalmars.com/d/2.0/lex.html >> >> > That works ;) I looked on the "conditional compilation" page. > > -Steve Also, there's std.compiler, which "decodes" the information in __VERSION__. http://www.digitalmars.com/d/2.0/phobos/std_compiler.html -Lars
Re: tooling quality and some random rant
Hello all, "Walter Bright" wrote in message news:ijeih9$2aso$2...@digitalmars.com... > Don wrote: >> That would really be fun. >> BTW, the current Intel processors are basically the same as Pentium Pro, >> with a few improvements. The strange thing is, because of all of the >> reordering that happens, swapping the order of two (non-dependent) >> instructions makes no difference at all. So you always need to look at >> every instruction in the a loop, before you can do any scheduling. > > I was looking at Agner's document, and it looks like ordering the > instructions in the 4-1-1 or 4-1-1-1 for optimal decoding could work. This > would fit right in with the way the scheduler works. > > I had thought that with the CPU automatically reordering instructions, > that scheduling them was obsolete. Reordering happens in the scheduler. A simple model is "Fetch", "Schedule", "Retire". Fetch and retire are done in program order. For code that is hitting well in the cache, the biggest bottleneck is that "4" decoder (the complex instruction decoder). Reducing the number of complex instructions will be a big win here (and settling them into the 4-1-1(-1) pattern). Of course, on anything after Core 2, the "1" decoders can handle pushes, pops, and load-ops (r+=m) (although not load-op-store (m+=r)). Also, "macro op fusion" allows you can get a branch along with the last instruction in decode, potentially giving you 5 macroinstructions per cycle from decode. Make sure it is the flags producing instruction (cmp-br). (I used to work for Intel :) Ned
Re: DMD versions
On Fri, 2011-02-18 at 13:20 +, Lars T. Kyllingstad wrote: > On Fri, 18 Feb 2011 08:08:46 -0500, Steven Schveighoffer wrote: > > > On Fri, 18 Feb 2011 07:56:46 -0500, Matthias Pleh > > wrote: > > > > > >> > >> There is the special Token __VERSION__ which gives an integer. > >> > >> http://www.digitalmars.com/d/2.0/lex.html > >> > >> > > That works ;) I looked on the "conditional compilation" page. > > > > -Steve > > Also, there's std.compiler, which "decodes" the information in > __VERSION__. > > http://www.digitalmars.com/d/2.0/phobos/std_compiler.html Sadly (perhaps), when I said programmatically, I actually meant from Python. So gcc has the -v option giving output that can be "parsed" to find the version number. javac has the -version option, as does groovyc. OCaml has a -version option. gdc has a -v option. I could go on. dmd seemingly has no option for delivering a version number. Which is sad. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD versions
Russel Winder wrote: > On Fri, 2011-02-18 at 13:20 +, Lars T. Kyllingstad wrote: > > On Fri, 18 Feb 2011 08:08:46 -0500, Steven Schveighoffer wrote: > > > > > On Fri, 18 Feb 2011 07:56:46 -0500, Matthias Pleh > > > wrote: > > > > > > > > >> > > >> There is the special Token __VERSION__ which gives an integer. > > >> > > >> http://www.digitalmars.com/d/2.0/lex.html > > >> > > >> > > > That works ;) I looked on the "conditional compilation" page. > > > > > > -Steve > > > > Also, there's std.compiler, which "decodes" the information in > > __VERSION__. > > > > http://www.digitalmars.com/d/2.0/phobos/std_compiler.html > > Sadly (perhaps), when I said programmatically, I actually meant from > Python. So gcc has the -v option giving output that can be "parsed" to > find the version number. javac has the -version option, as does > groovyc. OCaml has a -version option. gdc has a -v option. I could go > on. dmd seemingly has no option for delivering a version number. Which > is sad. If you start dmd without any arguments it will give you the information as well. $ dmd Digital Mars D Compiler v2.052 ... So you can parse the first line of this output. Jens
Re: ICOOOLPS 2011
On 2/18/11 6:15 AM, spir wrote: Hello, Just forwarding this information, thought some of you may be interested: Workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS) [snip] Just tell me if ever such "spam" is "unwelcome" on D's list. Highly relevant (probably more for the announce list). Thanks! Andrei
Re: DMD versions
On Fri, 2011-02-18 at 14:47 +0100, Jens Mueller wrote: [ . . . ] > If you start dmd without any arguments it will give you the information > as well. > $ dmd > Digital Mars D Compiler v2.052 > ... > > So you can parse the first line of this output. OK, that is the same as "dmd --help", I can make it work. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Integer conversions too pedantic in 64-bit
"Jonathan M Davis" wrote in message news:mailman.1758.1298013272.4748.digitalmar...@puremagic.com... > On Thursday 17 February 2011 23:09:32 Russel Winder wrote: >> On Thu, 2011-02-17 at 11:09 -0800, Walter Bright wrote: >> > Russel Winder wrote: >> > > Do not be afraid of the word. Fear leads to anger. Anger leads to >> > > hate. Hate leads to suffering. (*) >> > > >> > > (*) With apologies to Master Yoda (**) for any misquote. >> > >> > "Luke, trust your feelings!" -- Oggie Ben Doggie >> > >> > Of course, expecting consistency from Star Wars is a waste of time. >> >> "What -- me worry?" Alfred E Newman (*) >> >> Star Wars is like Dr Who you expect revisionist history in every >> episode. I hate an inconsistent storyline, so the trick is to assume >> each episode is a completely separate story unrelated to any other >> episode. > > The funny thing is that Doctor Who does a number of things which I would > normally consider to make a show a bad show - such as being inconsistent > in its > timeline and generally being episodic rather than having real story arcs > (though > some of the newer Doctor Who stuff has had more of a story arc than was > typical > in the past) - but in spite of all that, it's an absolutely fantastic > show - > probably because the Doctor's just so much fun. Still, it's interesting > how it > generally breaks the rules of good storytelling and yet is still so great > to > watch. > One of the things that gets me about Doctor Who (at least the newer ones) is that The Doctor keeps getting companions from modern-day London who, like the Doctor, are enthralled by the idea of travelling anywhere in time and space, and yet...it seems like they still wind up spending most of their time in modern-day London anyway :) (I agree it's an enjoyable show though. The character of The Doctor is definitely a big part of what makes it work.)
Interfaces and Unit testing
Does using interfaces extensively have a performance drawback like using inheritance has? Why do I ask? I was thinking about adopting a coding practice where I define explicit interfaces for all public aspects of my classes, and then couples the interfaces closely to unit tests. Then, whenever I would create a new class using some of these interfaces the unit tests would tag along, which means the unit tests would be reusable. Now, if the compiler has do align stuff in some arduous way to accommodate these interfaces then this whole idea might not be worth it? Or are interfaces a no-cost constraint on the implementation? Erik Meer
DMD 2.0562
I had thought std.date was deprecated, it actually seems to have been decimated? Actually it seems to be trying to use datetime anyway? |> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o pi_d2_sequential.d std.date and std.dateparse have been scheduled for deprecation. Please use std.datetime instead. |> gcc -o pi_d2_sequential pi_d2_sequential.o -L/home/users/russel/lib.Linux.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(datetime_434_1ec.o): In function `_D3std8datetime5Clock11currStdTimeFNdNeZl': std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d): undefined reference to `clock_gettime' /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(time_10e_4d1.o): In function `_D4core4time12TickDuration12_staticCtor7OFNeZv': src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv+0x1f): undefined reference to `clock_getres' /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a(time_10e_4d1.o): In function `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration': src/core/time.d:(.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration+0x1f): undefined reference to `clock_gettime' collect2: ld returned 1 exit status -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Interfaces and Unit testing
Erik Meer Wrote: > Does using interfaces extensively have a performance drawback like using > inheritance has? > > Why do I ask? I was thinking about adopting a coding practice where I define > explicit interfaces for all public aspects of my classes, and then couples > the interfaces closely to unit tests. Then, whenever I would create a new > class using some of these interfaces the unit tests would tag along, which > means the unit tests would be reusable. > > Now, if the compiler has do align stuff in some arduous way to accommodate > these interfaces then this whole idea might not be worth it? Or are > interfaces a no-cost constraint on the implementation? > > Erik Meer So you want interfaces only for unittests and won't use them in your code?
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
On 16/02/2011 17:54, Ulrik Mikaelsson wrote: 2011/2/16 Russel Winder: Definitely the case. There can only be one repository that represents the official state of a given project. That isn't really the issue in the move from CVCS systems to DVCS systems. Just note that not all projects have a specific "state" to represent. Many projects are centered around the concept of a centralized project, a "core"-team, and all-around central organisation and planning. Some projects however, I guess the Linux kernel is a prime example, have been quite de-centralized even in their nature for a long time. In the case of KDE, for a centralized example, there is a definite "project version", which is the version currently blessed by the central project team. There is a centralized project planning, including meetings, setting out goals for the coming development. In the case of Linux, it's FAR less obvious. Sure, most people see master@torvalds/linux-2.6.git as THE Linux-version. However, there are many other trees interesting to track as well, such as the various distribution-trees which might incorporate many drivers not in mainline, especially for older stability-oriented kernels, RHEL or Debian is probably THE version to care about. You might also be interested in special-environment-kernels, such as non x86-kernels, in which case you're probably more interested in the central repo for that architecture, which is rarely Linuses. Also, IIRC, hard and soft realtime-enthusiasts neither looks at linuses tree first. Above all, in the Linux-kernel, there is not much of "centralised planning". Linus doesn't call to a big planning-meeting quarterly to set up specific milestones for the next kernel release, but in the beginning of each cycle, he is spammed with things already developed independently, scratching someones itch. He then cherry-picks the things that has got good reviews and are interesting for where he wants to go with the kernel. That is not to say that there aren't a lot of coordination and communication, but there isn't a clear centralized authority steering development in the same ways as in many other projects. The bottom line is, many projects, even ones using DVCS, are often centrally organized. However, the Linux kernel is clear evidence it is not the only project model that works. Yeah, that's true. Some projects, the Linux kernel being one of the best examples, are more distributed in nature than not, in actual organizational terms. But projects like that are (and will remain) in the minority, a minority which is probably a very, very small. -- Bruno Medeiros - Software Engineer
64bit phobos on Windows?
I know that 64bit support on Windows is behind Linux etc for various reasons, but i thought i'd tried building some things with -m64 just to test, and got a bunch of errors like std\file.d(223): Error: undefined identifier GetLastError std\file.d(2067): Error: undefined identifier WIN32_FIND_DATA Which appears to be because various things in Phobos use version(Win32), and only 'Win64' is set in 64bit builds. I guess that at least some of these should be using version(Windows) instead?
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/17 Bruno Medeiros : > > Yeah, that's true. Some projects, the Linux kernel being one of the best > examples, are more distributed in nature than not, in actual organizational > terms. But projects like that are (and will remain) in the minority, a > minority which is probably a very, very small. > Indeed. However, I think it will be interesting to see how things develop, if this will be the case in the future too. The Linux kernel, and a few other projects were probably decentralized from start by necessity, filling very different purposes. However, new tools tends to affect models, which might make it a bit more common in the future. In any case, it's an interesting time to do software development.
Re: Interfaces and Unit testing
On Fri, 18 Feb 2011 09:43:19 -0500, Erik Meer wrote:
Does using interfaces extensively have a performance drawback like using
inheritance has?
Why do I ask? I was thinking about adopting a coding practice where I
define explicit interfaces for all public aspects of my classes, and
then couples the interfaces closely to unit tests. Then, whenever I
would create a new class using some of these interfaces the unit tests
would tag along, which means the unit tests would be reusable.
Now, if the compiler has do align stuff in some arduous way to
accommodate these interfaces then this whole idea might not be worth it?
Or are interfaces a no-cost constraint on the implementation?
There is a real cost associated with interfaces. Each additional
interface on a class requires another pointer-sized word space. I would
recommend not adding interfaces if the sole purpose is to use them for
unit tests.
You can reuse unit tests by creating a template function.
example:
// all classes that define foo conform to the foo definition.
class X
{
int foo() {...}
}
class Y
{
int foo() {...}
}
unittest
{
void testFoo(T)(T t) { assert(t.foo() == 0); }
testFoo(new X);
testFoo(new Y);
}
-Steve
Re: 64bit phobos on Windows?
== Quote from Richard Webb (we...@beardmouse.org.uk)'s article > I know that 64bit support on Windows is behind Linux etc for various reasons, > but i thought i'd tried building some things with -m64 just to test, and got a > bunch of errors like > std\file.d(223): Error: undefined identifier GetLastError > std\file.d(2067): Error: undefined identifier WIN32_FIND_DATA > Which appears to be because various things in Phobos use version(Win32), and > only 'Win64' is set in 64bit builds. > I guess that at least some of these should be using version(Windows) instead? Yea, also even if a working Win64 codegen/linker is still fairly far off, it would be nice to be able to test that code passes semantic analysis in 64 under Windows.
Re: Integer conversions too pedantic in 64-bit
Don писал(а) в своём письме Wed, 16 Feb 2011 17:21:06 +0600: Exactly. It is NOT the same as the 8 & 16 bit case. The thing is, the fraction of cases where the MSB is important has been decreasing *exponentially* from the 8-bit days. [...] Some facts to back your opinion: * today's most powerful supercomputer have "just" 230 TB of RAM, which is between 2^47 and 2^48 (http://www.top500.org/site/systems/3154) * Windows7 x64 __virtual__ memory limit is 8 TB (= 2^43) (http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#physical_memory_limits_windows_7) -- Alexander
Re: Interfaces and Unit testing
As mentioned by Steven there are other ways to this without Interfaces. Templates are one very nice way and you may also find: AutoImplements BlackHole WhiteHole http://digitalmars.com/d/2.0/phobos/std_typecons.html#AutoImplement Useful. I thought there was also going to be something that would take a given class and derive it from a base class to assume the type. But I guess that isn't in Phobos.
Re: DMD 2.0562
On Fri, 18 Feb 2011 15:26:20 +, Russel Winder wrote: > I had thought std.date was deprecated, it actually seems to have been > decimated? Actually it seems to be trying to use datetime anyway? > > > |> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o > pi_d2_sequential.d std.date and std.dateparse have been scheduled for > deprecation. Please use std.datetime instead. > > |> gcc -o pi_d2_sequential pi_d2_sequential.o > -L/home/users/russel/lib.Linux.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a (datetime_434_1ec.o): > In function `_D3std8datetime5Clock11currStdTimeFNdNeZl': > std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d): > undefined reference to `clock_gettime' > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a (time_10e_4d1.o): > In function `_D4core4time12TickDuration12_staticCtor7OFNeZv': > src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv +0x1f): > undefined reference to `clock_getres' > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a (time_10e_4d1.o): > In function > `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration': > src/core/time.d: (.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration +0x1f): > undefined reference to `clock_gettime' collect2: ld returned 1 exit > status You need to link in librt. Pass the -L-lrt option to DMD (or -lrt to GCC), and you get rid of the "undefined reference" errors. -Lars
Re: Interfaces and Unit testing
Steven Schveighoffer Wrote:
> On Fri, 18 Feb 2011 09:43:19 -0500, Erik Meer wrote:
>
> > Does using interfaces extensively have a performance drawback like using
> > inheritance has?
> >
> > Why do I ask? I was thinking about adopting a coding practice where I
> > define explicit interfaces for all public aspects of my classes, and
> > then couples the interfaces closely to unit tests. Then, whenever I
> > would create a new class using some of these interfaces the unit tests
> > would tag along, which means the unit tests would be reusable.
> >
> > Now, if the compiler has do align stuff in some arduous way to
> > accommodate these interfaces then this whole idea might not be worth it?
> > Or are interfaces a no-cost constraint on the implementation?
>
> There is a real cost associated with interfaces. Each additional
> interface on a class requires another pointer-sized word space. I would
> recommend not adding interfaces if the sole purpose is to use them for
> unit tests.
>
> You can reuse unit tests by creating a template function.
>
> example:
>
> // all classes that define foo conform to the foo definition.
>
> class X
> {
> int foo() {...}
> }
>
> class Y
> {
> int foo() {...}
> }
>
> unittest
> {
> void testFoo(T)(T t) { assert(t.foo() == 0); }
> testFoo(new X);
> testFoo(new Y);
> }
>
> -Steve
Excellent! In addition to not introducing overhead, this is better because the
"interface" is entirely verified by the unit test, i.e. you don't have to name
it when defining the class.
Thanks, guys!
RND engines benchs
Timings, n = 100_000_000, seconds, best of 6:
Xorshift: 1.08
MinstdRand: 1.15
Mt19937:1.92
DMD 2.052. It seems that compared to MinstdRand, Xorshift is both faster and
gives higher quality outputs :-)
import std.stdio, std.random;
void main() {
uint r;
//auto rnd = Xorshift(1);
//auto rnd = Mt19937(1);
auto rnd = MinstdRand(1);
foreach (i; 0 .. 100_000_000) {
r = rnd.front;
rnd.popFront();
}
writeln(r);
}
Another interesting engine:
http://d.puremagic.com/issues/show_bug.cgi?id=5509
Bye,
bearophile
Re: DMD 2.0562
On Friday, February 18, 2011 09:41:07 Lars T. Kyllingstad wrote: > On Fri, 18 Feb 2011 15:26:20 +, Russel Winder wrote: > > I had thought std.date was deprecated, it actually seems to have been > > decimated? Actually it seems to be trying to use datetime anyway? > > > > |> dmd -I. -O -release -inline -m64 -c -ofpi_d2_sequential.o > > > > pi_d2_sequential.d std.date and std.dateparse have been scheduled for > > deprecation. Please use std.datetime instead. > > > > |> gcc -o pi_d2_sequential pi_d2_sequential.o > > > > -L/home/users/russel/lib.Linux.x86_64/DMD2/lib64 -lphobos2 -lpthread -lm > > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a > > (datetime_434_1ec.o): > > In function `_D3std8datetime5Clock11currStdTimeFNdNeZl': > > std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d): > > undefined reference to `clock_gettime' > > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a > > (time_10e_4d1.o): > > In function `_D4core4time12TickDuration12_staticCtor7OFNeZv': > > src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv > > +0x1f): > > undefined reference to `clock_getres' > > /home/users/russel/lib.Linux.x86_64/DMD2/lib64/libphobos2.a > > (time_10e_4d1.o): > > In function > > `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration': > > src/core/time.d: > (.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDur > ation > > +0x1f): > > undefined reference to `clock_gettime' collect2: ld returned 1 exit > > status > > You need to link in librt. Pass the -L-lrt option to DMD (or -lrt to > GCC), and you get rid of the "undefined reference" errors. Yeah. Make sure that your dmd.conf is up-to-date. There are a number of changes in it with the most recent release - not only the addition of librt, but the lib directories were changed as well. So, everyone should either use the dmd.conf that comes in the release or make sure that the dmd.conf that they use is based on that dmd.conf. You're going to run into problems otherwise. - Jonathan M Davis
Re: Stupid little iota of an idea
Nick Sabalausky wrote: "bearophile" wrote in message news:ij473k$1tfn$1...@digitalmars.com... Andrei: Aside from the fact that "range" has another meaning in D, the word does not convey the notion that iota adds incremental steps to move from one number to another. "Iota" does convey that notion. I have accepted the "iota" name, it's short, easy to remember, it has one historical usage in APL, and "Range" has another meaning in D (but it's weird, and it's something you need to learn, it's not something a newbie is supposed to know before reading D2 docs well. The name "interval" is better, simpler to understand, but it's longer for a so common function). But this answer of yours is stepping outside the bounds of reasonableness :-) If you ask a pool of 20 programmers what range(10,20) or iota(10,20) means, I'm sure more people will guess range() correctly than iota(). The word range() do convey a complete enumeration of values in an interval. iota() does not convey that. Said all this, I suggest to introduce the first-class a..b interval syntax in D (or even a..b:c), this is able to remove most (all?) usage of iota(). I like "interval", too. I do think the name "iota" is a nice extra reason to just use a..b or a..b:c like you say. It also makes it clear that it's a series of discrete values rather than a true mathematical range, since that's exactly how foreach already uses a..b: as a series of discrete values. I don't like interval at all, because I don't think it includes the notion of 'stepping'. An interval is just, everything from A to B, without necessarily specifying how you reach everything in that interval. Whereas iota includes the stepping. (I would like to see intervals in the language, but just as an [a,b] pair). OTOH iota() is unintuitive to me, and I do keep reading it as itoa(). Sadly I don't have any better suggestions.
Re: Integer conversions too pedantic in 64-bit
Russel Winder wrote: Star Wars is like Dr Who you expect revisionist history in every episode. I hate an inconsistent storyline, so the trick is to assume each episode is a completely separate story unrelated to any other episode. My trick was to lose all interest in SW. Have you seen the series "Defying Gravity"? The plot is a spaceship is sent around a to pass by various planets in the solar system on a mission of discovery. The script writers apparently thought this was boring, so to liven things up they installed a ghost on the spaceship. It's really, really sad.
Short strings optimization
I've found this simple blog post: http://journal.thobe.org/2011/02/better-support-for-short-strings-in.html It suggests the creation of a ShortArray struct, that like arrays is size_t.sizeof*2, that's usable for short arrays and short strings. In 64 bit mode that's 16 bytes long, just like a dynamic array. The higher bit of the struct may denote a "short array". If it's 0, then the the second nibble of the first byte represents the length (even if it's an array of bytes its length can't be more than 15), otherwise the struct contains a length/ptr pair, like a normal dynamic array. This is able to remove many heap allocations (without any compression or tricks), because in programs a good percentage of strings are short. Every time an item of the array is accessed, the struct opIndex/opIndexAssign has to test the first bit, this lowers the performance, but there are no pointers to follow in other parts of the memory, so the overall performance is probably not much different, and if the array is in RAM instead of caches, it may be even faster. The ptr is not always a pointer, so the GC needs to be aware of this and do not follow the pointer if the first bit of the struct is 0. To manage this cleanly, it's useful a standard method like onGCScan() I have suggested time ago, to specify the runtime semantics for the garbage collector. Bye, bearophile
Re: Integer conversions too pedantic in 64-bit
"Walter Bright" wrote in message news:ijmnp7$433$1...@digitalmars.com... > Russel Winder wrote: >> Star Wars is like Dr Who you expect revisionist history in every >> episode. I hate an inconsistent storyline, so the trick is to assume >> each episode is a completely separate story unrelated to any other >> episode. > > My trick was to lose all interest in SW. > I must not be enough of a Star Wars guy, I don't know what anyone's talking about here. Was it the prequel trilogy that introduced the inconsistencies (I still haven't gotten around to episodes 2 or 3 yet), or were there things in the orignal trilogy that I managed to completely overlook? (Or something else entirely?) > Have you seen the series "Defying Gravity"? The plot is a spaceship is > sent around a to pass by various planets in the solar system on a mission > of discovery. The script writers apparently thought this was boring, so to > liven things up they installed a ghost on the spaceship. > > It's really, really sad. Sounds like Stargate Universe: A bunch of people trapped on a ancient spaceship of exploration...but to make that concept "interesting" the writers had to make every damn character on the show a certifiable drama queen. Unsurprisingly, dead after only two seasons - a record low for Stargate. Really looking forward to the movie sequels though (as well as the new SG-1/Atlantis movies that, I *think*, are still in the works).
Re: Stupid little iota of an idea
On Fri, 18 Feb 2011 22:10:37 +0100, Don wrote: > Nick Sabalausky wrote: >> I like "interval", too. >> >> I do think the name "iota" is a nice extra reason to just use a..b or >> a..b:c like you say. It also makes it clear that it's a series of >> discrete values rather than a true mathematical range, since that's >> exactly how foreach already uses a..b: as a series of discrete values. > > I don't like interval at all, because I don't think it includes the > notion of 'stepping'. An interval is just, everything from A to B, > without necessarily specifying how you reach everything in that > interval. Whereas iota includes the stepping. (I would like to see > intervals in the language, but just as an [a,b] pair). > > OTOH iota() is unintuitive to me, and I do keep reading it as itoa(). > Sadly I don't have any better suggestions. I have a similar range in SciD, which is called steps(). It differs from iota() in that a) you specify the number of steps instead of the step size and b) it only iterates over FP numbers and ensures that the first and last iterated values are in fact exactly the endpoints you specify. I guess steps() would be a possible name for iota(), but then I would have to come up with a new name for my range. ;) -Lars
Re: Stupid little iota of an idea
Lars T. Kyllingstad wrote: I guess steps() would be a possible name for iota(), but then I would have to come up with a new name for my range. ;) Might I suggest iota()? ;) -- Simen
Re: RND engines benchs
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Timings, n = 100_000_000, seconds, best of 6:
> Xorshift: 1.08
> MinstdRand: 1.15
> Mt19937:1.92
> DMD 2.052. It seems that compared to MinstdRand, Xorshift is both faster and
gives higher quality outputs :-)
> import std.stdio, std.random;
> void main() {
> uint r;
> //auto rnd = Xorshift(1);
> //auto rnd = Mt19937(1);
> auto rnd = MinstdRand(1);
> foreach (i; 0 .. 100_000_000) {
> r = rnd.front;
> rnd.popFront();
> }
> writeln(r);
> }
> Another interesting engine:
> http://d.puremagic.com/issues/show_bug.cgi?id=5509
> Bye,
> bearophile
What do you think of my 2 sided dice?
bool randBool()
{
static uint r;
static size_t n = 32;
if( n >= 32 ){
r = rand();
n = 0;
}
return cast(bool)bt( &r, n++ );
}
Re: Integer conversions too pedantic in 64-bit
On Friday, February 18, 2011 14:20:03 Nick Sabalausky wrote: > "Walter Bright" wrote in message > news:ijmnp7$433$1...@digitalmars.com... > > > Russel Winder wrote: > >> Star Wars is like Dr Who you expect revisionist history in every > >> episode. I hate an inconsistent storyline, so the trick is to assume > >> each episode is a completely separate story unrelated to any other > >> episode. > > > > My trick was to lose all interest in SW. > > I must not be enough of a Star Wars guy, I don't know what anyone's talking > about here. Was it the prequel trilogy that introduced the inconsistencies > (I still haven't gotten around to episodes 2 or 3 yet), or were there > things in the orignal trilogy that I managed to completely overlook? (Or > something else entirely?) The prequel movies definitely have some inconsistencies with the originals, but for the most part, they weren't huge. I suspect that the real trouble comes in when you read the books (which I haven't). - Jonathan M Davis
Re: DMD 2.0562
On Fri, 2011-02-18 at 10:31 -0800, Jonathan M Davis wrote: [ . . . ] > Yeah. Make sure that your dmd.conf is up-to-date. There are a number of > changes > in it with the most recent release - not only the addition of librt, but the > lib > directories were changed as well. So, everyone should either use the dmd.conf > that comes in the release or make sure that the dmd.conf that they use is > based > on that dmd.conf. You're going to run into problems otherwise. linux/bin/dmd.conf is identical in the 2.051 and 2.052 distributions which implies the distribution is broken? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD 2.0562
On Friday, February 18, 2011 16:58:50 Russel Winder wrote: > On Fri, 2011-02-18 at 10:31 -0800, Jonathan M Davis wrote: > [ . . . ] > > > Yeah. Make sure that your dmd.conf is up-to-date. There are a number of > > changes in it with the most recent release - not only the addition of > > librt, but the lib directories were changed as well. So, everyone should > > either use the dmd.conf that comes in the release or make sure that the > > dmd.conf that they use is based on that dmd.conf. You're going to run > > into problems otherwise. > > linux/bin/dmd.conf is identical in the 2.051 and 2.052 distributions > which implies the distribution is broken? No, they're definitely _not_ the same - at least not in the zip file. Maybe the deb or the rpm is messed up, but the zip file is fine. It _does_ look like -L-lrt was added in dmd 2.051 (though I'm not sure if it was necessary for 2.051), but ther are other changes related to 64-bit which are in 2.052. The lib directory changed from lib to lib32 and lib64 and a linker flag was added to go with that (to stop gcc from complaining about library mismatches). You need a new dmd.conf for the new release. The correct dmd.conf _is_ in the zip file. - Jonathan M Davis
Re: Integer conversions too pedantic in 64-bit
Jonathan M Davis wrote: The prequel movies definitely have some inconsistencies with the originals, but for the most part, they weren't huge. I suspect that the real trouble comes in when you read the books (which I haven't). Huge? How about it never occurs to Vader to search for Luke at the most obvious location in the universe - his nearest living relatives (Uncle Owen)? That's just the start of the ludicrousness. Ok, I have no right to be annoyed, but what an opportunity (to make a truly great movie) squandered.
Re: Integer conversions too pedantic in 64-bit
On Friday, February 18, 2011 17:39:34 Walter Bright wrote: > Jonathan M Davis wrote: > > The prequel movies definitely have some inconsistencies with the > > originals, but for the most part, they weren't huge. I suspect that the > > real trouble comes in when you read the books (which I haven't). > > Huge? How about it never occurs to Vader to search for Luke at the most > obvious location in the universe - his nearest living relatives (Uncle > Owen)? That's just the start of the ludicrousness. > > Ok, I have no right to be annoyed, but what an opportunity (to make a truly > great movie) squandered. Well, that's not really an inconsistency so much as not properly taking everything into account in the plot (though to be fair, IIRC, Vader had no clue that he even _had_ kids, so it's not like he would have gone looking in the first place). Regardless, I don't think that there's much question that those films could have been much better. - Jonathan M Davis
O(N) Garbage collection?
I've been trying out D's new 64-bit compiler and a serious barrier to
using it effectively seems to be abysmal garbage collection performance
with large heaps. It seems like the time for a garbage collection to run
scales linearly with the size of the heap *even if most of the heap is
marked as NO_SCAN*. I'm running a program with a heap size of ~6GB,
almost all of which is strings (DNA sequences), which are not scanned by
the GC. It's spending most of its time in GC, based on pausing it every
once in a while in GDB and seeing what's at the top of the stack.
Here's a test program and the results for a few runs.
import std.stdio, std.datetime, core.memory, std.conv;
void main(string[] args) {
if(args.length < 2) {
stderr.writeln("Need size.");
return;
}
immutable mul = to!size_t(args[1]);
auto ptr = GC.malloc(mul * 1_048_576, GC.BlkAttr.NO_SCAN);
auto sw = StopWatch(autoStart);
GC.collect();
immutable msec = sw.peek.msecs;
writefln("Collected a %s megabyte heap in %s milliseconds.",
mul, msec);
}
Outputs for various sizes:
Collected a 10 megabyte heap in 1 milliseconds.
Collected a 50 megabyte heap in 4 milliseconds.
Collected a 200 megabyte heap in 16 milliseconds.
Collected a 500 megabyte heap in 41 milliseconds.
Collected a 1000 megabyte heap in 80 milliseconds.
Collected a 5000 megabyte heap in 397 milliseconds.
Collected a 1 megabyte heap in 801 milliseconds.
Collected a 3 megabyte heap in 2454 milliseconds.
Collected a 5 megabyte heap in 4096 milliseconds.
Note that these tests were run on a server with over 100 GB of physical
RAM, so a shortage of physical memory isn't the problem. Shouldn't GC
be O(1) with respect to the size of the unscanned portion of the heap?
Re: Integer conversions too pedantic in 64-bit
Jonathan M Davis wrote: Vader had no clue So much for his force!
Re: Integer conversions too pedantic in 64-bit
Walter Bright wrote: Jonathan M Davis wrote: The prequel movies definitely have some inconsistencies with the originals, but for the most part, they weren't huge. I suspect that the real trouble comes in when you read the books (which I haven't). Huge? How about it never occurs to Vader to search for Luke at the most obvious location in the universe - his nearest living relatives (Uncle Owen)? That's just the start of the ludicrousness. Ok, I have no right to be annoyed, but what an opportunity (to make a truly great movie) squandered. I nominate the second prequel for the worst movie of all time. I never saw the third one.
Re: Integer conversions too pedantic in 64-bit
Don wrote: I nominate the second prequel for the worst movie of all time. I never saw the third one. You didn't miss a thing.
Re: tooling quality and some random rant
nedbrek wrote: Reordering happens in the scheduler. A simple model is "Fetch", "Schedule", "Retire". Fetch and retire are done in program order. For code that is hitting well in the cache, the biggest bottleneck is that "4" decoder (the complex instruction decoder). Reducing the number of complex instructions will be a big win here (and settling them into the 4-1-1(-1) pattern). Of course, on anything after Core 2, the "1" decoders can handle pushes, pops, and load-ops (r+=m) (although not load-op-store (m+=r)). Also, "macro op fusion" allows you can get a branch along with the last instruction in decode, potentially giving you 5 macroinstructions per cycle from decode. Make sure it is the flags producing instruction (cmp-br). (I used to work for Intel :) I can't find any Intel documentation on this. Can you point me to some?
Re: Integer conversions too pedantic in 64-bit
On Fri, 2011-02-18 at 17:52 -0800, Jonathan M Davis wrote: > On Friday, February 18, 2011 17:39:34 Walter Bright wrote: > > Jonathan M Davis wrote: > > > The prequel movies definitely have some inconsistencies with the > > > originals, but for the most part, they weren't huge. I suspect that the > > > real trouble comes in when you read the books (which I haven't). > > > > Huge? How about it never occurs to Vader to search for Luke at the most > > obvious location in the universe - his nearest living relatives (Uncle > > Owen)? That's just the start of the ludicrousness. The wikipedia article http://en.wikipedia.org/wiki/Star_Wars is quite interesting, and indicates why there are lots of little inconsistencies as well as quite a few big ones. As to the veracity of the material, who knows, it's the Web, lies have the exact same status as truth. > > Ok, I have no right to be annoyed, but what an opportunity (to make a truly > > great movie) squandered. > > Well, that's not really an inconsistency so much as not properly taking > everything into account in the plot (though to be fair, IIRC, Vader had no > clue > that he even _had_ kids, so it's not like he would have gone looking in the > first > place). Regardless, I don't think that there's much question that those films > could have been much better. I think there has been a loss of historical context here, leading to anti-rose coloured (colored?) spectacles. in 1977, Star Wars was a watershed film. Simple fairy tale storyline, space opera on film instead of book. It's impact was greater than 2001: A Space Odyssey which had analogous impact albeit to a smaller audience in 1968. I am sure there are films from the 1940s and 1950s that deserve similar status but television changed the nature of film impact, making 2001 and Star Wars more influential -- again historical context is important. I think Return of the Jedi is quite fun and that the rest of the Star Wars films lost the simplicity and brilliance of Star Wars, pandering to the need for huge budget special effects, essentially driving us to the computer generated, poor storyline, stuff that gets churned out today. With the exception of The Lord of The Rings. Sadly all the effects companies are using C++ and Python, can D get traction as the language of choice for the post-production companies? Crikey, this thread has drifted a good few light years from the original title. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
