Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: simple optimization test of dcclinux64 and golang1.9


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 17 - Last Post: Oct 18, 2017 12:13 PM Last Post By: Rudy Velthuis (...
Guangyao Hu

Posts: 5
Registered: 6/20/11
simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2017 7:00 PM
Hi,
Yesterday i did a little simple & rough test about compiler optimization of dcclinux64, compared with golang(1.9), and the results showed out that dcclinux64 was a bit slow, the testing codes are from http://www.cnblogs.com/ecofast/p/4043873.html
All testings were performed on CentOS Linux release 7.2.1511 (Core), with Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz and 8GB RAM, and here are the testing results.

matrix test:
Delphi: 6103ms, 6071ms, 6076ms, 6090ms, 6084ms
Golang: 5.33s, 5.35s, 5.35s, 5.34s, 5.36s

str test(the Golang code uses bytes.Buffer):
Delphi: 132ms, 133ms, 131ms, 132ms, 133ms
Golang: 92ms, 98ms, 94ms, 89ms, 89ms

It seems that:
1) without the support of FastMM, string operations in Delphi are no longer efficient(?)
2) the dcclinux64 could be better since 5 years ago, i did some test about C++Builder which was already llvm back end and the results showed that it's optimization ability was nearly as good as MS VC

And i have some (naive)questions:
1) Which MM will Delphi utilize on Linux? TCMalloc or jemlloc?
2) Is dcclinux64 already LLVM back end? I was confused of the compilation speed of it, compared with the C++Builder compiler...

Edited by: Guangyao Hu on Oct 8, 2017 7:01 PM

Edited by: Guangyao Hu on Oct 8, 2017 7:03 PM
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 12:02 AM   in response to: Guangyao Hu in response to: Guangyao Hu
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 1:58 AM   in response to: Guangyao Hu in response to: Guangyao Hu
Guangyao Hu wrote:
1) Which MM will Delphi utilize on Linux? TCMalloc or jemlloc?

The plain LibC allocator.
Which is much slower than FastMM4, for sure (latest glibc did have a better allocator some weeks ago, but it is for sure not included yet in your distro).

2) Is dcclinux64 already LLVM back end? I was confused of the compilation speed of it, compared with the C++Builder compiler...

Yes, it uses LLVM.
First proof is that it is much slower than the Win64 platform to compile. ;)

But the LLVM use is clearly not efficient - some wrong settings, maybe.
It is not a LLVM problem, but how LLVM is used by dcclinux64.
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 2:06 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
BTW, I use FPC on production since years for Linux, and its code is pretty good enough.
Not as optimized than LLVM or GCC for intensive computation tasks (no automated vectorization, for instance), but pretty good enough for most work.

I found the FPC compiler to be more efficient than Delphi's - see http://blog.synopse.info/post/2015/06/21/Why-FPC-may-be-a-better-compiler-than-Delphi
The main benefits are it is natively cross-platform (no external LLVM), so is consistent.
And FPC team makes continuous effort for code optimization - whereas Embarcadero sounded more like tied to adding new features, not compiler tuning.

About Delphi, the RTL is clearly a sometimes a bottleneck (especially due to ARC implementation).

Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 2:38 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
And FPC team makes continuous effort for code optimization - whereas Embarcadero sounded more like tied to adding new features, not compiler tuning.
Which new "features" was added in Tokyo, was that not just the Linux compiler?
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 2:27 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
But the LLVM use is clearly not efficient - some wrong settings, maybe.
It is not a LLVM problem, but how LLVM is used by dcclinux64.

It seems to be a problem in the Frontend compiler (Delphi -> IR). The codegen for ARM is the same.
If Emba dont fix it, we get the same "speed" as well for macOS and later on Windows.
Guangyao Hu

Posts: 5
Registered: 6/20/11
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 7:42 PM   in response to: Ronald Klitsche in response to: Ronald Klitsche
Ronald Klitsche wrote:
Arnaud Bouchez wrote:
But the LLVM use is clearly not efficient - some wrong settings, maybe.
It is not a LLVM problem, but how LLVM is used by dcclinux64.

It seems to be a problem in the Frontend compiler (Delphi -> IR). The codegen for ARM is the same.
If Emba dont fix it, we get the same "speed" as well for macOS and later on Windows.

