November 27, 2017
On 11/26/17 9:56 PM, Walter Bright wrote:
> I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D.

I did a double-take on this. Are we to see an article about it soon?

Very exciting!

-Steve
November 27, 2017
On Monday, 27 November 2017 at 06:12:53 UTC, Ola Fosheim Grostad wrote:
> On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh
>> std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version.
>
> You meant stupidly, you would rather use std::string_view for string references in C++.

I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a fig leaf of deniability.)

> std::string is a library convenience type that typically is only used for debugging and filenames. If you want performance then it really isnt possible to make do with a fixed library type for strings so in a realistic program people would write their own.

An efficient text parser doesn't seem like a sufficiently unusual task that it should require you to create your own string type. A large swath of programs will use at least one text parser.

> Sure. But maybe you shouldn't use a tiny 400k input when discussing performance. Try to think about how many instructions a CPU executes in 50ms...

It is often useful to talk about real-world workloads when discussing performance. The reference document I'm talking about is a short novel of 75,000 words. It was a document I already had on hand, and it was within a factor of two of the largest I expected to feed through subtex.

And I already had the numbers on hand: <https://blog.ikeran.org/?p=277>

If you want me to do more in-depth testing, you'll have to pay me.
November 27, 2017
On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote:
> I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a fig leaf of deniability.)

I'n not talking about you obviously. I am talking about using languages stupidly... You could use GSL string_span or the array version span, or write your own in 20 minutes. These are not language constructs, but library constructs, so they dont speak to the efficiency of the language...

> An efficient text parser doesn't seem like a sufficiently unusual task that it should require you to create your own string type. A large swath of programs will use at least one text parser.

C++ requires you to write basically most things from scratch or use external libraries... What ships with it is very rudimentary. There are many parser libraries available.

C++ is very much batteries not included... Which is good for low level programming.

> It is often useful to talk about real-world workloads when discussing performance.

Well, in that case Java was sufficiently fast, so all languages came out the same...

If we talk about language performance the we need use a different approach. If we do a direct translation from lang A to B, then we essentially give A an advantage.

So that methodology is flawed.

Assuming that your CPU can execute 20 billion instuctions per second.  That means 1 billion per 50 ms, so your budget is 1 million instructions on 400 bytes? Doesnt that suggest that the program is far from optimal or that most of the time is spent on something else?

Anyway benchmarking different languages isnt easy, so failing at doing it well is usual... It is basically very difficult to do convincingly.

November 27, 2017
On 27.11.2017 09:01, IM wrote:
> On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote:
>> On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
>>> - ‎It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone.
>>
>> Have you observed a human to exist who has complained about a specific feature in D that is similar to a feature in Java? Relaying their complaints would be much more useful.
>>
> 
> Yes, in particular All classes inherit from `Object`,

Actually, extern(C++) classes don't. (Also, Object does not. :o) )

> virtual methods by default,

This was almost changed some time ago, but doing so would break a lot of existing code.

> inner classes pointers to parent classes

I think marking inner classes static or just not nesting them works around this well enough in those cases where it is not desired.

> ... to name a few.

Another one: Object has a lazily initialized 'monitor' field.
November 27, 2017
On 11/27/2017 7:16 AM, Steven Schveighoffer wrote:
> On 11/26/17 9:56 PM, Walter Bright wrote:
>> I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D.
> 
> I did a double-take on this. Are we to see an article about it soon?

I suppose I should write one :-) It was a very satisfying project. I'm looking at converting all my C projects still in use (like 'make') to D. BetterC has removed the last barriers to it.

> 
> Very exciting!
> 
> -Steve

November 28, 2017
On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad wrote:
> On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote:
>> I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a fig leaf of deniability.)
>
> I'n not talking about you obviously. I am talking about using languages stupidly...

You can ask your local HR representative how much better it is to say "your ideas are stupid" than "you are stupid".

> You could use GSL string_span or the array version span, or write your own in 20 minutes. These are not language constructs, but library constructs, so they dont speak to the efficiency of the language...

Only for people who are happy to eschew the standard library, which pretty much just includes C++ users.

