Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: Delphi's compiler



Permlink Replies: 6 - Last Post: Aug 29, 2014 5:59 AM Last Post By: fia starta
fia starta

Posts: 9
Registered: 10/25/09
Delphi's compiler
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 27, 2014 6:44 PM
Don't worry, I only rant about Delphi's poor compiler every 3 years.

For over 15 years, I have been thinking that if Delphi's compiler was SO bad, it's because it hadn't been updated since Delphi7, and was hoping that one day maybe, Embarcadero would make it acceptable.

..but then I read this:
http://www.delphitools.info/2014/05/07/a-look-at-improved-inlining-in-delphi-xe6/2/

Really? Embarcadero is touching the compiler after all, but only to make it even worse?

It's one thing that the compiler is this poor, and it's already ironic enough that the next Delphi will be focusing on multithreading, which may give you at the very best 300-350% better performances on today's quad cores, while Delphi inserts 13 instructions where only 1 is needed.
But really, all we would need is support for assembler in inlined functions. Just that, and then third-parties can come up with optimized libraries for everything, including basic math.

And yes, I know that inlining assembler is a challenge, but you could come up with a solution, like "virtual" registers, etc. And let's remember that initially, inlined functions in Turbo Pascal were only only supporting assembler (well, machine code to be exact), they were ONLY supporting that.

Give us assembler or machine code inlining, and let us do our own "intrinsics", and we won't have to complain about Delphi's compiler which is probably the worst in history.
It sucks to see each new version bloated with crap that we could already get from third-parties, while there's the compiler we can do nothing about. A compiler, that's normally the core of a programming environment, it's not a side thing that you leave to a noob team.

