Re: dmd codegen improvements

[Tobias Müller via Digitalmars-d]

Iain Buclaw via Digitalmars-d  wrote:
> 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

[Joakim via Digitalmars-d]

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

[Mike Parker via Digitalmars-d]

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

[Bruno Medeiros via Digitalmars-d]

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

[Bruno Medeiros via Digitalmars-d]

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

[Bruno Medeiros via Digitalmars-d]

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

[Kagamin via Digitalmars-d]

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

[jmh530 via Digitalmars-d]

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

[Laeeth Isharc via Digitalmars-d]

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

[Bruno Medeiros via Digitalmars-d]

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

[Bruno Medeiros via Digitalmars-d]

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

[Ola Fosheim Grøstad via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[BBasile via Digitalmars-d]

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

[ponce via Digitalmars-d]

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

[Martin Nowak via Digitalmars-d]

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

[BBasile via Digitalmars-d]

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

[Martin Nowak via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[via Digitalmars-d]

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

[Manu via Digitalmars-d]

On 6 September 2015 at 18:57, Jacob Carlborg via Digitalmars-d
 wrote:
> 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

[Iain Buclaw via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[via Digitalmars-d]

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

[Kagamin via Digitalmars-d]

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

[via Digitalmars-d]

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

[Iain Buclaw via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Dmitry Olshansky via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Manu via Digitalmars-d]

On 6 September 2015 at 07:20, Walter Bright via Digitalmars-d
 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.

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

[rsw0x via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[rsw0x via Digitalmars-d]

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

[via Digitalmars-d]

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

[via Digitalmars-d]

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

[rsw0x via Digitalmars-d]

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

[Manu via Digitalmars-d]

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

[via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[rsw0x via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[via Digitalmars-d]

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

[via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[rsw0x via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Laeeth Isharc via Digitalmars-d]

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

[via Digitalmars-d]

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

[Laeeth Isharc via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[Manu via Digitalmars-d]

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?

Re: dmd codegen improvements

[Walter Bright via Digitalmars-d]

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

[via Digitalmars-d]

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

[via Digitalmars-d]

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

[jmh530 via Digitalmars-d]

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

[Manu via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[David Nadlinger via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Iain Buclaw via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[via Digitalmars-d]

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

[Manu via Digitalmars-d]

On 3 September 2015 at 13:57, Walter Bright via Digitalmars-d
 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.

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

[Walter Bright via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Ola Fosheim Grostad via Digitalmars-d]

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

[David Nadlinger via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Dmitry Olshansky via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Laeeth Isharc via Digitalmars-d]

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

[Laeeth Isharc via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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

[via Digitalmars-d]

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.