Jump to page: 1 2
Thread overview
If Zortech C++ and dmc++ are fast, why is dmd's asm slow?
May 29
James Lu
May 29
James Lu
May 30
Abdulhaq
Jun 08
Abdulhaq
May 29
>

In 1988 Zortech C++ was the first C++ compiler to ship for Windows and the performance of its compiled executables compared favourably against Microsoft C 5.1 and Watcom C 6.5 in a graphics benchmark run by PC Magazine.

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

May 29

On Saturday, 29 May 2021 at 23:34:47 UTC, James Lu wrote:

>

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

They were fast in 1988. Even in 1998.

But since then they've only gotten a little better, whereas the competition has gotten a LOT better.

May 29

On Saturday, 29 May 2021 at 23:36:34 UTC, Adam D. Ruppe wrote:

>

On Saturday, 29 May 2021 at 23:34:47 UTC, James Lu wrote:

>

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

They were fast in 1988. Even in 1998.

But since then they've only gotten a little better, whereas the competition has gotten a LOT better.

That makes sense.

Why does DMD only have a -O flag, not a -O2?

The competition got heavier– slower compiles, too.

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

May 30
On 30/05/2021 11:43 AM, James Lu wrote:
> I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

1 building of them? Sounds about right!

Could take a while tho...
May 30

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

No, phd=research. Not engineering.

May 30

On Sunday, 30 May 2021 at 00:04:35 UTC, Ola Fosheim Grostad wrote:

>

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

No, phd=research. Not engineering.

Lots of compiler work is done by PhD students, especially the groundwork on new algorithms etc.

The backend would need a complete rewrite which is basically what Chris Lattner did his PhD thesis on (or at least on the design of said rewrite)

May 30

On Sunday, 30 May 2021 at 02:43:29 UTC, Max Haughton wrote:

>

On Sunday, 30 May 2021 at 00:04:35 UTC, Ola Fosheim Grostad wrote:

>

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

No, phd=research. Not engineering.

Lots of compiler work is done by PhD students, especially the groundwork on new algorithms etc.

The backend would need a complete rewrite which is basically what Chris Lattner did his PhD thesis on (or at least on the design of said rewrite)

Master thesis. Phd=advancement in pointer analysis, more theoretical/narrow.

May 30

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

On Saturday, 29 May 2021 at 23:36:34 UTC, Adam D. Ruppe wrote:

>

On Saturday, 29 May 2021 at 23:34:47 UTC, James Lu wrote:

>

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

They were fast in 1988. Even in 1998.

But since then they've only gotten a little better, whereas the competition has gotten a LOT better.

That makes sense.

Why does DMD only have a -O flag, not a -O2?

The competition got heavier– slower compiles, too.

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

Why stop at -O2? The languages of the future will go to -O11.

May 31

On Sunday, 30 May 2021 at 12:43:22 UTC, Abdulhaq wrote:

>

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

On Saturday, 29 May 2021 at 23:36:34 UTC, Adam D. Ruppe wrote:

>

On Saturday, 29 May 2021 at 23:34:47 UTC, James Lu wrote:

>

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

They were fast in 1988. Even in 1998.

But since then they've only gotten a little better, whereas the competition has gotten a LOT better.

That makes sense.

Why does DMD only have a -O flag, not a -O2?

The competition got heavier– slower compiles, too.

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

Why stop at -O2? The languages of the future will go to -O11.

A higher level of optimizations doesn't necessarily mean better. With GCC, real-world applications may perform better with -O2 than -O3. A lot of optimizations performed on -O3 may be too aggressive depending on the type of operations, size and other complex variables in the equation.

A practical example of this situation is present in Arch Linux. Every package is compiled with -O2 optimizations. See https://github.com/archlinux/devtools/blob/master/makepkg-x86_64.conf#L42 .

May 31

On Monday, 31 May 2021 at 20:33:08 UTC, Luís Ferreira wrote:

>

On Sunday, 30 May 2021 at 12:43:22 UTC, Abdulhaq wrote:

>

On Saturday, 29 May 2021 at 23:43:48 UTC, James Lu wrote:

>

On Saturday, 29 May 2021 at 23:36:34 UTC, Adam D. Ruppe wrote:

>

On Saturday, 29 May 2021 at 23:34:47 UTC, James Lu wrote:

>

If Zortech C++ and dmc++ are fast, why is dmd's asm slow? I thought they used the same machine code backend.

They were fast in 1988. Even in 1998.

But since then they've only gotten a little better, whereas the competition has gotten a LOT better.

That makes sense.

Why does DMD only have a -O flag, not a -O2?

The competition got heavier– slower compiles, too.

I wonder if it could be possible to get some CS PhD candidate to work on dmc++ to bring its backend up to modern standards.

Why stop at -O2? The languages of the future will go to -O11.

A higher level of optimizations doesn't necessarily mean better. With GCC, real-world applications may perform better with -O2 than -O3. A lot of optimizations performed on -O3 may be too aggressive depending on the type of operations, size and other complex variables in the equation.

A practical example of this situation is present in Arch Linux. Every package is compiled with -O2 optimizations. See https://github.com/archlinux/devtools/blob/master/makepkg-x86_64.conf#L42 .

In my experience I have not bumped into this issue all that often, especially when allowing the compiler to use a specific machine description for the target (Working out exactly which target information most of this is due to is unfortunately quite painful as modern compilers are anything but simple when deciding what to do based on their nicely specified machine description files)

« First   ‹ Prev
1 2