Maybe you are right, years ago when i did some test of the C++Builder compiler(based on LLVM), it's pretty good, in most samples it beat MS VC!
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 2:01 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Am 09.10.2017 um 10:58 schrieb Arnaud Bouchez:

But the LLVM use is clearly not efficient - some wrong settings, maybe.
It is not a LLVM problem, but how LLVM is used by dcclinux64.

What do you mean with this?
Speed of compilation or speed of generated code?

Greetings

Markus
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 11:34 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Speed of compilation or speed of generated code?

Both need improvements.
Slow speed of generated code is due to how LLVM is used.
Slow speed of compilation is due to LLVM - and perhaps also how it is used, since a "fast" compilation may be possible using LLVM-JIT.
Guangyao Hu

Posts: 5
Registered: 6/20/11
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2017 7:37 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
Guangyao Hu wrote:
1) Which MM will Delphi utilize on Linux? TCMalloc or jemlloc?

The plain LibC allocator.
Which is much slower than FastMM4, for sure (latest glibc did have a better allocator some weeks ago, but it is for sure not included yet in your distro).

2) Is dcclinux64 already LLVM back end? I was confused of the compilation speed of it, compared with the C++Builder compiler...

Yes, it uses LLVM.
First proof is that it is much slower than the Win64 platform to compile. ;)

But the LLVM use is clearly not efficient - some wrong settings, maybe.
It is not a LLVM problem, but how LLVM is used by dcclinux64.

Thank you, seems that emb guys have lots of TECHNICAL work to get done before the so called NectGen compiler matches its name :)
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 11, 2017 6:25 AM   in response to: Guangyao Hu in response to: Guangyao Hu
Guangyao Hu wrote:

Arnaud Bouchez wrote:
Guangyao Hu wrote:
1) Which MM will Delphi utilize on Linux? TCMalloc or jemlloc?

The plain LibC allocator.
Which is much slower than FastMM4, for sure (latest glibc did have
a better allocator some weeks ago, but it is for sure not included
yet in your distro).

2) Is dcclinux64 already LLVM back end? I was confused of the
compilation speed of it, compared with the C++Builder compiler...

Yes, it uses LLVM.
First proof is that it is much slower than the Win64 platform to
compile. ;)

But the LLVM use is clearly not efficient - some wrong settings,
maybe. It is not a LLVM problem, but how LLVM is used by
dcclinux64.

Thank you, seems that emb guys have lots of TECHNICAL work to get
done before the so called NectGen compiler matches its name :)

That is to be expected. The early Win64 compilers (and especially the
RTL) were not very efficient either. These days, they are, mainly
because of vast improvements in the RTL.

--
Rudy Velthuis http://www.rvelthuis.de

"I would have made a good pope."
-- Richard Nixon
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 11, 2017 7:04 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
Guangyao Hu wrote:
Thank you, seems that emb guys have lots of TECHNICAL work to get
done before the so called NectGen compiler matches its name :)

That is to be expected. The early Win64 compilers (and especially the
RTL) were not very efficient either. These days, they are, mainly
because of vast improvements in the RTL.

Isn't it a compiler issue? I assume, that the Delphi RTL cant help in this case.
And the NextGen isn't that new, the arrival time of the first version (XE4) was April 2013.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 11, 2017 8:18 AM   in response to: Ronald Klitsche in response to: Ronald Klitsche
Ronald Klitsche wrote:

Rudy Velthuis (TeamB, MVP) wrote:
Guangyao Hu wrote:
Thank you, seems that emb guys have lots of TECHNICAL work to get
done before the so called NectGen compiler matches its name :)

That is to be expected. The early Win64 compilers (and especially
the RTL) were not very efficient either. These days, they are,
mainly because of vast improvements in the RTL.

Isn't it a compiler issue? I assume, that the Delphi RTL cant help in
this case. And the NextGen isn't that new, the arrival time of the
first version (XE4) was April 2013.

But the Linux compiler/RTL combo is new. There are many (especially
RTL) functions that could be optimized, especially those working with
strings.

--
Rudy Velthuis http://www.rvelthuis.de

"I've made an odd discovery. Every time I talk to a savant I
feel quite sure that happiness is no longer a possibility.
Yet when I talk with my gardener, I'm convinced of the
opposite." -- Bertrand Russell
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2017 12:19 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
{quote:title=Rudy Velthuis (TeamB, MVP) wrote:}
But the Linux compiler/RTL combo is new.

