Re: dmd codegen improvements
Iain Buclaw via Digitalmars-dwrote: > On 5 Sep 2015 11:25 pm, "Walter Bright via Digitalmars-d" < > digitalmars-d@puremagic.com> wrote: >> >> On 9/5/2015 5:54 AM, Adam D. Ruppe wrote: >>> >>> On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote: And your post did it too. If you're using the Thunderbird news reader, typing Cntl-U will show > the full source of the message. >>> >>> >>> This is perfectly normal for emails and such. They are > multipart/alternative >>> MIME messages which pack different versions of the same message together > and >>> your client picks its preferred one to show you. >>> >>> It is kinda useless because the html version adds zero value, but the > text >>> version is still there to so your client should just ignore it. >> >> >> I know, and my client does, but given the size of the n.g. message > database, doubling its size for no added value makes it slower. > > There's no way to change the Gmail client behaviour. And I'm assuming that > it isn't a recent feature either. Considering the messy quoting in your posts I'd actually prefer HTML messages.
Re: dmd codegen improvements
On Wednesday, 16 September 2015 at 20:44:00 UTC, Walter Bright wrote: On 9/16/2015 7:16 AM, Bruno Medeiros wrote: On 28/08/2015 22:59, Walter Bright wrote: People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. So your whole career is fundamentally based not on bringing value to the software world, but rather merely proving people wrong? That amounts to living your professional life in thrall of other people's validation, and it's not commendable at all. It's a waste of your potential. It is only worthwhile to prove people wrong when it brings you a considerable amount of either monetary resources or clout - and more so than you would have got doing something else with your time. It's not clear to me that was always the case throughout your career... was it? Wow, such an interpretation never occurred to me. I will reiterate that I worked on things that I believed had value and nobody else did. I.e. I did not need validation from others. Yeah, I was a bit stunned that that is what Bruno took from your post. I don't think anybody would question that writing a C or C++ compiler in the '80s and '90s had value, and I'm sure you did pretty well off them, considering you retired at 42 (http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322). Your point is that nobody thought _you_ or you _alone_ could do these valuable things, and you repeatedly proved them wrong. Those doubting you in this thread, about improving the dmd backend so it's competitive with llvm/gcc while still having time to work on the frontend, may or may not turn out to be right, but you certainly seem to have a good track record at proving such doubters wrong.
Re: dmd codegen improvements
On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros wrote: And on this aspect I think the development of D does very poorly. Often people clamored for a feature or change (whether people in the D community, or the C++ one), and Walter you went ahead and did it, regardless of whether it will actually increase D usage in the long run. You are prone to this, given your nature to please people who ask for things, or to prove people wrong (as you yourself admitted). I apologize for not remembering any example at the moment, but I know there was quite a few, especially many years back. It usually went like this: C++ community guy: "D is crap, it's not gonna be used without X" *some time later* Walter: "Ok, I've now implemented X in D!" the same C++ community guy: either finds another feature or change to complain about (repeat), or goes silent, or goes "meh, D is still not good" Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"... I find this assessment inaccurate. In my own experience, I have come to see Walter as Dr. No (in a good sense!) in that he has said no to a great many feature requests over the years. The instances where a feature was implemented that took the community by surprise have been rare indeed. And even then, we are not privy to the support requests and other discussions that Walter has with the businesses using D. I'm confident that what goes on in his head when deciding to pursue a change or enhancement has little to do with willy-nilly complaints by C++ users.
Re: dmd codegen improvements
On 17/09/2015 08:10, Joakim wrote: Yeah, I was a bit stunned that that is what Bruno took from your post. I don't think anybody would question that writing a C or C++ compiler in the '80s and '90s had value, and I'm sure you did pretty well off them, considering you retired at 42 (http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322). I didn't say that Walter's previous work didn't bring *any* value to the software world. It's not like people challenged him to write efficient lolcode or brainfuck(*) compilers, or some other silly challenge, which if he did would have a been a massive waste of time - even if it was technically a very admirable feat. (*) - Yeah those languages weren't around at the time, but that's just an example. My point was that one would certainly bring *more* value to the software world, if that is the primary focus of one's career, instead of merely proving people wrong. That doesn't mean either one has to be an emotionless robot that never does something just for the sake of ego-boosting (which is really the only reward of proving people wrong - unless there are some monetary or other resources at stake). But Walter has so many stories of "I did this [massive project] to prove people wrong." which is what makes me wonder if there isn't too much focus on ego validation. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd codegen improvements
On 17/09/2015 09:06, Mike Parker wrote: On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros wrote: And on this aspect I think the development of D does very poorly. Often people clamored for a feature or change (whether people in the D community, or the C++ one), and Walter you went ahead and did it, regardless of whether it will actually increase D usage in the long run. You are prone to this, given your nature to please people who ask for things, or to prove people wrong (as you yourself admitted). I apologize for not remembering any example at the moment, but I know there was quite a few, especially many years back. It usually went like this: C++ community guy: "D is crap, it's not gonna be used without X" *some time later* Walter: "Ok, I've now implemented X in D!" the same C++ community guy: either finds another feature or change to complain about (repeat), or goes silent, or goes "meh, D is still not good" Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"... I find this assessment inaccurate. In my own experience, I have come to see Walter as Dr. No (in a good sense!) in that he has said no to a great many feature requests over the years. The instances where a feature was implemented that took the community by surprise have been rare indeed. And even then, we are not privy to the support requests and other discussions that Walter has with the businesses using D. I'm confident that what goes on in his head when deciding to pursue a change or enhancement has little to do with willy-nilly complaints by C++ users. Dr. No for the D community. If someone from D community said "D won't succeed without X", or "D can't be made to work without X", that wouldn't have much clout with Walter. (unless that someone is behind a company using D commercially, or considering so) But if people from the C++ community said it, OMG, then Walter goes "let's add it to D!", just to prove a point or something. *Mind you*: all this I'm saying is pre TDPL book stuff. After the book was out, things stabilized. But way back, even more so before D2, it would happen quite often. Again apologies for no references or examples, but this is all stuff from 4-7 years ago so it's hard to remember exact cases. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd codegen improvements
On 17/09/2015 12:57, Bruno Medeiros wrote: But if people from the C++ community said it, OMG, then Walter goes "let's add it to D!", just to prove a point or something. *Mind you*: all this I'm saying is pre TDPL book stuff. After the book was out, things stabilized. But way back, even more so before D2, it would happen quite often. Again apologies for no references or examples, but this is all stuff from 4-7 years ago so it's hard to remember exact cases. I do remember though, that the turning point for this was when Andrei joined the D team. Before that it was more or less like this: Walter was the master compiler writer, wohoo, and if someone challenged him to add a feature, it went in. In most cases maybe Walter wasn't challenged directly, but someone in the C++ community would say "Ha, wouldn't it be great if C++ had X!", and then if D didn't had X already, it would get added, so Walter would go "Oh, you know what, D has X!!" Little consideration was given to whether X was worthwhile or not in the big picture. After Andrei came on board, things improved and became more like: Andrei: "Hold on, first let's see if the use case for X is actually a real world need or not. If it is, let's see if it is not satisfactory to use existing D language features to solve that use case. And if it's not, only then we'll consider adding it. But even so let's try to add X in a more generic way, so that it easier to implement and/or so that it could solve other use cases as well." -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd codegen improvements
Template metaprogramming is probably the only notable feature borrowed from C++ (more like a redesign?), the rest looks more like borrowed from Java. This actually turns C++ programmers away when they see so many things are done differently from C++.
Re: dmd codegen improvements
On Thursday, 17 September 2015 at 11:57:29 UTC, Bruno Medeiros wrote: *Mind you*: all this I'm saying is pre TDPL book stuff. After the book was out, things stabilized. Can I speak for the people who only became familiar with D after TDPL and say I don't really care about what you're talking about?
Re: dmd codegen improvements
On Thursday, 17 September 2015 at 11:47:36 UTC, Bruno Medeiros wrote: On 17/09/2015 08:10, Joakim wrote: Yeah, I was a bit stunned that that is what Bruno took from your post. I don't think anybody would question that writing a C or C++ compiler in the '80s and '90s had value, and I'm sure you did pretty well off them, considering you retired at 42 (http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322). I didn't say that Walter's previous work didn't bring *any* value to the software world. It's not like people challenged him to write efficient lolcode or brainfuck(*) compilers, or some other silly challenge, which if he did would have a been a massive waste of time - even if it was technically a very admirable feat. (*) - Yeah those languages weren't around at the time, but that's just an example. My point was that one would certainly bring *more* value to the software world, if that is the primary focus of one's career, instead of merely proving people wrong. That doesn't mean either one has to be an emotionless robot that never does something just for the sake of ego-boosting (which is really the only reward of proving people wrong - unless there are some monetary or other resources at stake). But Walter has so many stories of "I did this [massive project] to prove people wrong." which is what makes me wonder if there isn't too much focus on ego validation. Human beings are funny creatures, and able people like to be stretched to the limit of what's possible. Having someone tell you there is no way you can do that is a hint that it's quite a difficult problem, and yet you may correctly perceive how it may be done. A highly talented person of this sort has many ways in which in theory they might add most value, but many fewer viable ways, because they find it harder than most to do what they don't want to do. (And creativity comes when you are following a path that is within you). Cattell and Eysenck wrote about this, and lately Professor Bruce Charlton at Iqpersonalitygenius blog. Plus, following what moves you may be a better guide than rational optimisation given that with the latter one is often fooling oneself since one doesn't even understand the structure of social calculus. I personally find Walter's attitude quite inspiring, although I am not familiar with the pre TDPL days and not so interested at this moment. At least you can say that he recognizes that management is difficult for him and did bring Andrei alongside, not something easy to do to yield total control.
Re: dmd codegen improvements
On 28/08/2015 22:59, Walter Bright wrote: People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. So your whole career is fundamentally based not on bringing value to the software world, but rather merely proving people wrong? That amounts to living your professional life in thrall of other people's validation, and it's not commendable at all. It's a waste of your potential. It is only worthwhile to prove people wrong when it brings you a considerable amount of either monetary resources or clout - and more so than you would have got doing something else with your time. It's not clear to me that was always the case throughout your career... was it? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd codegen improvements
On 02/09/2015 19:58, Walter Bright wrote: On 8/29/2015 12:37 PM, Laeeth Isharc wrote: In my experience you can deliver everything people say they want, and then find it isn't that at all. That's so true. My favorite anecdote on that was back in the 1990's. A friend of mine said that what he and the world really needs was a Java native compiler. It'd be worth a fortune! I told him that I had that idea a while back, and had implemented one for Symantec. I could get him a copy that day. He changed the subject. I have many, many similar stories. I also have many complementary stories - implementing things that people laugh at me for doing, that turn out to be crucial. We can start with the laundry list of D features that C++ is rushing to adopt :-) Yes, and this I think is demonstrative of a very important consideration: if someone says they want X (and they are not paying upfront for it), then it is crucial for *you* to be able to figure out if that person or group actually wants X or not. If someone spends time building a product or feature that turns out people don't want... the failure is on that someone. And on this aspect I think the development of D does very poorly. Often people clamored for a feature or change (whether people in the D community, or the C++ one), and Walter you went ahead and did it, regardless of whether it will actually increase D usage in the long run. You are prone to this, given your nature to please people who ask for things, or to prove people wrong (as you yourself admitted). I apologize for not remembering any example at the moment, but I know there was quite a few, especially many years back. It usually went like this: C++ community guy: "D is crap, it's not gonna be used without X" *some time later* Walter: "Ok, I've now implemented X in D!" the same C++ community guy: either finds another feature or change to complain about (repeat), or goes silent, or goes "meh, D is still not good" Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"... -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd codegen improvements
On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros wrote: Me and other people from D community: "ok... now we have a new half-baked functionality in D, adding complexity for little value, and put here only to please people that are extremely unlikely to ever be using D whatever any case"... D is fun for prototyping ideas, so yes half-baked and not stable, but still useful. I'm waiting for Rust to head down the same lane of adding features and obfuscating the syntax (and their starting point is even more complex than D's was)...
Re: dmd codegen improvements
On 9/16/2015 7:16 AM, Bruno Medeiros wrote: On 28/08/2015 22:59, Walter Bright wrote: People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. So your whole career is fundamentally based not on bringing value to the software world, but rather merely proving people wrong? That amounts to living your professional life in thrall of other people's validation, and it's not commendable at all. It's a waste of your potential. It is only worthwhile to prove people wrong when it brings you a considerable amount of either monetary resources or clout - and more so than you would have got doing something else with your time. It's not clear to me that was always the case throughout your career... was it? Wow, such an interpretation never occurred to me. I will reiterate that I worked on things that I believed had value and nobody else did. I.e. I did not need validation from others.
Re: dmd codegen improvements
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote: Martin ran some benchmarks recently that showed that ddmd compiled with dmd was about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical. I'm interested in ways to reduce that gap. There are 3 broad kinds of optimizations that compilers do: 1. source translations like rewriting x*2 into x<<1, and function inlining 2. instruction selection patterns like should one generate: SETC AL MOVZ EAX,AL or: SBB EAX NEG EAX 3. data flow analysis optimizations like constant propagation, dead code elimination, register allocation, loop invariants, etc. Modern compilers (including dmd) do all three. So if you're comparing code generated by dmd/gdc/ldc, and notice something that dmd could do better at (1, 2 or 3), please let me know. Often this sort of thing is low hanging fruit that is fairly easily inserted into the back end. For example, recently I improved the usage of the SETcc instructions. https://github.com/D-Programming-Language/dmd/pull/4901 https://github.com/D-Programming-Language/dmd/pull/4904 A while back I improved usage of BT instructions, the way switch statements were implemented, and fixed integer divide by a constant with multiply by its reciprocal. Maybe the ENTER instruction should be replaced by a full prologue: - https://github.com/D-Programming-Language/dmd/blob/ef24f9acd99aa52ed28e7221cb0997099ab85f4a/src/backend/cod3.c#L2939 - http://stackoverflow.com/questions/5959890/enter-vs-push-ebp-mov-ebp-esp-sub-esp-imm-and-leave-vs-mov-esp-ebp It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER.
Re: dmd codegen improvements
On Sunday, 13 September 2015 at 17:30:12 UTC, BBasile wrote: It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER. Same here, I thought nobody used this one instruction.
Re: dmd codegen improvements
On 09/13/2015 07:30 PM, BBasile wrote: > It seems that since the Pentium I, ENTER is always slower. But i don't > know if it's used as a kind of optimization for the binary size. > Actually before using DMD I had **never** seen an ENTER. https://github.com/D-Programming-Language/dmd/pull/5073
Re: dmd codegen improvements
On Sunday, 13 September 2015 at 18:33:52 UTC, Martin Nowak wrote: On 09/13/2015 07:30 PM, BBasile wrote: It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER. https://github.com/D-Programming-Language/dmd/pull/5073 Yeah, that was fast. With the hope it'll be approved.
Re: dmd codegen improvements
On 09/13/2015 08:45 PM, BBasile wrote: > Yeah, that was fast. With the hope it'll be approved. If only it wasn't for me to do this...
Re: dmd codegen improvements
On 9/6/2015 4:39 PM, Manu via Digitalmars-d wrote: It didn't happen for me because I changed my gmail settings after Walter requested some time back to only include plain text. My NG experience is much less enjoyable as a result of the change; I prefer the blue quote line, but now I just have a sea of '>' characters after turning it off. I preferred it before I changed my settings, but apparently I am invisible spamming. It is doing the right thing now, yay! :-) BTW, Thunderbird's n.g. reader will transform the > into the blue line.
Re: dmd codegen improvements
On 2015-09-06 15:24, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=wrote: Oh, actually it appears to run on both OS-X and Linux. I didn't know that. Looks very promising, thanks! Yeah, it's built on the same framework as Atom. Or were you hoping for Visual Studio, sans Code, on OS X and Linux? -- /Jacob Carlborg
Re: dmd codegen improvements
On Monday, 7 September 2015 at 13:41:31 UTC, Jacob Carlborg wrote: On 2015-09-06 15:24, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=wrote: Oh, actually it appears to run on both OS-X and Linux. I didn't know that. Looks very promising, thanks! Yeah, it's built on the same framework as Atom. Or were you hoping for Visual Studio, sans Code, on OS X and Linux? I knew there was an Atom based type script editor (or several?), but didn't know that Microsoft was behind it and that "VS Code" was different from "VS"/"VS Express" ;). Typescript seems to have a lot of momentum. I'm thinking about the possibility of a transpiler TypeScript->D (and other languages).
Re: dmd codegen improvements
On 6 September 2015 at 18:57, Jacob Carlborg via Digitalmars-dwrote: > On 2015-09-06 02:54, Walter Bright wrote: > >> It probably is a rampant problem. I notice it with you because >> Thunderbird gives a line count for a message, and yours are usually in >> the hundreds of lines while others are like 10 to 20. > > > Usually Thunderbird highlights the quoted part in blue and makes the '<' > characters in to a solid line. I've noticed that for some messages that > don't happen, recently for Iain's messages, but not for Manu's. It didn't happen for me because I changed my gmail settings after Walter requested some time back to only include plain text. My NG experience is much less enjoyable as a result of the change; I prefer the blue quote line, but now I just have a sea of '>' characters after turning it off. I preferred it before I changed my settings, but apparently I am invisible spamming.
Re: dmd codegen improvements
On 5 Sep 2015 11:25 pm, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On 9/5/2015 5:54 AM, Adam D. Ruppe wrote: >> >> On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote: >>> >>> And your post did it too. >>> >>> If you're using the Thunderbird news reader, typing Cntl-U will show the full >>> source of the message. >> >> >> This is perfectly normal for emails and such. They are multipart/alternative >> MIME messages which pack different versions of the same message together and >> your client picks its preferred one to show you. >> >> It is kinda useless because the html version adds zero value, but the text >> version is still there to so your client should just ignore it. > > > I know, and my client does, but given the size of the n.g. message database, doubling its size for no added value makes it slower. There's no way to change the Gmail client behaviour. And I'm assuming that it isn't a recent feature either.
Re: dmd codegen improvements
On 2015-09-06 02:54, Walter Bright wrote: It probably is a rampant problem. I notice it with you because Thunderbird gives a line count for a message, and yours are usually in the hundreds of lines while others are like 10 to 20. Usually Thunderbird highlights the quoted part in blue and makes the '<' characters in to a solid line. I've noticed that for some messages that don't happen, recently for Iain's messages, but not for Manu's. -- /Jacob Carlborg
Re: dmd codegen improvements
On Sunday, 6 September 2015 at 12:31:27 UTC, Kagamin wrote: On Saturday, 5 September 2015 at 14:57:58 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:44:46 UTC, Jacob Carlborg wrote: I heard the TypeScript support for Visual Studio Code is really good. I'm crossing my fingers for an OS-X or Linux version of VS. ;) You mean Visual Studio Code doesn't run on Linux? Oh, actually it appears to run on both OS-X and Linux. I didn't know that. Looks very promising, thanks!
Re: dmd codegen improvements
On Saturday, 5 September 2015 at 14:57:58 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:44:46 UTC, Jacob Carlborg wrote: I heard the TypeScript support for Visual Studio Code is really good. I'm crossing my fingers for an OS-X or Linux version of VS. ;) You mean Visual Studio Code doesn't run on Linux?
Re: dmd codegen improvements
On Friday, 4 September 2015 at 15:45:35 UTC, Luís Marques wrote: On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad wrote: Actually, browsers are deprecating NPAPI plugins. Flash is so dead… Could, in principle, Flash be supported through an extension, instead of a media / NPAPI plugin? Btw, come across this flash emulator, in case you are interested: https://github.com/mozilla/shumway
Re: dmd codegen improvements
On 5 Sep 2015 6:31 am, "Manu via Digitalmars-d"wrote: > > On 5 September 2015 at 14:14, Walter Bright via Digitalmars-d > wrote: > > On 9/4/2015 7:52 AM, Manu via Digitalmars-d wrote: > >> > >> [...] > > > > > > Sadly, your newsgroup software is back to doing double posts - once in > > plaintext, once in html. > > My software in this case was the mail client on Android. > I'm astonished this isn't a rampant problem; mail clients seem to do > this by default. I have not configured it in any special way, not > changed a single setting... this is default settings for the worlds > most popular mail client (gmail). > How can I possibly be the only offender here? That is a good question (this is a reply from Android Gmail).
Re: dmd codegen improvements
On 9/5/2015 1:00 AM, Iain Buclaw via Digitalmars-d wrote: On 5 Sep 2015 6:31 am, "Manu via Digitalmars-d"> wrote: > > On 5 September 2015 at 14:14, Walter Bright via Digitalmars-d > > wrote: > > On 9/4/2015 7:52 AM, Manu via Digitalmars-d wrote: > >> > >> [...] > > > > > > Sadly, your newsgroup software is back to doing double posts - once in > > plaintext, once in html. > > My software in this case was the mail client on Android. > I'm astonished this isn't a rampant problem; mail clients seem to do > this by default. I have not configured it in any special way, not > changed a single setting... this is default settings for the worlds > most popular mail client (gmail). > How can I possibly be the only offender here? That is a good question (this is a reply from Android Gmail). And your post did it too. If you're using the Thunderbird news reader, typing Cntl-U will show the full source of the message.
Re: dmd codegen improvements
On 18-Aug-2015 13:45, Walter Bright wrote: Martin ran some benchmarks recently that showed that ddmd compiled with dmd was about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical. I'm interested in ways to reduce that gap. .. 2. instruction selection patterns like should one generate: SETC AL MOVZ EAX,AL or: SBB EAX NEG EAX See section "Problematic instructions" here: http://www.agner.org/optimize/optimizing_assembly.pdf And some invaluable material on each CPU specifics for all x86 from Pentium to Haswell and AMD from K6 toBuldozer: http://www.agner.org/optimize/microarchitecture.pdf Hope this helps. -- Dmitry Olshansky
Re: dmd codegen improvements
On 9/5/2015 5:54 AM, Adam D. Ruppe wrote: On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote: And your post did it too. If you're using the Thunderbird news reader, typing Cntl-U will show the full source of the message. This is perfectly normal for emails and such. They are multipart/alternative MIME messages which pack different versions of the same message together and your client picks its preferred one to show you. It is kinda useless because the html version adds zero value, but the text version is still there to so your client should just ignore it. I know, and my client does, but given the size of the n.g. message database, doubling its size for no added value makes it slower.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:25:11 UTC, rsw0x wrote: I believe the FOSS version of Intellij can install the Javascript plugin which also adds support for Typescript. May be wrong. Hm. I bought WebStorm to do Dart, but have kinda put Dart on hold, so maybe not a bad idea. I assume it would then work with PyCharm CE. On Friday, 4 September 2015 at 14:44:46 UTC, Jacob Carlborg wrote: I heard the TypeScript support for Visual Studio Code is really good. I'm crossing my fingers for an OS-X or Linux version of VS. ;)
Re: dmd codegen improvements
On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote: And your post did it too. If you're using the Thunderbird news reader, typing Cntl-U will show the full source of the message. This is perfectly normal for emails and such. They are multipart/alternative MIME messages which pack different versions of the same message together and your client picks its preferred one to show you. It is kinda useless because the html version adds zero value, but the text version is still there to so your client should just ignore it.
Re: dmd codegen improvements
On 9/5/2015 4:32 PM, Manu via Digitalmars-d wrote: Perhaps the NG server should make an effort to trim the wanted message content then? I'd rather work with NNTP as it is. I'm still astonished I'm the only one that uses Gmail... this should be a rampant problem. It probably is a rampant problem. I notice it with you because Thunderbird gives a line count for a message, and yours are usually in the hundreds of lines while others are like 10 to 20. Your last one was 109 lines long, although you only wrote 1 original line of text. It also isn't helpful to include a quote of the whole previous message - just what you are specifically replying to.
Re: dmd codegen improvements
On 6 September 2015 at 07:20, Walter Bright via Digitalmars-dwrote: > On 9/5/2015 5:54 AM, Adam D. Ruppe wrote: >> >> On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote: >>> >>> And your post did it too. >>> >>> If you're using the Thunderbird news reader, typing Cntl-U will show the >>> full >>> source of the message. >> >> >> This is perfectly normal for emails and such. They are >> multipart/alternative >> MIME messages which pack different versions of the same message together >> and >> your client picks its preferred one to show you. >> >> It is kinda useless because the html version adds zero value, but the text >> version is still there to so your client should just ignore it. > > > I know, and my client does, but given the size of the n.g. message database, > doubling its size for no added value makes it slower. Perhaps the NG server should make an effort to trim the wanted message content then? I'm still astonished I'm the only one that uses Gmail... this should be a rampant problem.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 13:39:45 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim Grøstad wrote: I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications. Err... avoid WebStorm. Just noticed JetBrains have decided to rip off their customers with a subscription model and increase their pricing 100%. Damn, I'm going back to OpenSource IDEs… I believe the FOSS version of Intellij can install the Javascript plugin which also adds support for Typescript. May be wrong.
Re: dmd codegen improvements
On 2015-09-04 15:39, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=wrote: Err... avoid WebStorm. Just noticed JetBrains have decided to rip off their customers with a subscription model and increase their pricing 100%. Damn, I'm going back to OpenSource IDEs… I heard the TypeScript support for Visual Studio Code is really good. -- /Jacob Carlborg
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim Grostad wrote: On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote: On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: [...] It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet. SIMD is not even remotely close to explaining the perf difference. What browser? Only FF supports it. Chrome just JIT it IIRC. asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically. The gap is way to big for vectorization to be a reasonable explanation. In fact a large body of code just do not vectorize at all. You seems to be fixated on that vectorization thing, when it is not even remotely close to the problem at hand. All of this could have been avoided by all browser vendors agreeing to implement pNaCl. Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. No. TurboFan is in Chrome with asm.js support.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim Grøstad wrote: I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications. Err... avoid WebStorm. Just noticed JetBrains have decided to rip off their customers with a subscription model and increase their pricing 100%. Damn, I'm going back to OpenSource IDEs…
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. No. TurboFan is in Chrome with asm.js support. I'd rather not advocate the adoption of inferior technology.
Re: dmd codegen improvements
On 5 Sep 2015 12:32 am, "rsw0x via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote: >> >> On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim Grostad wrote: >>> >>> On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote: > > On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: >> >> [...] > > > It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet. SIMD is not even remotely close to explaining the perf difference. >>> >>> >>> What browser? Only FF supports it. Chrome just JIT it IIRC. >> >> >> asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically. >> >> The gap is way to big for vectorization to be a reasonable explanation. In fact a large body of code just do not vectorize at all. >> >> You seems to be fixated on that vectorization thing, when it is not even remotely close to the problem at hand. > > > All of this could have been avoided by all browser vendors agreeing to implement pNaCl. > Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. What I don't get is, Firefox and ie support plugins... Why isn't there a pnacl plugin for other browsers? Surely it could be added with the existing plugin interfaces?
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote: On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. No. TurboFan is in Chrome with asm.js support. I'd rather not advocate the adoption of inferior technology. It has already been adopted by Microsoft, Google and Mozilla...
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 01:54:45 UTC, Laeeth Isharc wrote: On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote: It's been mentioned before that there really isn't much point in using C when you can use D. Even if you completely avoid the GC and the standard library, you're _still_ ahead of where you'd be with C, and you can call C functions trivially. So, you can definitely use D as a better C; you just lose out on a lot of cool stuff that D has to offer beyond that. But D has a lot to offer over C even without using any of that stuff. One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's features (heck, D2 was quite young at that point, and I don't think that ranges had been introduced to Phobos yet at that point, so the standard library was seriously lacking anyway), but it was still easier to use D. - Jonathan M Davis worthy of a quick blogpost sometime? Laeeth. My memory would be pretty sketchy on it at this point. I remember what the project was (it had to do with randomly generating 3D fractals in opengl for a graphics course), but that was back in 2008, I think, and I couldn't really say much interesting about it beyond the fact that I was annoyed enough with C++ at the time to use D for the project. The only thing notable about it is that it was the first thing that I did in D that was actually supposed to do something rather than just messing around with the language. - Jonathan M Davis
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:53:06 UTC, Manu wrote: On 5 Sep 2015 12:32 am, "rsw0x via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: [...] wrote: [...] Performance is a different issue since it does not provide SIMD yet. [...] run about 20% slower typically. [...] In fact a large body of code just do not vectorize at all. [...] remotely close to the problem at hand. [...] implement pNaCl. [...] they've been handling things lately. What I don't get is, Firefox and ie support plugins... Why isn't there a pnacl plugin for other browsers? Surely it could be added with the existing plugin interfaces? Mozilla flat out stated they have no intention of supporting pNaCl. I'm sure a third party could make a plugin to support it.
Re: dmd codegen improvements
On 09/02/2015 11:57 PM, Walter Bright wrote: On 9/2/2015 7:48 PM, Adam D. Ruppe wrote: but still i'm meh on the practical usefulness of such things. I guess if you target a canvas and run your code in it that makes more sense but my preferred style is a progressive enhancement webpage where you want to know the browser platform and work with it rather than around it. I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less. The premise here is that Javascript is a lock-in for code that can run in the browser. So to get D code to run in the browser you'd need to generate Javascript. This concern is orthogonal to relative capabilities of languages etc. -- Andrei
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:45:39 UTC, rsw0x wrote: Because it has the path of least resistance. It's still a poor technology that is just treating the symptoms. pnacl/pepper is not good either, they are both poor technologies. But vendors are moving in the same direction, which is important, and compilers are improving each release. What matters most is getting something that is 3x+ faster than javascript when you need it, cross browser. Fortunately, Apple seems to take is seriously too, which is important, iOS Safari is a critical platform.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad wrote: Actually, browsers are deprecating NPAPI plugins. Flash is so dead… Could, in principle, Flash be supported through an extension, instead of a media / NPAPI plugin?
Re: dmd codegen improvements
On 09/03/2015 02:54 AM, Walter Bright wrote: On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote: As Walter once said, "Be the change you wish to see." I think that was Andrei. But I do agree with it. I think it was Gandhi :o). -- Andrei
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:43:43 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote: On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. No. TurboFan is in Chrome with asm.js support. I'd rather not advocate the adoption of inferior technology. It has already been adopted by Microsoft, Google and Mozilla... Because it has the path of least resistance. It's still a poor technology that is just treating the symptoms.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:43:43 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote: On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. No. TurboFan is in Chrome with asm.js support. I'd rather not advocate the adoption of inferior technology. It has already been adopted by Microsoft, Google and Mozilla... Doesn't mean it is not inferior. In fact it is bad enough on its own so there is the whole WebAssembly things going on.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:22:17 UTC, Jonathan M Davis wrote: On Thursday, 3 September 2015 at 01:54:45 UTC, Laeeth Isharc wrote: On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote: One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's features (heck, D2 was quite young at that point, and I don't think that ranges had been introduced to Phobos yet at that point, so the standard library was seriously lacking anyway), but it was still easier to use D. - Jonathan M Davis worthy of a quick blogpost sometime? Laeeth. My memory would be pretty sketchy on it at this point. I remember what the project was (it had to do with randomly generating 3D fractals in opengl for a graphics course), but that was back in 2008, I think, and I couldn't really say much interesting about it beyond the fact that I was annoyed enough with C++ at the time to use D for the project. The only thing notable about it is that it was the first thing that I did in D that was actually supposed to do something rather than just messing around with the language. - Jonathan M Davis Tku for colour.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 17:05:41 UTC, deadalnix wrote: Statement do not makes arguements. pNaCl is portable, take only a 20% hit compared to pure native and is compact to send through the wire. You think pnacl is compact and compresses well? That's an unusual position. Both asm.js and pnacl fail to be ideal for various reasons. One is that you loose too much information if you go from a high level language to enable full target optimization. The "p" for portable is questionable. A BIG advantage with asm.js is that you can generate and compile it from code running in the browser, so you can choose your own transport format, run JITs in the browser etc. You could essentially create a (simple) D development environment in the browser. Anyway, what we think does not matter. What matters is what is supported by the least common denominator, which for many developers happen to be browsers on weak mobile ARM devices. Apple has no interest in undermining their Apps market, so… who knows where this will go. Let's hope they don't sabotage it.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote: "I don't have enough time to figure out all the ins-and-outs of the current compiler." "Unless you sell DMD, how about providing a definition of "customer"? If you don't pay attention to evaluations, then surely the competition will steal your thunder and you'll end up as Cobol; on a long tail in maintenance mode." Sometimes it's really worth putting energy into ensuring crisp definitions. This isn't one of those cases. Your own language is exploiting polysemy in an unstraightforward manner - mixing up different meanings to achieve a rhetorical effect. Quite clearly Walter+Andrei listen to what people say, but it doesn't thereby follow that they should listen to people who think D should go in a completely different direction based on a very theoretical view of things and who have no evident experience in writing a compiler used on a large scale, or in developing a language community. It's Business 101 that you shouldn't listen to what most people tell you, because whilst often well-meaning it's based on an understanding of things different from the practical situation one faces and that doesn't always understand what one is trying to achieve. It's hard to do that whilst not falling into the other extreme of not attending to the smallest signs from the right people when you should, but difficulty is in the nature of such endeavours. "Oh, I would love for D to follow the trajectory of C. C development can follow a near-waterfall development model: 1. specification-ratification-cycle 2. specification based gamma-beta-alpha production implementation 3. release 4. non-semantic improvements D is nowhere near C's conservative fully spec'ed ISO-standard-based process." Thank the Lord! I really don't see how anyone can seriously believe that this is an appropriate model for D for the foreseeable future. The essential reason for why it is an attractive language is that it was based on the genius (I mean this in the etymologically-rooted sense) of one, or a few minds and thereby is greatly superior to anything designed by a committee. Maybe at some stage this will be an appropriate process to establish, but I do note that even some of those involved in such processes would readily admit that waterfalls are evil, if necessary at that stage. Andrei talked about documentation and presentation a little while back, and we're now in a much better state. Allocators soon here. > People have got D to run on embedded systems with low > resources. " What people can do isn't really all that interesting. What is interesting is what you can do with little effort and better than the alternatives." This is why you come across as a bit academic and not always constructive. You suggested things weren't developing, and I pointed out that they are, and gave a few concrete examples of how. You then said that the first attempt wasn't perfect. But you know, as well as I, that it's in the nature of things that beginnings never are. It's really tough to be the first to do something (another reason I think you could be a little more respectful towards Walter), but every person that follows makes it some how easier. There's a slightly mysterious aspect to this, but nonetheless it's true. D is running on embedded systems, and it sounds like it was a pain because of the runtime but not because of any horrible flaw in the language that means it cannot be considered a systems language if you want it to be. I'd be really surprised if it doesn't become easier from here with time. I like the old-fashioned English virtue of being willing in a discussion to give credit where credit is due. I'd honestly bet that a little more effort to communicate the practical commercial benefits of D would make much more of a difference than this abstract stuff. But who am I to say. " I think you underestimate the expections people with a major in compsci or a significant amount of development experience have. They care about the actual qualities, not the presentation. Those are the CTOs you need to convince, not the CEOs." I shared a flat for some time with a pretty smart friend who studied computer science at Trinity, Cambridge (I didn't study computing). He wrote this - it wasn't a success businesswise, but that's not for technical reasons and timing had a lot to do with it: https://github.com/pythonanywhere/dirigible-spreadsheet And I have other friends with similar backgrounds, and I have hired and worked with developers, and I am not sure that in the enterprise world a computer science credential has any more incantatory standing than any other degree - and that's probably as it should be. My point wasn't that D needs to fool gullible people into adopting it, but rather the opposite. I always thought smart people should just be able to see what's obvious, but one sometimes has to learn the hard way that
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:56:48 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 September 2015 at 14:45:39 UTC, rsw0x wrote: Because it has the path of least resistance. It's still a poor technology that is just treating the symptoms. pnacl/pepper is not good either, they are both poor technologies. Statement do not makes arguements. pNaCl is portable, take only a 20% hit compared to pure native and is compact to send through the wire.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 18:27:14 UTC, Laeeth Isharc wrote: Sometimes it's really worth putting energy into ensuring crisp definitions. This isn't one of those cases. Your own language is exploiting polysemy in an unstraightforward manner - mixing up different meanings to achieve a rhetorical effect. Quite clearly Walter+Andrei listen to what people say, but it doesn't thereby follow that they should listen to people who think D should go in a completely different direction based on a very theoretical view of things and who have no evident experience in writing a compiler used on a large scale, or in developing a language community. Define your target before designing, that is the essence here. This is critical to gain wide adoption. D has been defined to be a cross platform system level progrmming language. That is what D should be evaluated as. "customer" is a nonsensical term that essentially means what? It's Business 101 that you shouldn't listen to what most people tell you, because whilst often well-meaning it's based on an understanding of things different from the practical situation one faces and that doesn't always understand what one is trying to achieve. Defining who your target is does communicate what you are trying to achieve! This is critical if you want to evaluate and drive the systems development process forward. You cannot fix the process if you don't know how you measure progress. Thank the Lord! I really don't see how anyone can seriously believe that this is an appropriate model for D for the foreseeable future. You compared D to C, not me. I know many appropriate system development models... process to establish, but I do note that even some of those involved in such processes would readily admit that waterfalls are evil, if necessary at that stage. You are taking this too far, all non-chatoic models have a design-implement-evaluate pattern in them that, the difference is in how the iterations go. A language specification is a critical work document that expose qualities of the language. Bypassing that affects quality. At this stage D needs a specification. This is why you come across as a bit academic and not always constructive. You suggested things weren't developing, I said that adding performance features during refactoring communicates a lack of direction. Macro level refactoring is needed and challemging snd takes leadership. nonetheless it's true. D is running on embedded systems, and it sounds like it was a pain because of the runtime but not because of any horrible flaw in the language that means it cannot be considered a systems language if you want it to be. It does not matter if it runs on embedded or not, unless your "customers" are defined as that market. Nobody serious about development cares if D runs on embedded if there are cheaper and more suitable alternatives. It only matters if you are the best alternative. Engineers don't look for the next-best solution. They look for the best. So to gain ground you need to define your key goals with your design. obvious from the inside simply isn't from the outside. CTOs are not gifted with some magic ability to see through appearances to the Platonic essences of things. They are human and have a tough job. So one needs to make an effort if they are to easily appreciate the value. There are so few system level programming languages that the landscspe is easy to grasp. People are waiting for mature solutions that are better than what they have... Marketing does not affect this. Focus and improved process does. "I am not calling D a toy language" "As it stands today both Rust and D falls into the category toy-languages." Make up your mind. I said "if D is a toy language". That is not calling it anything. But it is, like Rust, a toy language by academic use of the phrase which is not a pejorative term, but an affectionate term in my book. The pejorative term is to call a language a "hack". C++ is a hack. String mixins is a hack. Etc. But this simply isn't the case, and it strikes me that you're manufacturing words to suit how you feel, rather than basing how you feel on things as they are. No. There are plenty of visible artifacts from the process. No need to manufacture anything. If you scaled up C++ to D based on resources and usage then C++ should have 100s of free compilers. You have 2 free C++14 compilers. If you scaled up the institutions and mores of Norway to the size of and conditions applying to the US you would have a very odd country indeed. There is only one community driven C++14 compiler, g++. The other ones are primarily commercial. > One may legitimately have the view that the projects should be consolidated, but one would have to actually make an argument for it in the Russian style of close-reasoning. You dont have to consolidate anything. You need to look at the causes that
Re: dmd codegen improvements
On 5 September 2015 at 14:14, Walter Bright via Digitalmars-dwrote: > On 9/4/2015 7:52 AM, Manu via Digitalmars-d wrote: >> >> [...] > > > Sadly, your newsgroup software is back to doing double posts - once in > plaintext, once in html. My software in this case was the mail client on Android. I'm astonished this isn't a rampant problem; mail clients seem to do this by default. I have not configured it in any special way, not changed a single setting... this is default settings for the worlds most popular mail client (gmail). How can I possibly be the only offender here?
Re: dmd codegen improvements
On 9/4/2015 7:52 AM, Manu via Digitalmars-d wrote: [...] Sadly, your newsgroup software is back to doing double posts - once in plaintext, once in html.
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:53:06 UTC, Manu wrote: What I don't get is, Firefox and ie support plugins... Why isn't there a pnacl plugin for other browsers? Surely it could be added with the existing plugin interfaces? Actually, browsers are deprecating NPAPI plugins. Flash is so dead…
Re: dmd codegen improvements
On Friday, 4 September 2015 at 15:45:35 UTC, Luís Marques wrote: On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad wrote: Actually, browsers are deprecating NPAPI plugins. Flash is so dead… Could, in principle, Flash be supported through an extension, instead of a media / NPAPI plugin? I don't think they will kill Flash outright even after removing plugins. It was more wishful thinking on my part. Adobe will emulate everything Flash does within HTML5 before it is killed, don't you think?
Re: dmd codegen improvements
On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote: All of this could have been avoided by all browser vendors agreeing to implement pNaCl. Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately. I thought even the PNaCl people were working on wasm.
Re: dmd codegen improvements
Actually, in the point cloud on the web demo I've linked before, which is EXTREMELY compute intensive code, we experience a barely measurable loss in performance between pnacl and native code. 20% loss would be huge, but we see nothing like that, probably within 5% is closer to our experience. On 5 Sep 2015 3:11 am, "deadalnix via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > On Friday, 4 September 2015 at 14:56:48 UTC, Ola Fosheim Grøstad wrote: > >> On Friday, 4 September 2015 at 14:45:39 UTC, rsw0x wrote: >> >>> Because it has the path of least resistance. It's still a poor >>> technology that is just treating the symptoms. >>> >> >> pnacl/pepper is not good either, they are both poor technologies. >> >> > Statement do not makes arguements. pNaCl is portable, take only a 20% hit > compared to pure native and is compact to send through the wire. > >
Re: dmd codegen improvements
On 2015-09-03 23:01, Ola Fosheim Grostad wrote: If you don't change the prototype object, then it is mostly similar, but more flexible. Functions are constructors and prototype objects are class definitions. Looking how many languages compile to JS and how many JS libraries there are out there that try to invent some kind of new syntax for declaring classes and now E6, I would say a lot of people are not satisfied with the current state of JS. You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime. Yeah, that's one those languages I was thinking about ;) -- /Jacob Carlborg
Re: dmd codegen improvements
On Friday, 4 September 2015 at 07:44:23 UTC, Jacob Carlborg wrote: Looking how many languages compile to JS and how many JS libraries there are out there that try to invent some kind of new syntax for declaring classes and now E6, I would say a lot of people are not satisfied with the current state of JS. Yes, JS gets painful once you get above 1000 lines of code. Fortunately we can now use typed ES6 also on older platforms. There are also polyfills for things like Promises (async), and Fetch (dead easy ajax http request). You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime. Yeah, that's one those languages I was thinking about ;) I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications. For more demanding apps I think we need a more traditional language that generates high quality asm.js like code as well as regular ES6 and some clean bridging. So either a new language or a modified language (like a D++ or something).
Re: dmd codegen improvements
On 2015-09-03 15:09, Adam D. Ruppe wrote: what about Borland's compiler? That would be Taumetric in Walter's list [1][2]. [1] https://en.wikipedia.org/wiki/Borland_C%2B%2B [2] https://en.wikipedia.org/wiki/Turbo_C%2B%2B -- /Jacob Carlborg
Re: dmd codegen improvements
On 9/3/2015 3:27 AM, Manu via Digitalmars-d wrote: Our major active project at work also now depends on Emscripten and PNaCl; 2 exotic LDC targets which would get my office onto D quicksmart! ping Adam Ruppe? I've never suffered C++ so violently. I feel your pain!
Re: dmd codegen improvements
On 9/3/2015 1:31 AM, deadalnix wrote: On Thursday, 3 September 2015 at 06:54:05 UTC, Walter Bright wrote: On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote: As Walter once said, "Be the change you wish to see." I think that was Andrei. But I do agree with it. It's Gandhi. Ah, makes sense. Thanks for the correction.
Re: dmd codegen improvements
On 9/3/2015 7:30 AM, Jacob Carlborg wrote: On 2015-09-03 15:09, Adam D. Ruppe wrote: what about Borland's compiler? That would be Taumetric in Walter's list [1][2]. [1] https://en.wikipedia.org/wiki/Borland_C%2B%2B [2] https://en.wikipedia.org/wiki/Turbo_C%2B%2B Apple had licensed Symantec C++ at one point. I sometimes wonder what influence it had on clang.
Re: dmd codegen improvements
On 9/3/2015 2:37 PM, David Nadlinger wrote: On Thursday, 3 September 2015 at 18:14:45 UTC, Walter Bright wrote: I sometimes wonder what influence it had on clang. In terms of design, not more than any other C++ compiler would have as far as I can tell. Might be interesting for you to have a closer look at it at some point though for comparison (it's non-copyleft, so no need to be afraid of lawyers there). Yeah, I'd have to read through the source code. But it's still copyrighted, and I prefer not to be subject to taint. For years, many people did not believe I could have created a C++ compiler on my own, and they were quick to believe any possibility that I didn't. Refusing to look at other compilers helped a lot with this. I'm still the only person to have ever created a C++ compiler from front to back. :-) Of course, DMC++ is a C++98 compiler, and C++ has moved on.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 07:04:11 UTC, Walter Bright wrote: On 9/2/2015 9:55 PM, Ola Fosheim Grostad wrote: Most C++ compilers are dead. Actually, only a tiny handful of original C++ compilers were ever created. The rest are just evolved versions of them. To list them (from memory): Cfront (Bjarne Stroustrup) Zortech C++ (Me) G++ (Michael Tiemann) Clang Edison Design Group (Daveed Vandevorde) Taumetric (Michael Ball) Microsoft There were a lot of original C compilers developed, but they pretty much all failed to make the transition to C++. I expected the list to be longer. Which one represents the non-cfront SGI compilers? SGI was quite heavily into C++ unlike most of the Unix world.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 18:14:45 UTC, Walter Bright wrote: I sometimes wonder what influence it had on clang. In terms of design, not more than any other C++ compiler would have as far as I can tell. Might be interesting for you to have a closer look at it at some point though for comparison (it's non-copyleft, so no need to be afraid of lawyers there). — David
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 13:12:07 UTC, Adam D. Ruppe wrote: On Thursday, 3 September 2015 at 06:45:16 UTC, Jacob Carlborg wrote: There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS. If you don't change the prototype object, then it is mostly similar, but more flexible. Functions are constructors and prototype objects are class definitions. You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime. You can kinda do classes in JS, it just isn't pretty syntax. In the D to JS toy I did, I just did an array of function pointers to handle the virtual functions, similar to how D is compiled to machine code. It'd be fairly ugly to write by hand but when converting languages, it works well enough. Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions?
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote: On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: It is twice as slow as native. That's far from allowing generation of pure assembly. It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet. SIMD is not even remotely close to explaining the perf difference. What browser? Only FF supports it. Chrome just JIT it IIRC.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote: On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote: On 9/2/2015 7:48 PM, Adam D. Ruppe wrote: but still i'm meh on the practical usefulness of such things. I guess if you target a canvas and run your code in it that makes more sense but my preferred style is a progressive enhancement webpage where you want to know the browser platform and work with it rather than around it. I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less. That is silly. asm.js is a very restricted typed subset with strict rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise (like multithreading). It is twice as slow as native. That's far from allowing generation of pure assembly.
Re: dmd codegen improvements
On 9/2/2015 9:28 PM, H. S. Teoh via Digitalmars-d wrote: Yes, serve existing customers well, and they will spread the word for you, leading to more customers. Divert your energy to please non-customers in hopes of winning them over, and you may end up driving away what customers you do have. That's a good description of the approach I prefer.
Re: dmd codegen improvements
On 3 Sep 2015 8:20 am, "deadalnix via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote: >> >> On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote: >>> >>> On 9/2/2015 7:48 PM, Adam D. Ruppe wrote: but still i'm meh on the practical usefulness of such things. I guess if you target a canvas and run your code in it that makes more sense but my preferred style is a progressive enhancement webpage where you want to know the browser platform and work with it rather than around it. >>> >>> >>> I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less. >> >> >> That is silly. asm.js is a very restricted typed subset with strict rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise (like multithreading). > > > It is twice as slow as native. That's far from allowing generation of pure assembly. I have far more faith in gccjit. But it's more like the orange to a conventional jit's apples.
Re: dmd codegen improvements
On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote: As Walter once said, "Be the change you wish to see." I think that was Andrei. But I do agree with it.
Re: dmd codegen improvements
On 9/2/2015 9:55 PM, Ola Fosheim Grostad wrote: Most C++ compilers are dead. Actually, only a tiny handful of original C++ compilers were ever created. The rest are just evolved versions of them. To list them (from memory): Cfront (Bjarne Stroustrup) Zortech C++ (Me) G++ (Michael Tiemann) Clang Edison Design Group (Daveed Vandevorde) Taumetric (Michael Ball) Microsoft There were a lot of original C compilers developed, but they pretty much all failed to make the transition to C++.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 06:54:05 UTC, Walter Bright wrote: On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote: As Walter once said, "Be the change you wish to see." I think that was Andrei. But I do agree with it. It's Gandhi.
Re: dmd codegen improvements
On 2015-09-03 05:57, Walter Bright wrote: I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less. There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS. Although now with ECMAScript 6 classes are supported. But it will still be a long time before enough web browsers support E6. Therefore it can be useful to have an E6 compiler that translates to E5 or E3 compatible JS. -- /Jacob Carlborg
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote: On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: It is twice as slow as native. That's far from allowing generation of pure assembly. It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet. SIMD is not even remotely close to explaining the perf difference.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: It is twice as slow as native. That's far from allowing generation of pure assembly. It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet.
Re: dmd codegen improvements
On 3 September 2015 at 13:57, Walter Bright via Digitalmars-dwrote: > On 9/2/2015 7:48 PM, Adam D. Ruppe wrote: >> >> but still i'm meh on the practical usefulness of such things. I guess if >> you >> target a canvas and run your code in it that makes more sense but my >> preferred >> style is a progressive enhancement webpage where you want to know the >> browser >> platform and work with it rather than around it. > > > I don't see a whole lot of point to generating JS from another language. You > can't do anything more than JS can do, and you're likely to be doing less. You have a pile of existing code, you need to run it on a webpage, and don't have time/budget to rewrite that code. Emscripten is an opportunity, it is an enabling technology. Something that you can do and brings a nice business opportunity that you just wouldn't do otherwise, as in our case: http://udserver.euclideon.com/demo/ It would have been great if this were written in D, but we reverted to C++ because LDC doesn't support Emscripten (yet?). Our major active project at work also now depends on Emscripten and PNaCl; 2 exotic LDC targets which would get my office onto D quicksmart! I've never suffered C++ so violently.
Re: dmd codegen improvements
On 9/3/2015 2:28 PM, Ola Fosheim Grostad wrote: I expected the list to be longer. I don't. It takes 10 years to write a C++ compiler, and most companies wanting to get into the business found it far more practical to buy one as a starting point. Which one represents the non-cfront SGI compilers? SGI was quite heavily into C++ unlike most of the Unix world. I don't know, but many companies tended to hide where they got their starting point. I know about a few of them simply from being in the business and knowing the players. It's like VCRs. There were only a couple makers of VCR guts, but a lot of VCR boxes with different brand names on them that repackaged the same old guts. The same goes for dishwashers, SD cards, DVD blanks, etc. EDG licensed their front end to a lot of companies who made their own branded C++ compilers, such as Intel C++.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote: On Thursday, 3 September 2015 at 13:12:07 UTC, Adam D. Ruppe wrote: On Thursday, 3 September 2015 at 06:45:16 UTC, Jacob Carlborg wrote: There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS. If you don't change the prototype object, then it is mostly similar, but more flexible. Functions are constructors and prototype objects are class definitions. You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime. You can kinda do classes in JS, it just isn't pretty syntax. In the D to JS toy I did, I just did an array of function pointers to handle the virtual functions, similar to how D is compiled to machine code. It'd be fairly ugly to write by hand but when converting languages, it works well enough. Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions? Maybe because you need 2 map lookups + 1 indirection instead of an array lookup in addition of the indirect call. But who know, with a vectorized SSA, it surely will be faster than light.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim Grostad wrote: On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote: On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote: It is twice as slow as native. That's far from allowing generation of pure assembly. It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet. SIMD is not even remotely close to explaining the perf difference. What browser? Only FF supports it. Chrome just JIT it IIRC. asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically. The gap is way to big for vectorization to be a reasonable explanation. In fact a large body of code just do not vectorize at all. You seems to be fixated on that vectorization thing, when it is not even remotely close to the problem at hand.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 22:48:47 UTC, deadalnix wrote: On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote: Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions? Maybe because you need 2 map lookups + 1 indirection instead of an array lookup in addition of the indirect call. But who know, with a vectorized SSA, it surely will be faster than light. obj.f is not slower than obj.v[5] on the contrary, it is faster
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote: asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically. Browser version, benchmark, reference? Without informationloss there is no inherent overhead outside sandboxing if you avoid the sandbox boundaries. Other people report 1-1.5x.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote: Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions? The specific implementation I used was like what D compiles to: index into an array. So it is a bit clunky to do obj.vtbl[2](args) rather than obj.foo(args).
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 06:56:16 UTC, Walter Bright wrote: On 9/2/2015 9:28 PM, H. S. Teoh via Digitalmars-d wrote: Yes, serve existing customers well, and they will spread the word for you, leading to more customers. Divert your energy to please non-customers in hopes of winning them over, and you may end up driving away what customers you do have. That's a good description of the approach I prefer. Unless you sell DMD, how about providing a definition of "customer"? If you don't pay attention to evaluations, then surely the competition will steal your thunder and you'll end up as Cobol; on a long tail in maintenance mode.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 21:58:18 UTC, Walter Bright wrote: Yeah, I'd have to read through the source code. But it's still copyrighted, and I prefer not to be subject to taint. For years, many people did not believe I could have created a C++ compiler on my own, and they were quick to believe any possibility that I didn't. Refusing to look at other compilers helped a lot with this. Yeah, sure, that's your choice. It would have been been interesting to hear your take on it, though. — David
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 07:04:11 UTC, Walter Bright wrote: Actually, only a tiny handful of original C++ compilers were ever created. The rest are just evolved versions of them. what about Borland's compiler?
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 06:45:16 UTC, Jacob Carlborg wrote: There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS. You can kinda do classes in JS, it just isn't pretty syntax. In the D to JS toy I did, I just did an array of function pointers to handle the virtual functions, similar to how D is compiled to machine code. It'd be fairly ugly to write by hand but when converting languages, it works well enough.
Re: dmd codegen improvements
On 03-Sep-2015 16:09, Adam D. Ruppe wrote: On Thursday, 3 September 2015 at 07:04:11 UTC, Walter Bright wrote: Actually, only a tiny handful of original C++ compilers were ever created. The rest are just evolved versions of them. what about Borland's compiler? Seconded, it was horrible but still was there since MS-DOS. -- Dmitry Olshansky
Re: dmd codegen improvements
On 8/29/2015 1:13 PM, Ola Fosheim Grostad wrote: But the net effect of maintaining 3 different backends is sending signals that the project lacks direction and priorities. Back when there was only 1 compiler, people complained about that, saying it signaled lack of reliable support. Having 3 D compilers is a big positive. Each has their strengths and weaknesses. It's all good. People can and do interpret anything and everything about D as a negative. Or get involved and do something positive.
Re: dmd codegen improvements
On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote: It's been mentioned before that there really isn't much point in using C when you can use D. Even if you completely avoid the GC and the standard library, you're _still_ ahead of where you'd be with C, and you can call C functions trivially. So, you can definitely use D as a better C; you just lose out on a lot of cool stuff that D has to offer beyond that. But D has a lot to offer over C even without using any of that stuff. One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's features (heck, D2 was quite young at that point, and I don't think that ranges had been introduced to Phobos yet at that point, so the standard library was seriously lacking anyway), but it was still easier to use D. - Jonathan M Davis worthy of a quick blogpost sometime? Laeeth.
Re: dmd codegen improvements
On Wednesday, 2 September 2015 at 20:50:03 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 2 September 2015 at 19:05:32 UTC, Walter Bright wrote: On 8/29/2015 9:16 PM, Ola Fosheim Grostad wrote: Here is a good list: [...] 5. Performance. Ironically, you guys complained in this thread when that gets worked on. I agree that having a native D backend is a good thing. In fact, I'd very much like to see WebAssembly/asm.js codegen built around a backend that create compact builds since download size is an issue. Which is a different kind of "performance". I just don't see how I could use the current backend to achieve it. Maybe with your experience you could at some point in the future lay the foundation for a new a free backend, that is more minimalistic than LLVM, but that also could be used for the web? Adam Ruppe already wrote a javascript backend - it's not maintained as I guess not so much interest. Maybe not the fastest, but it's already been done. Again, JS not asm.js but I don't see why a man of your evident ability should find this an infeasible project were you to be serious about completing it.
Re: dmd codegen improvements
On Thu, Sep 03, 2015 at 02:30:39AM +, Laeeth Isharc via Digitalmars-d wrote: > On Sunday, 30 August 2015 at 16:17:49 UTC, Ola Fosheim Grøstad wrote: > >On Sunday, 30 August 2015 at 06:07:25 UTC, Laeeth Isharc wrote: > >>Morale is important in long term projects that don't pay off very > >>quickly, and constant nagging and grumbling doesn't tend to help, > >>even in the case when it is entirely well founded. > > > >Actually, it does help. > > There's a big difference between saying "dmd generates code that's > slow by the standards of modern C++ compilers. it's an impressive > accomplishment for a small group, but we ought to do better. I know > C++ and asm, and only have a little time, but I would like to help. > what would be most useful to look at ?" > > and something else. > > In my experience grumbling without action doesn't tend to lead to the > change you want in the world. In theory maybe it should, and someone > will listen. But human beings are funny creatures. [...] Especially in this forum, where large quantities of discussions, complaints, grandiose ideas, etc., are produced every day, yet disappointingly little of it actually results in anything. Submitting PRs on Github, or even just submitting bug reports / enhancement requests, OTOH, produces much more tangible value, in spite of frequently not even being mentioned here on the forum. As Walter once said, "Be the change you wish to see." Somebody else once said, "Talk is cheap; whining is actually free", which seems especially pertinent to this forum. --T
Re: dmd codegen improvements
On Wed, Sep 02, 2015 at 09:09:43PM -0700, Walter Bright via Digitalmars-d wrote: > On 9/2/2015 7:08 PM, Laeeth Isharc wrote: > >And that's why it really doesn't matter what the naysayers believe - > >the ones you want to focus on pleasing are those who are favourably > >disposed towards D anyway and just need to understand the case for it > >better, or have one or two missing things completed. > > That's right. > > I've heard "I'd use your product if only you added Feature X" for 35 > years. Every time I come back with "Here's X, now you can use it!" > they just come back with "That's great, but I actually need Feature > Y". Too true! auto featuresRequested = [ x ]; while (featuresRequested.length > 0) { refuse(product, new Reason(featuresRequested)); auto newFeatures = waitForNextRelease(); foreach (x; newFeatures) { featuresRequested.remove(x); auto y = new Excuse(); featuresRequested ~= y; } } adopt(product); > The truth is, those people will never use it. They just come up with > endless reasonable sounding excuses. They'll wear you out chasing > rainbows. > > Those kinds of feature requests should be responded to politely, but > with a healthy amount of skepticism. > > Of much more realistic interest are those who are already heavily > using the product, but are blocked by this or that. Yes, serve existing customers well, and they will spread the word for you, leading to more customers. Divert your energy to please non-customers in hopes of winning them over, and you may end up driving away what customers you do have. T -- Век живи - век учись. А дураком помрёшь.
Re: dmd codegen improvements
On Thursday, 3 September 2015 at 02:30:41 UTC, Laeeth Isharc wrote: In my experience grumbling without action doesn't tend to lead to the change you want in the world. In theory maybe it should, and someone will listen. But human beings are funny creatures. End user back pressure helps. If it does not help, then the development process is FUBAR. However it does help, Walter is an intelligent man, that enjoys defending his position, but that does not mean that he does not listen to arguments and internalize them over time. Well how would a dictator of D accomplish that? Probably porting the compiler to D would be a pretty good start, for a variety of reasons. That will help with stability, refactoring, and documentation I should have thought. Not everyone knows C++, and of those who do, not everyone wants to write in it. Dedicating one cycle to porting, another to refactoring and documentation is a very good start. IFF you focus on that and stick with it and avoid adding more features as code at the same time. (Add them to the plan/spec instead.) By the way, the dmd source code doesn't seem horribly obscure to read at first glance. Reading is one thing, making it do what you want another. For that you need either documentation or "reverse-engineering the underlying model". alors ? as you point out, an asm.js backend would be rather nice to have, and you are by all accounts a low-level guy, so it shouldn't be hard to do, no ? I don't have enough time to figure out all the ins-and-outs of the current compiler. To do that, in reasonable time, I would need a refactored and documented compiler. (I am also not primarily a low level person, my background is broad, but my major was in systems development). Given that C compilers are still developing, I doubt D will ever be finished in my useful career. So what ? The facts speak against your claim, since D is clearly becoming more polished with every release - just look at the improvements to the GC within the past year. (Runtime/compiler, whatever). Oh, I would love for D to follow the trajectory of C. C development can follow a near-waterfall development model: 1. specification-ratification-cycle 2. specification based gamma-beta-alpha production implementation 3. release 4. non-semantic improvements D is nowhere near C's conservative fully spec'ed ISO-standard-based process. Semantically C does not have many advantages over D, except VLAs (which I find rather useful and think D should adopt). Andrei talked about documentation and presentation a little while back, and we're now in a much better state. Allocators soon here. People have got D to run on embedded systems with low resources. What people can do isn't really all that interesting. What is interesting is what you can do with little effort and better than the alternatives. BASIC ran on machines with just a few K's of RAM, that does not make it a reasonable choice. enough for my modest needs. I'd honestly bet that a little more effort to communicate the practical commercial benefits of D would make much more of a difference than this abstract stuff. But who am I to say. I think you underestimate the expections people with a major in compsci or a significant amount of development experience have. They care about the actual qualities, not the presentation. Those are the CTOs you need to convince, not the CEOs. As it stands today both Rust and D falls into the category toy-languages. "toy language" is the term academics use to describe their languages that explore interesting ideas, but does not have the polish, tooling or commercial backing to take a significant market share.