Re: Increasing D Compiler Speed by Over 75%
On 01.08.2013 07:33, dennis luehring wrote: Am 31.07.2013 23:24, schrieb Rainer Schuetze: On 31.07.2013 09:00, Walter Bright wrote: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): can you also give us also timings for (dmd_dmc|dmd_msc) std\algorithm -unittest -main std.algorithm -unittest -main: dmd_dmc 20 sec, std new 61 sec dmd_msc 11 sec, std new 13 sec std.algorithm -unittest -main -O: dmd_dmc 27 sec, std new 68 sec dmd_msc 16 sec, std new 18 sec
Re: Increasing D Compiler Speed by Over 75%
Am 01.08.2013 08:16, schrieb Rainer Schuetze: On 01.08.2013 07:33, dennis luehring wrote: Am 31.07.2013 23:24, schrieb Rainer Schuetze: On 31.07.2013 09:00, Walter Bright wrote: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): can you also give us also timings for (dmd_dmc|dmd_msc) std\algorithm -unittest -main std.algorithm -unittest -main: dmd_dmc 20 sec, std new 61 sec dmd_msc 11 sec, std new 13 sec std.algorithm -unittest -main -O: dmd_dmc 27 sec, std new 68 sec dmd_msc 16 sec, std new 18 sec results from mingw, vs2012(13) and llvm-clang builds would be also very interesting, but i don't know if dmd can be build with mingw or clang out of the box under windows
Re: Article: Increasing the D Compiler Speed by Over 75%
On Wednesday, 31 July 2013 at 22:58:56 UTC, Walter Bright wrote: On 7/31/2013 2:40 PM, Bill Baxter wrote: Are you serious that you can't fathom how it could be confusing to someone than talking about differences in run times? Yes. And no, I'm not talking about confusing to someone who lives in an undiscovered stone age tribe in the Amazon. I'm talking about computer programmers. If you say something is faster than something else you want the two numbers to be something you can relate to. Like MPH. Everyone has a clear concept of what MPH is. We use it every day. So to say 25 MPH is 25% faster than 20 MPH is perfectly clear. But nobody talks about program execution speed in terms of programs per second. Yes, they do, and certainly in lines per second. Google it and see for yourself. And as you well understand, from using the same program to compile, the number of lines cancels out when comparing speeds. There is nothing mysterious or confusing about this. Seriously. So I think it's pretty clear why that would be harder for people to grok than changes in car speeds or run times. To be blunt, Baloney! Can we please stop this dumb argument? I think the source of the confusion is that programmers only use execution times to measure execution speed and will often say that they sped up a program by 50% when they halved the execution time, implying that the speed went up by 50%. Well, as Walter points out, a real speed, ie output/sec, would go up 100% in that scenario, so the programmers' language is technically incorrect. This breaks many programmers' intuitions, hence all the complaining in this thread. However, this whole debate is a bikeshed topic, as nobody really cares if the gain was 43% or 75%, ie nobody is using that precision for any purpose anyway. Walter is technically correct, that's all that matters. On Wednesday, 31 July 2013 at 23:26:32 UTC, Walter Bright wrote: On 7/31/2013 3:58 PM, John Colvin wrote: It's a quite impressively unbalanced education that provides understanding of memory allocation strategies, hashing and the performance pitfalls of integer division, but not something as basic as a speed. Have you ever seen those cards that some electrical engineers carry around, with the following equations on them: V = I * R R = V / I I = V / R ? I found it: https://docs.google.com/drawings/d/1StlhTYjiUEljnfVtFjP1BXLbixO30DIkbw-DpaYJoA0/edit?hl=enpli=1 Unbelievable. The author of it writes: I'm going to explain to you how to use this cheat sheet in case you've never seen this before. http://blog.ricardoarturocabral.com/2010/07/electronic-electrical-cheat-sheets.html Makes you want to cry. No real electrical engineer would ever use that card, as you connote with your quotes. If they don't have Ohm's law and the resulting algebra drilled into their head, they better find another job. I suspect that chart is for amateurs from other backgrounds who happen to be doing some electrical work.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Thursday, 1 August 2013 at 07:47:25 UTC, Joakim wrote: On Wednesday, 31 July 2013 at 22:58:56 UTC, Walter Bright wrote: Have you ever seen those cards that some electrical engineers carry around, with the following equations on them: V = I * R R = V / I I = V / R ? I found it: https://docs.google.com/drawings/d/1StlhTYjiUEljnfVtFjP1BXLbixO30DIkbw-DpaYJoA0/edit?hl=enpli=1 Unbelievable. The author of it writes: I'm going to explain to you how to use this cheat sheet in case you've never seen this before. http://blog.ricardoarturocabral.com/2010/07/electronic-electrical-cheat-sheets.html Makes you want to cry. No real electrical engineer would ever use that card, as you connote with your quotes. If they don't have Ohm's law and the resulting algebra drilled into their head, they better find another job. I suspect that chart is for amateurs from other backgrounds who happen to be doing some electrical work. Screw engineers, *anybody* who doesn't know these laws shouldn't be allowed anywhere *near* electricity :D
Re: Emacs D Mode version 2.0.6 released
Hi Russel, I'm not proposing my changes to be merged into master because I know they are merely workarounds rather than proper fixes (eg. font-lock-add-keywords). On Thursday, 1 August 2013 at 08:07:28 UTC, Russel Winder wrote: The way to progress this is for you to to clone the GitHub repository on GitHub, clone it locally to your machines, create a feature branch with your proposed changes, push them to your GitHub clone and then submit a pull request via GitHub. I and others can then try things out and see if the pull request can be merged into master. The one thing that still worries me about all the E-Lisp stuff – no unit tests :-( Thanks.
Re: DScanner is ready for use
okay, I look forward to its release. I'm really looking forward to code completion in Sublime Text 2 On Wed, Jul 31, 2013 at 10:44 PM, Brian Schott briancsch...@gmail.comwrote: On Wednesday, 31 July 2013 at 18:41:17 UTC, Justin Whear wrote: On Wed, 31 Jul 2013 20:30:17 +0200, Rory McGuire wrote: Any chance of you turning this into a daemon? Something likt margo or gocode? The author has another project here: https://github.com/**Hackerpilot/DCDhttps://github.com/Hackerpilot/DCD I wouldn't bother trying to use that yet. Maybe next week, but not now. When I get it working there will be a thread on D.announce.
Re: New Russian site about D Programming Language
On Friday, 24 May 2013 at 06:30:32 UTC, Suliman wrote: Huge update. Replaced terrible bb-code editor. Old one was really buggy. added Mozilla Persona integration and a lot of other improves! -- http://dlang.ru Else another update. Added colorized bb-code, Latest answer box, and a lot of other functionality. Site have still few issues that will be fixed in nearest time.
Re: New Russian site about D Programming Language
Would it be possible to create block communities on dlang.org site and put there links to national language communities?
Re: Emacs D Mode version 2.0.6 released
On Thu, 2013-08-01 at 16:32 +0200, finalpatch wrote: Hi Russel, I'm not proposing my changes to be merged into master because I know they are merely workarounds rather than proper fixes (eg. font-lock-add-keywords). Development on this is event driven. Having an event of a hack fix, may lead to investigation and thence a proper fix! Basically it would be good to see something that solves the problem as input to trying to find the proper solution. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
dmc 8.57 now available for download
http://www.digitalmars.com/download/freecompiler.html Using it to compile dmd for win32 will result in a faster dmd.
Re: dmc 8.57 now available for download
Walter Bright: http://www.digitalmars.com/download/freecompiler.html Using it to compile dmd for win32 will result in a faster dmd. Thank you, I'll try it soon. A faster compilation of dmd, or a faster running dmd, or both? :-) Bye, bearophile
Re: dmc 8.57 now available for download
On 8/1/2013 4:05 PM, bearophile wrote: Thank you, I'll try it soon. A faster compilation of dmd, or a faster running dmd, or both? :-) Better code gen does both!
Re: dmc 8.57 now available for download
Walter Bright: Better code gen does both! Good. I have tried to compile dmd, and it doesn't work: ...make -f win32.mak release make -fwin32.mak C=backend TK=tk ROOT=root clean del *.obj del total.sym del msgs.h msgs.c del elxxx.c cdxxx.c optab.c debtab.c fltables.c tytab.c del impcnvtab.c del id.h id.c del verstr.h make -fwin32.mak C=backend TK=tk ROOT=root reldmd make -fwin32.mak C=backend TK=tk ROOT=root OPT=-o DEBUG= LFLAGS=-L/delexe dmd.exe dmc -cpp -DDM_TARGET_CPU_X86=1 idgen Compiling for C++ source = 'idgen.c' obj = 'idgen.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' link idgen,,,user32+kernel32/noi; idgen echo 2.064 verstr.h dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 mars -Ae Compiling for C++ source = 'mars.c' obj = 'mars.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 enum Compiling for C++ source = 'enum.c' obj = 'enum.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 struct Compiling for C++ source = 'struct.c' obj = 'struct.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 dsymbol Compiling for C++ source = 'dsymbol.c' obj = 'dsymbol.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 import Compiling for C++ source = 'import.c' obj = 'import.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 id Compiling for C++ source = 'id.c' obj = 'id.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 staticassert Compiling for C++ source = 'staticassert.c' obj = 'staticassert.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 identifier Compiling for C++ source = 'identifier.c' obj = 'identifier.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' dmc -c -Iroot;\dm\include -o -cpp -DDM_TARGET_CPU_X86=1 mtype Compiling for C++ source = 'mtype.c' obj = 'mtype.obj' dep = '(null)' lst = '(null)' sym = '(null)' tdb = 'symc.tdb' nbytes = 80031, ph_maxsize = 65520 Internal error: ph.c 1854 --- errorlevel -1073741510 Bye, bearophile
Re: dmc 8.57 now available for download
On 8/1/2013 5:56 PM, Walter Bright wrote: On 8/1/2013 5:50 PM, bearophile wrote: Walter Bright: Better code gen does both! Good. I have tried to compile dmd, and it doesn't work: Oh crud, I copied the wrong files. Fixed.
Re: dmc 8.57 now available for download
Walter Bright: Fixed. Do you mean that if I download the dmc zip again it will work? Bye, bearophile
Re: dmc 8.57 now available for download
On 8/1/2013 6:22 PM, bearophile wrote: Walter Bright: Fixed. Do you mean that if I download the dmc zip again it will work? Yes, unless I screwed it up again.
Re: DScanner is ready for use
On Sun, 28 Jul 2013 00:27:34 +0200 Brian Schott briancsch...@gmail.com wrote: DScanner is a tool for analyzing D source code. [...] When I try to compile it (DMD 2.063.2 Win32) I get this: C:\Users\Nick\AppData\Roaming\dvm\compilers\dmd-2.063.2\bin\..\src\phobos\std\array.d(321): Error: function core.memory.GC.malloc (uint sz, uint ba = 0u) is not callable using argument types (ulong, BlkAttr) C:\Users\Nick\AppData\Roaming\dvm\compilers\dmd-2.063.2\bin\..\src\phobos\std\array.d(272): Error: template instance std.array.arrayAllocImpl!(false, ubyte[], ulong) error instantiating main.d(77):instantiated from here: uninitializedArray!(ubyte[], ulong) main.d(77): Error: template instance std.array.uninitializedArray!(ubyte[], ulong) error instantiating
Re: DScanner is ready for use
On Thu, 1 Aug 2013 21:52:00 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Sun, 28 Jul 2013 00:27:34 +0200 Brian Schott briancsch...@gmail.com wrote: DScanner is a tool for analyzing D source code. [...] When I try to compile it (DMD 2.063.2 Win32) I get this: C:\Users\Nick\AppData\Roaming\dvm\compilers\dmd-2.063.2\bin\..\src\phobos\std\array.d(321): Error: function core.memory.GC.malloc (uint sz, uint ba = 0u) is not callable using argument types (ulong, BlkAttr) C:\Users\Nick\AppData\Roaming\dvm\compilers\dmd-2.063.2\bin\..\src\phobos\std\array.d(272): Error: template instance std.array.arrayAllocImpl!(false, ubyte[], ulong) error instantiating main.d(77):instantiated from here: uninitializedArray!(ubyte[], ulong) main.d(77): Error: template instance std.array.uninitializedArray!(ubyte[], ulong) error instantiating Actually, I dug into this more (it was problem on 32-bit) and made a pull request: https://github.com/Hackerpilot/Dscanner/pull/42