I dont think, that the FrontEnd compiler for Linux compiler is new.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2017 9:13 AM   in response to: Ronald Klitsche in response to: Ronald Klitsche
Ronald Klitsche wrote:

{quote:title=Rudy Velthuis (TeamB, MVP) wrote:}
But the Linux compiler/RTL combo is new.

I dont think, that the FrontEnd compiler for Linux compiler is new.

You may not think so, but it is certainly a new compiler. Sure, it is
based on the other compilers, but it is new, especially the code
generator.

--
Rudy Velthuis http://www.rvelthuis.de

"I have the greatest admiration for your propaganda. Propaganda
in the West is carried out by experts who have had the best
training in the world, in the field of advertising, and have
mastered the techniques with exceptional proficiency. Yours are
subtle and persuasive; ours are crude and obvious. I think that
the fundamental difference between our worlds, with respect to
propaganda, is quite simple. You tend to believe yours and we
tend to disbelieve ours."
-- A U.S. based Soviet correspondent
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2017 12:27 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB, MVP) wrote:
You may not think so, but it is certainly a new compiler.

The codegen for ARM and X64 seems to be very similar, after all these years. What's new?

Sure, it is based on the other compilers, but it is new, especially the code
generator.

The ASM code is generated by LLVM. x64 isn't new either.
But the LLVM can only be as good as what it gets from the Delphi FrontEnd compiler.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: simple optimization test of dcclinux64 and golang1.9 [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 18, 2017 12:13 PM   in response to: Ronald Klitsche in response to: Ronald Klitsche
Ronald Klitsche wrote:

Rudy Velthuis (TeamB, MVP) wrote:
You may not think so, but it is certainly a new compiler.

The codegen for ARM and X64 seems to be very similar, after all these
years. What's new?

Sure, it is based on the other compilers, but it is new, especially
the code generator.

The ASM code is generated by LLVM.

Yes, and no. It all depends on what the compiler generates.

x64 isn't new either.

But generating 64 bit for LLVM is, for Delphi. Don't assume that there
is no difference, i.e. that the intermediate code is the same for each
platform.

But the LLVM can only be as good as what it gets from the Delphi
FrontEnd compiler.

The runtime is also an important part of the performance.

--
Rudy Velthuis http://www.rvelthuis.de

"Whatever the natural cause, sin is the true cause of all
earthquakes."
-- John Wesley
Guangyao Hu

Posts: 5
Registered: 6/20/11
Re: simple optimization test of dcclinux64 and golang1.9  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 18, 2017 2:30 AM   in response to: Guangyao Hu in response to: Guangyao Hu
Guangyao Hu wrote:
Hi,
Yesterday i did a little simple & rough test about compiler optimization of dcclinux64, compared with golang(1.9), and the results showed out that dcclinux64 was a bit slow, the testing codes are from http://www.cnblogs.com/ecofast/p/4043873.html
All testings were performed on CentOS Linux release 7.2.1511 (Core), with Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz and 8GB RAM, and here are the testing results.

matrix test:
Delphi: 6103ms, 6071ms, 6076ms, 6090ms, 6084ms
Golang: 5.33s, 5.35s, 5.35s, 5.34s, 5.36s

str test(the Golang code uses bytes.Buffer):
Delphi: 132ms, 133ms, 131ms, 132ms, 133ms
Golang: 92ms, 98ms, 94ms, 89ms, 89ms

It seems that:
1) without the support of FastMM, string operations in Delphi are no longer efficient(?)
2) the dcclinux64 could be better since 5 years ago, i did some test about C++Builder which was already llvm back end and the results showed that it's optimization ability was nearly as good as MS VC

And i have some (naive)questions:
1) Which MM will Delphi utilize on Linux? TCMalloc or jemlloc?
2) Is dcclinux64 already LLVM back end? I was confused of the compilation speed of it, compared with the C++Builder compiler...

Edited by: Guangyao Hu on Oct 8, 2017 7:01 PM

Edited by: Guangyao Hu on Oct 8, 2017 7:03 PM

I just did some test using FPC(3.0.2) on the some machine, and the results were:
matrix test: 3195 ms
str test: 248ms

The command line were like: fpc MatrixTest.lpr -Tlinux -Px86_64 -O4
In the two samples, -O3 and -O4 have no difference.

It seems that:
1) FPC also didn't use tcmaaloc nor jemalloc
2) FPC generates more optimized binary code
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02