> C++ is very much batteries not included... Which is good for low level programming.

So you're saying that having a body of well tested code that does what you want already but *might* be making performance tradeoffs that don't work for your use case, is *worse* than not having it.

Well, it's a heterodox opinion to be sure.

>> It is often useful to talk about real-world workloads when discussing performance.
>
> Well, in that case Java was sufficiently fast, so all languages came out the same...

You might try reading my first post.

Java: 140ms to print "Hello world"

D: 50ms to turn a 400kb subtex document into an epub

> Assuming that your CPU can execute 20 billion instuctions per second.  That means 1 billion per 50 ms, so your budget is 1 million instructions on 400 bytes? Doesnt that suggest that the program is far from optimal or that most of the time is spent on something else?

Again, you might try reading my first post. In it, I mentioned memory a lot, since allocating memory is relatively slow. I specifically called it out as the reason that the C# version of subtex was so slow. And allocating memory isn't slow simply because it requires executing a large number of instructions.
November 28, 2017
On Tuesday, 28 November 2017 at 02:26:34 UTC, Neia Neutuladh wrote:
> On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad wrote:
>> On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote:
>>> I last used C++ professionally in 2015, and we were still rolling out C++11. std::string_view is part of C++17. You're calling me stupid for not having already known about it. (Yes, yes, you were sufficiently indirect to have a fig leaf of deniability.)
>>
>> I'n not talking about you obviously. I am talking about using languages stupidly...
>
> You can ask your local HR representative how much better it is to say "your ideas are stupid" than "you are stupid".

Could ask Linus about that, think I recall something about baby sloth dropped on it's head retardation level, or something.

>> C++ is very much batteries not included... Which is good for low level programming.
>
> So you're saying that having a body of well tested code that does what you want already but *might* be making performance tradeoffs that don't work for your use case, is *worse* than not having it.
>
> Well, it's a heterodox opinion to be sure.

For C++ that's boost. Most people avoid it cause of all the bloat anyways.

>>> It is often useful to talk about real-world workloads when discussing performance.
>>
>> Well, in that case Java was sufficiently fast, so all languages came out the same...
>
> You might try reading my first post.
>
> Java: 140ms to print "Hello world"
>
> D: 50ms to turn a 400kb subtex document into an epub

Were you including startup times? Then that's not a very fair comparison. Lots of applications aren't just start and stop frequently. These benchmarks are all but pointless for performance anyways. Like when someone updated the D sort functions, they made an article about how much faster sorting was in D than C++. Well no shit, you just spent a bunch of time optimizing it based on some tiny stupid test.

Anyways if you think that's a valid comparison of performance you have no idea what's going on.


November 28, 2017
On Monday, 27 November 2017 at 23:13:00 UTC, Walter Bright wrote:
> On 11/27/2017 7:16 AM, Steven Schveighoffer wrote:
>> On 11/26/17 9:56 PM, Walter Bright wrote:
>>> I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D.
>> 
>> I did a double-take on this. Are we to see an article about it soon?
>
> I suppose I should write one :-) It was a very satisfying project. I'm looking at converting all my C projects still in use (like 'make') to D. BetterC has removed the last barriers to it.

Should add optlink to that list, would love to see it converted to D!

November 28, 2017
On Monday, 27 November 2017 at 08:33:42 UTC, IM wrote:
> - More exposure. I sometimes feel like there isn't enough D material to consume on a regular basis (and I and certainly many others are eager to learn more and more about the language). i.e. one blog post (weekly?), and a single DConf annually is not enough. In the C++ world, there's always something to read (various blog posts) or something to watch (CppCon, C++Now, Meeting C++, code::dive, Pacific++, ...etc.)
>

What are the plans to increase exposure?
November 28, 2017
On Tuesday, 28 November 2017 at 02:26:34 UTC, Neia Neutuladh wrote:
>
> You might try reading my first post.
>
> Java: 140ms to print "Hello world"
>
> D: 50ms to turn a 400kb subtex document into an epub
>

You're not measuring what you think for the Java program. Did you calculate the runtime and JIT initialization time and subtracted that from the actual execution time? Otherwise your benchmark isn't sufficient.