Bonus point, it would also make binaries much smaller, and when you compare the size of a binary produced by the latest Delphi to the one produced by the last good Delphi (Delphi 7 I'd say), omg..

Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi's compiler [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 27, 2014 8:14 PM   in response to: fia starta in response to: fia starta
fia wrote:

Bonus point, it would also make binaries much smaller, and when you
compare the size of a binary produced by the latest Delphi to the one
produced by the last good Delphi (Delphi 7 I'd say), omg..

That is not a result of just the compiler by itself. The RTL and VCL have
grown considerably since D7. They contribute to file size.

--
Remy Lebeau (TeamB)
fia starta

Posts: 9
Registered: 10/25/09
Re: Delphi's compiler [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 27, 2014 8:59 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
That is not a result of just the compiler by itself. The RTL and VCL have
grown considerably since D7. They contribute to file size.

yes I know, bloating is indeed the main reason, but sometimes we can hack the new stuff out & reduce the size (we did that with "themes")
(& to be honnest, I wouldn't even care for the size of binaries if we weren't mainly doing plugins as DLLs).

Auto-inlining probably has a role as well, and when you see what the compiler produces, it'd be safe to say that binaries would probably be at least half the current sizes.
An Pham

Posts: 7
Registered: 11/2/01
Re: Delphi's compiler
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2014 6:39 AM   in response to: fia starta in response to: fia starta
fia starta wrote:
Don't worry, I only rant about Delphi's poor compiler every 3 years.

For over 15 years, I have been thinking that if Delphi's compiler was SO bad, it's because it hadn't been updated since Delphi7, and was hoping that one day maybe, Embarcadero would make it acceptable.

..but then I read this:
http://www.delphitools.info/2014/05/07/a-look-at-improved-inlining-in-delphi-xe6/2/

It does not matter much since Delphi runtime, TPersistent class (or any derived from it), is not thread friendly at all. On its Destroy, it calls RemoveFixups(Self); and there is a global GlobalFixupList lock and unlock. They need to fix up the runtime codes

Cheers

fia starta

Posts: 9
Registered: 10/25/09
Re: Delphi's compiler
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2014 8:19 PM   in response to: An Pham in response to: An Pham
It does not matter much since Delphi runtime, TPersistent class (or any derived from it), is not thread friendly at all. On its Destroy, it calls RemoveFixups(Self); and there is a global GlobalFixupList lock and unlock. They need to fix up the runtime codes

mmh ok, but how is that related?

You mean Delphi isn't efficient at multithreading, so no need to speed up the compiler?
Well: Delphi is efficient at multithreading.

I'm checking what you're talking about, seems like RemoveFixups is indeed using a TMonitor. And at a first glance, TMonitor seems to be bad, as opposed to a good old critical section.
Ok, but.. why would you create/destroy TPersistent-based classes in a thread anyway? Even doing that for any class is to be avoided anyway, I'd rather use records on the heap, or preallocated classes for this. Creating/destroying classes in a thread also involves the memory manager, and Delphi's memory manager is TOO not very thread-friendly (this because the guy behind it believes that critical sections are evil, and opted for a much much muuuch worse Sleep() option).

Talking about this, to those who don't know: if your app is multithreaded, switch this on:
NeverSleepOnMMThreadContention:=True;
It will make the memory manager spinning, which isn't as good as using a proper critical section (which is spinning + waiting for an event, which will involves, at worst, around 100 microseconds delays (especially when TimeBeginPeriod is properly used)), it's much much better than sleeping for 10ms (maybe I'm a little biased because my needs require response time over CPU usage, but 10ms is an eternity for a computer)
(this said, I'm still in XE2, maybe the new memory manager has improved)


Edit: I'm checking the latest FastMM (assuming that's what in the latest Delphi).
The additional sleep time went from 10ms to 1ms, that's already better, but it's still sleeping all over the place.
BUT, while in XE2 it was just spinning.. now it's using SwitchToThread.. I don't know if that's any better.

Really, I believe the whole problem is that programmers have been told that locking was bad, and they try to avoid it at all cost, coming up with solutions that are worse than locking.
A critical section is a little spinning, + eventually the use of a semaphore. With little contention, it will only spin most of the time and will be very efficient. In the worst case, high contention, it will use the semaphore and make the thread wait. That wait is indeed bad, it's slow, as I wrote, can be dozens up to hundreds of microseconds, for kernel switch. So yes that's bad. But what's even worse than 100 microseconds? 10 milliseconds! The memory manager should use critical sections, period, OR better than this, period.

Edited by: fia starta on Aug 28, 2014 8:30 PM

Edited by: fia starta on Aug 28, 2014 8:43 PM

Attila Molnár

Posts: 7
Registered: 12/2/09
Re: Delphi's compiler
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2014 11:58 PM   in response to: fia starta in response to: fia starta
About multithreaded TPersistent : it should work in multithreaded environment, Delphi is not only for single threaded client side applications developer tool. Some part of rtl/vcl has to be pached to work correctly.

About Delphi MM : take a look at these links. Sure the default FastMM is not so great, but there are other options.

https://code.google.com/p/scalemm/
http://www.topsoftwaresite.nl/
http://www.delphifeeds.com/go/s/109849
http://www.delphitools.info/2011/10/13/memory-manager-investigations/

fia starta wrote:
It does not matter much since Delphi runtime, TPersistent class (or any derived from it), is not thread friendly at all. On its Destroy, it calls RemoveFixups(Self); and there is a global GlobalFixupList lock and unlock. They need to fix up the runtime codes

mmh ok, but how is that related?

You mean Delphi isn't efficient at multithreading, so no need to speed up the compiler?
Well: Delphi is efficient at multithreading.

I'm checking what you're talking about, seems like RemoveFixups is indeed using a TMonitor. And at a first glance, TMonitor seems to be bad, as opposed to a good old critical section.
Ok, but.. why would you create/destroy TPersistent-based classes in a thread anyway? Even doing that for any class is to be avoided anyway, I'd rather use records on the heap, or preallocated classes for this. Creating/destroying classes in a thread also involves the memory manager, and Delphi's memory manager is TOO not very thread-friendly (this because the guy behind it believes that critical sections are evil, and opted for a much much muuuch worse Sleep() option).

Talking about this, to those who don't know: if your app is multithreaded, switch this on:
NeverSleepOnMMThreadContention:=True;
It will make the memory manager spinning, which isn't as good as using a proper critical section (which is spinning + waiting for an event, which will involves, at worst, around 100 microseconds delays (especially when TimeBeginPeriod is properly used)), it's much much better than sleeping for 10ms (maybe I'm a little biased because my needs require response time over CPU usage, but 10ms is an eternity for a computer)
(this said, I'm still in XE2, maybe the new memory manager has improved)


Edit: I'm checking the latest FastMM (assuming that's what in the latest Delphi).
The additional sleep time went from 10ms to 1ms, that's already better, but it's still sleeping all over the place.
BUT, while in XE2 it was just spinning.. now it's using SwitchToThread.. I don't know if that's any better.

Really, I believe the whole problem is that programmers have been told that locking was bad, and they try to avoid it at all cost, coming up with solutions that are worse than locking.
A critical section is a little spinning, + eventually the use of a semaphore. With little contention, it will only spin most of the time and will be very efficient. In the worst case, high contention, it will use the semaphore and make the thread wait. That wait is indeed bad, it's slow, as I wrote, can be dozens up to hundreds of microseconds, for kernel switch. So yes that's bad. But what's even worse than 100 microseconds? 10 milliseconds! The memory manager should use critical sections, period, OR better than this, period.

Edited by: fia starta on Aug 28, 2014 8:30 PM

Edited by: fia starta on Aug 28, 2014 8:43 PM


Edited by: Attila Molnár on Aug 28, 2014 11:59 PM
fia starta

Posts: 9
Registered: 10/25/09
Re: Delphi's compiler
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2014 5:59 AM   in response to: Attila Molnár in response to: Attila Molnár
About Delphi MM : take a look at these links. Sure the default FastMM is not so great, but there are other options.

https://code.google.com/p/scalemm/
http://www.topsoftwaresite.nl/
http://www.delphifeeds.com/go/s/109849
http://www.delphitools.info/2011/10/13/memory-manager-investigations/

thanks
I had already tried ScaleMM & TopMemoryManager, and decided they weren't an option for me. I don't remember why exactly, maybe it had to do with higher memory usage (as that's an important factor too). But maybe they have improved since then.

What's the "NN" in this test, has it been released since then?
http://www.delphifeeds.com/go/s/109849

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02