Watch, Follow, &
Connect with Us

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


Welcome, Guest
Guest Settings
Help

Thread: Linux server compiler features



Permlink Replies: 76 - Last Post: Nov 19, 2015 6:56 AM Last Post By: Dalija Prasnikar
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 3:37 AM
What compiler features you expect/want/need on Linux?

Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.

--
Dalija Prasnikar

Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 4:09 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Delphi is using 16 bit unicode because of Win api. What is used in Linux api
or kde gnome gui framework?

<Dalija Prasnikar> schrieb im Newsbeitrag
news:735395 at forums dot embarcadero dot com...

What compiler features you expect/want/need on Linux?

Personally, I could probably live with ARC (performance wise), but if
anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way
there.
UTF8 in -> UTF8 in the middle -> UTF8 out.

--
Dalija Prasnikar

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 4:13 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf Stocker wrote:
Delphi is using 16 bit unicode because of Win api. What is used in Linux api
or kde gnome gui framework?

I have no idea. But AFAIK Linux is currently planned for
server side only, so GUI frameworks do not matter.

--
Dalija Prasnikar
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 4:23 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

What compiler features you expect/want/need on Linux?

Firemonkey!

--
Regards,
Bruce McGee
Glooscap Software
Michael Justin

Posts: 1
Registered: 4/11/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 5:20 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:
Dalija Prasnikar wrote:

What compiler features you expect/want/need on Linux?

Firemonkey!

Well, FireMonkey actually is not a compiler feature. But who knows, maybe in the future it will be :)
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 10:53 AM   in response to: Michael Justin in response to: Michael Justin
Michael Justin wrote:

Bruce McGee wrote:
Dalija Prasnikar wrote:

What compiler features you expect/want/need on Linux?

Firemonkey!

Well, FireMonkey actually is not a compiler feature. But who knows,
maybe in the future it will be :)

I'm not limiting my response to compiler only features.

DataSnap would be the other, obvious choice, but that's not nearly as
controversial.

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 4:46 AM   in response to: Bruce McGee in response to: Bruce McGee
DataSnap would be the other, obvious choice, but that's not nearly as
controversial.

Good luck to offer Datasnap to Linux developers, and its utterly lack of security. Try to tell them that PC1 is a safe, well known encryption algorithm, and that encryption keys are fixed and stored locally...
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 5:41 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

DataSnap would be the other, obvious choice, but that's not nearly
as controversial.

Good luck to offer Datasnap to Linux developers, and its utterly lack
of security.

I see you haven't paid any attention to DataSnap outside of your narrow
use case.

Are you at least using a more recent version of Delphi?

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 8:39 AM   in response to: Bruce McGee in response to: Bruce McGee
I see you haven't paid any attention to DataSnap outside of your narrow
use case.

I paid a lot of attention to Datasnap. Under the "security" features, it didn't improve at all. Maybe your use cases are very simple and narrow, my requirements for security are pretty higher and broader.

BTW: how many Datasnap applications have you ever deployed? I have a now old one that fully relies on the old DCOM Datasnap implementation. That was then secure enough, thanks to DCOM built in security. The issue is the new Datasnap implementaion - especially when it can't rely on a web server HTTPS implementaion (not always you can ask to install a web server just for some remoting...)

Are you at least using a more recent version of Delphi?

No, we're moving most development to C++ for lack of real improvements for our needs. Sorry, no mobile apps here.

But I did use the trials, and couldn't see any improvement. Worse, the same basic mistakes have been made in the other remoting technologies.

You may not have noticed, but security is getting paramount importance lately, and today you can't really deploy security-flawed applications but for the most simple and useless tasks.

But feel free to explain me how much secure Datasnap is - and were to find a sound critpgraphic library in Delphi... (hint: Lockbox is the wrong answer).
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 9:56 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

I see you haven't paid any attention to DataSnap outside of your
narrow use case.

I paid a lot of attention to Datasnap. Under the "security" features,
it didn't improve at all. Maybe your use cases are very simple and
narrow, my requirements for security are pretty higher and broader.

Most of mine use HTTP, which secures very nicely.

I seem to remember that you didn't care because you only use TCP/IP and
didn't have a good strategy for storing keys. That sounds like a
narrower use case than mine.

BTW: how many Datasnap applications have you ever deployed?

More than a few.

Including some using the old architecture.

Are you at least using a more recent version of Delphi?

No,

That explains a lot.

we're moving most development to C++ for lack of real
improvements for our needs.

Good luck.

Sorry, no mobile apps here.

These aren't the only advances made, but maybe you don't use any of the
other stuff, either.

But feel free to explain me how much secure Datasnap is

We had a whole thread about that. Didn't you absorb any of it?

--
Regards,
Bruce McGee
Glooscap Software

Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 2:09 AM   in response to: Bruce McGee in response to: Bruce McGee
Most of mine use HTTP, which secures very nicely.

You forgot an S....

And no, it doesn't secure very nicely everywhere - especially since it relies on certificates, which, especially for client authentication, may be a big management overhead - but you authenticate clients, right? Have you ever had the need to impersonate the client security context on the server? Or the need for fully bidirectional connection?

And remember, installing a web server is not always an option for remoting - there are many situations where you don't want, or simply you can't. You have a very narrow view of remoting.

More than a few.

Good luck to your customers... I'd advise you to ask a professional to perform a VA.

That explains a lot.

Sure. It explains I can't trust the actual architecture for my data. Why should I spend thousand of dollars to get subpar security?

Good luck.

It works very well. Being server code, all the RAD part would be useless.

We had a whole thread about that. Didn't you absorb any of it?

Time to revist it, after the new releases you talked about, right? Or it is still in the abysmal state of old, so no need to revisit it?
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 6:13 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Good luck to your customers... I'd advise you to ask a professional
to perform a VA.

I have.

Have you?

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 6:59 AM   in response to: Bruce McGee in response to: Bruce McGee
Have you?

Yes. We do VA and pentest...
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 10, 2015 8:25 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 09.10.2015 um 17:39 schrieb Luigi Sandon:
I see you haven't paid any attention to DataSnap outside of your narrow
use case.

I paid a lot of attention to Datasnap. Under the "security" features, it didn't improve at all. Maybe your use cases are very simple and narrow, my requirements for security are pretty higher and broader.

BTW: how many Datasnap applications have you ever deployed? I have a now old one that fully relies on the old DCOM Datasnap implementation. That was then secure enough, thanks to DCOM built in security. The issue is the new Datasnap implementaion - especially when it can't rely on a web server HTTPS implementaion (not always you can ask to install a web server just for some remoting...)

Are you at least using a more recent version of Delphi?

No, we're moving most development to C++ for lack of real improvements for our needs. Sorry, no mobile apps here.

But I did use the trials, and couldn't see any improvement. Worse, the same basic mistakes have been made in the other remoting technologies.

You may not have noticed, but security is getting paramount importance lately, and today you can't really deploy security-flawed applications but for the most simple and useless tasks.

But feel free to explain me how much secure Datasnap is - and were to find a sound critpgraphic library in Delphi... (hint: Lockbox is the wrong answer).

Hello,

afaik datasnap nowadays supports more security wise than PC1!
Afaik it has at least a filter system where you can plug something in.
You might want to look here:
http://blogs.embarcadero.com/pawelglowacki/2013/10/16/40089

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 2:27 AM   in response to: Markus Humm in response to: Markus Humm
afaik datasnap nowadays supports more security wise than PC1!

Not out of the box unless you piggyback a web server. Even their RSA implementation is just the "easily exportable" one - an unsecure version.

Their finger to hide behind is that exporting cryptography needs a permission, so they can't - they would need some paperwork it looks they don't want to pay for. Let's see if Idera is less mean.

Afaik it has at least a filter system where you can plug something in.

Filters as designed are useless to implement proper security. Sure, you can manipulate the traffic, but you have no way to implement a proper cryptographic protocol to ensure the traffic gets properly encrypted. There is no support for handshaking - take a look at how TLS implements handshaking to secure the channel, and you understand why filters may be good for compression, and little else. You can't really encrypt traffic with a fixed key stored locally on both endpoints, and the same for every client.

Also Datasnap doesn't support any authentication method which is not user/password based. Instead of having a pluggable system able to support actual authenticatio methods which don't send the password (i.e. Kerberos...), it requires you to send a password to another system. Of course everything password as strings, because authentication data are only strings, never binary data, right?

No matter how much a channel is secure, sorry, I can't send password around for several reasons... it's 2015, not 1985 nor 1995.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 11:56 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 12.10.2015 um 11:27 schrieb Luigi Sandon:
afaik datasnap nowadays supports more security wise than PC1!

Not out of the box unless you piggyback a web server. Even their RSA implementation is just the "easily exportable" one - an unsecure version.

Their finger to hide behind is that exporting cryptography needs a permission, so they can't - they would need some paperwork it looks they don't want to pay for. Let's see if Idera is less mean.

Afaik it has at least a filter system where you can plug something in.

Filters as designed are useless to implement proper security. Sure, you can manipulate the traffic, but you have no way to implement a proper cryptographic protocol to ensure the traffic gets properly encrypted. There is no support for handshaking - take a look at how TLS implements handshaking to secure the channel, and you understand why filters may be good for compression, and little else. You can't really encrypt traffic with a fixed key stored locally on both endpoints, and the *same for every client
*.

Also Datasnap doesn't support any authentication method which is not user/password based. Instead of having a pluggable system able to support actual authenticatio methods which don't send the password (i.e. Kerberos...), it requires you to send a password to another system. Of course everything password as strings, because authentication data are only strings, never binary data, right?

No matter how much a channel is secure, sorry, I can't send password around for several reasons... it's 2015, not 1985 nor 1995.

Ok, if your information is current, then you have valid points.

Did you already talk with Marco Cantu about this matter?

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 6:44 AM   in response to: Markus Humm in response to: Markus Humm
Did you already talk with Marco Cantu about this matter?

Embarcadero is well aware of my complains about security in its remoting solutions. It's a pity this area is still overlooked.

Another issue is Delphi has no libraries to easy access Windows security APIs. I see CodeRage sessions using OpenSSL thorugh Indy and the like. OpenSSL is a widely used library, but under Windows it's not the standard one.

That means you have to update it for your customer every time a security fix is made available (and in the past months, after Heartbleed vulnerability and OpenSSL scrutiny, there have been a lot...), and your customers have to patch your application themselves outside the Windows update cycle. For customer who properly test applications before putting them in production, a stream of patches is not usually welcome.

Moreover, OpenSSL is not integrated with Windows certificate store, meaning you have to manage certificates (and protect private keys) yourself, and especially can't rely on Active Directory to easily distribute certificate (and revoke them). A little issue if you have a single web server, a not so little one when you have 50,000 clients each needing its own certificate to authenticate, also using a non flat PKI hierarchy.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 10:05 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi wrote:

Moreover, OpenSSL is not integrated with Windows certificate store

Not natively, no. However, it is possible to use Windows certificates
with OpenSSL using a little manual code. And IIRC there are some third-party
addons that integrate the Windows certificate store into OpenSSL.

--
Remy Lebeau (TeamB)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 10:57 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 16.10.2015 um 15:44 schrieb Luigi Sandon:
Did you already talk with Marco Cantu about this matter?

Embarcadero is well aware of my complains about security in its remoting solutions. It's a pity this area is still overlooked.

Another issue is Delphi has no libraries to easy access Windows security APIs. I see CodeRage sessions using OpenSSL thorugh Indy and the like. OpenSSL is a widely used library, but under Windows it's not the standard one.

That means you have to update it for your customer every time a security fix is made available (and in the past months, after Heartbleed vulnerability and OpenSSL scrutiny, there have been a lot...), and your customers have to patch your application themselves outside the Windows update cycle. For customer who properly test applications before putting them in production, a stream of patches is not usually welcome.

Moreover, OpenSSL is not integrated with Windows certificate store, meaning you have to manage certificates (and protect private keys) yourself, and especially can't rely on Active Directory to easily distribute certificate (and revoke them). A little issue if you have a single web server, a not so little one when you have 50,000 clients each needing its own certificate to authenticate, also using a non flat PKI hierarchy.

Hello,

there is a new http library/component added to Delphi now which uses the
platform apis on Windows afaik.

Greetings

Markus
John Kaster


Posts: 913
Registered: 9/22/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 1:01 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

there is a new http library/component added to Delphi now which uses
the platform apis on Windows afaik.

Correct. And also for iOS, OSX and Android.

Since you guys evidently didn't attend my CodeRageX talk:

https://github.com/jkaster/RTLPerf

Grab either my slides or my notes.

You will probably also be interested in:

WinAPI.Security.pas
WinAPI.Security.Credentials.pas
WinAPI.Security.Cryptography.pas

--
John Kaster http://johnkaster.wordpress.com
Software solutions
John Kaster


Posts: 913
Registered: 9/22/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 1:02 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Embarcadero is well aware of my complains about security in its
remoting solutions. It's a pity this area is still overlooked.

Overlooked by you, perhaps, but no longer by Embarcadero.

https://github.com/jkaster/RTLPerf

Grab either my slides or my notes.

You will also be interested in:

WinAPI.Security.pas
WinAPI.Security.Credentials.pas
WinAPI.Security.Cryptography.pas

Which are party of the DXS RTL.

--
John Kaster http://johnkaster.wordpress.com
Software solutions
Robert Love

Posts: 155
Registered: 5/3/07
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 5:57 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Afaik it has at least a filter system where you can plug something in.

Plug in filters can easily be implemented in an insecure way. Encrypting x number of bytes with a shared key is usually the examples given with filters.
Patterns in the data will arise because of it.
TLS 1.2 and protocols like it that use public key crypto to exchange a random symmetric key are far more secure.

Shared keys mean that the key typically has to be distributed with the client, which is only as secure as you can keep your clients, which is typically not secure.
One comprised client == all communication can be decrypted regardless of the client.
Robert Love

Posts: 155
Registered: 5/3/07
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 7:52 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
Try to tell them that PC1 is a safe, well known encryption algorithm, and that encryption keys are fixed and stored locally...

There are far more problems:

PC1 code references a website that does not exist anymore, but I found following C code that had the same url
http://xrootd.org/doc/githead/xrootd/src/XrdCrypto/PC1.cc

Form this I believe the code implements the algorithm published by Alexander Pukall on usenet in 1991, and the algorithm has
been studied since it was used with Kindle DRM.

The following paper is the Cryptoanalysis of the "Kindle" Cipher, which is same as PC1
http://orbilu.uni.lu/bitstream/10993/17072/1/Cryptanalysis%20of%20Kindle%20Cipher.pdf
Some quotes from the paper:
"We show devastating attacks against the PC1 cipher"
"This analysis shows that PC1 is very weak and probably made its
way into popular products due to the lack of academic cryptanalysis, which we
provide in this paper."

PC1 algorithm is not on the listed as a valid algorithm for PCI, FIPS, NSIT, or ISO compliance.

DataSnap however can use SSL/TLS with Indy and and can also use SSL/TLS via a web server. But you need to make sure you are using TLS 1.2 exclusively as all the other variants can
be exploited by POODLE and other attacks.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2015 12:35 PM   in response to: Robert Love in response to: Robert Love
Am 27.10.2015 um 03:52 schrieb Robert Love:


DataSnap however can use SSL/TLS with Indy and and can also use SSL/TLS via a web server. But you need to make sure you are using TLS 1.2 exclusively as all the other variants can
be exploited by POODLE and other attacks.

Hello,

how would I enforce TLS 1.2?

Greetings

Markus
Robert Love

Posts: 155
Registered: 5/3/07
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2015 3:58 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
how would I enforce TLS 1.2?

So with IIS you can use this free product, or you can figure out the various registry entries.
https://www.nartac.com/Products/IISCrypto

With Indy you set the SSLVersions property. Here is the demo code from my last coderage sessions where I discussed it.
https://github.com/rlove/Indy-SSL-Examples

although you should limit it to TLS 1.2 on client & server you really only need to do it with server as the POODLE exploit is due to a man in the middle causing you to downgrade from 1.2 to lower exploitable versions.
Robert Love

Posts: 155
Registered: 5/3/07
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2015 6:28 PM   in response to: Robert Love in response to: Robert Love
Robert Love wrote:
Markus Humm wrote:
how would I enforce TLS 1.2?
FYI- When it comes to DataSnap and TLS 1.2 unless your under IIS you have to do a lot work since TLS 1.2 is not defined in the interface.

https://quality.embarcadero.com/browse/RSP-12760
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 28, 2015 2:54 PM   in response to: Robert Love in response to: Robert Love
Am 28.10.2015 um 02:28 schrieb Robert Love:
Robert Love wrote:
Markus Humm wrote:
how would I enforce TLS 1.2?
FYI- When it comes to DataSnap and TLS 1.2 unless your under IIS you have to do a lot work since TLS 1.2 is not defined in the interface.

https://quality.embarcadero.com/browse/RSP-12760

Hello,

unfortunatelly I want to build something directly using DataSnap without
any IIS etc. so it's self contained.

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 8:10 AM   in response to: Bruce McGee in response to: Bruce McGee
Firemonkey!

Yes, all Linux server administrators will be happy to setup X and OpenGL just to configure or monitor an application... <G>

IMHO it's better if they re-addTurboVision....
Joseph Mitzen

Posts: 392
Registered: 6/9/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 2:56 PM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:
Dalija Prasnikar wrote:

What compiler features you expect/want/need on Linux?

Firemonkey!

It would need to be renamed Flaming Penguin to have a chance.
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 5:35 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?

- Not ARC, for sure (it would break a lot of existing code, running perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8), even if I'm fine with string=UnicodeString as long as I can define my own type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc 2 layout)
- share a lot of API headers with other POSIX targets

I'm currently spending a lot of time in FPC those days, and I can say that cross-platform integration of this compiler is just great.

AFAIC, a Kylix-level compiler with gcc 4/5 .o static linking would be just fine.
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 4:45 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
- Not ARC, for sure (it would break a lot of existing code, running perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8), even if I'm fine with string=UnicodeString as long as I can define my own type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc 2 layout)
- share a lot of API headers with other POSIX targets

And I would add, the most wanted:

- Linux 64 bit target.

Nowadays, all installed Linux systems are 64 bit, and Linux needs specific packages for running of 32 bit executables.
In short, running a 32 bit executable under Linux is more complicated than under Windows (which has a specific translation layer of all APIs).
Even if a Delphi executable has very few dependencies, my experiment is that running as native 64 bit app is a requirement under Linux.
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 1, 2015 7:24 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Kylix level would mean Delphi 6. The new Delphi 10.1/.2/.3 "Kylix" compiler
would have the same language features as the Win compiler.

<Arnaud Bouchez> schrieb im Newsbeitrag
news:735420 at forums dot embarcadero dot com...

Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?

- Not ARC, for sure (it would break a lot of existing code, running
perfectly on Windows or OSX).
- 8 bit strings (almost everything in C like API uses *char and UTF-8),
even if I'm fine with string=UnicodeString as long as I can define my own
type string(CP_UTF8).
- resource binding
- standard .map file for debug info
- .o static linking in latest gcc format (Kylix is tied to deprecated gcc
2 layout)
- share a lot of API headers with other POSIX targets

I'm currently spending a lot of time in FPC those days, and I can say that
cross-platform integration of this compiler is just great.

AFAIC, a Kylix-level compiler with gcc 4/5 .o static linking would be just
fine.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 2, 2015 6:43 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf Stocker wrote:

Kylix level would mean Delphi 6. The new Delphi 10.1/.2/.3 "Kylix"
compiler would have the same language features as the Win compiler.

I certainly hope so.

I want to be able to deploy a server to either Windows or Linux with as
little hassle as possible.

Mac, too, I suppose, but that's mostly just for completeness. I'm not
sure how many people are actually deploying Mac servers. I know I'm not
planning to.

--
Regards,
Bruce McGee
Glooscap Software
Cesar Romero


Posts: 462
Registered: 3/22/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 7:33 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:


What compiler features you expect/want/need on Linux?

Probably it will be almost the same as Mac OSX

[]s

Cesar Romero

Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 8:08 AM   in response to: Cesar Romero in response to: Cesar Romero
Probably it will be almost the same as Mac OSX

OSX is essentially a desktop OS. Linux today is essentially a server OS.

That means very different applications and very different loads. Do not expect a compiler optimized for GUI desktop applications to perform well on heavy server applications.
Cesar Romero


Posts: 462
Registered: 3/22/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 8:20 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

OSX is essentially a desktop OS. Linux today is essentially a server
OS.

That means very different applications and very different loads. Do
not expect a compiler optimized for GUI desktop applications to
perform well on heavy server applications.

Like the OP mentioned, I mean the compiler (and RTL implictly), not UI
Libraries.

Sorry if I was not clear enought.

Regards,

Cesar Romero

Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 8:26 AM   in response to: Cesar Romero in response to: Cesar Romero
Like the OP mentioned, I mean the compiler (and RTL implictly), not UI
Libraries.

Exactly. A compiler able to produce highly scalable multithread code is very important. And how object instances (and all memory management features) are managed is very, very important.

In OSX basically you have a single user application that may run a few threads. On a server, you may have thousands (or more) users running over as many threads as your CPUs allow. If the compiled and the RTL are not designed to handle it, you've got a big problem...

Delphi really needs to get rid of its Windows 3.1 desktop apps roots. It could work for mobile apps, it won't work for server applications. They should have noticed Windows became a valid server operating system since Window 2000, but they failed to do so...
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 1:48 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Delphi really needs to get rid of its Windows 3.1 desktop apps roots. It could work for mobile apps, it won't work for server applications. They should have noticed Windows became a valid server operating system since Window 2000, but they failed to do so...

I don't think this is true when it comes down to compiler (although it can certainly be improved). We all have seen Delphi based code kicking some Java and C# asses out there. Mormot, RealThinClient, kbmMW come to my mind. (here http://andremussche.blogspot.co.nz/2013/01/datasnap-ro-rtc-mormot-wcf-node-speed.html and here http://blog.synopse.info/post/2012/11/23/Speed-comparison-between-WCF,-Java,-DataSnap-and-mORMot are good resources). If DataSnap is slow, it has nothing to do with the compiler as we can see.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 2:42 AM   in response to: Alexandre Machado in response to: Alexandre Machado
I don't think this is true when it comes down to compiler (although it can certainly be improved).

Object and memory management is a compiler matter. Actually between the compiler (non ARC one) and the RTL the biggest issues are in the latter.

kicking some Java and C# asses

Under Linux, the competitors will not be nor Java nor C# nor Python. It will be GCC (also, under Windows the real competitor is VC++). And the RTL has to paly against libraries like the standard C library and Boost, which are usually far better optimized.

Anyway, if you want to convince someone used to free tools to pay for your not-so-cheap one, you have really to offer something really capable of outperforming the free tools. Otherwise, good luck to sell yours...
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 11, 2015 1:23 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Under Linux, the competitors will not be nor Java nor C# nor Python. It will be GCC (also, under Windows the real competitor is VC++)

I really don't get this. If Java is not in Linux servers nor in Windows servers where it is after all? Desktop? The same for C# on Windows...
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 1:57 AM   in response to: Alexandre Machado in response to: Alexandre Machado
I really don't get this. If Java is not in Linux servers nor in Windows servers where it is after all? Desktop? The same for C# on Windows...

Ask yourself. If ever Delphi targets Linux, who could be its prospect customers? Java developers? PHP/Python/Ruby developers? Same for Windows - with C# on the same level as Java.

On Linux, and other platforms, Java is the realm of large enterprise applications, especially thanks to products like Tomcat, WebLogic, WebSphere and the like - something that Delphi can't really offer. Raw speed is nor really the main issue for Java applications, the main issues are scalability, robustness and the like - especially often in the hands of not-so-skilled developers.

Nor Delphi is good to deliver web applications.

Thereby who could be the targer of a "Delphi for Linux"? Unluckily, it's the same target actually using GCC and writing C/C++ native applications. And it also needs to ask money, while all the rest is free.... where's the appeal?
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 3:02 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
On Linux, and other platforms, Java is the realm of large enterprise applications, especially thanks to products like Tomcat, WebLogic, WebSphere and the like - something that Delphi can't really offer. Raw speed is nor really the main issue for Java applications, the main issues are scalability, robustness and the like - especially often in the hands of not-so-skilled developers.

I can assure you that raw speed is a huge factor in a lot of SOA applications.
Once your SaaS applications start to have success, scaling abilities are the main question.
Vertical scaling is used in the Java world (more RAM and CPU, mainly to help GC process)...

I've worked for companies spending millions to get rid of Hibernate or SOAP just to gain raw speed.
Even writing some core component in raw C/C++, just to ensure best speed possible.

something that Delphi can't really offer
Nor Delphi is good to deliver web applications.

We developped the whole http://mormot.net framework just to write such large entreprise applications, following SOA principles.
I'm currently working on a huge cloud of mORMot servers, creating IoT interfaces following DDD principles, and it rocks.
I can assure you that in terms of ease of deployment and resulting performance, it is just great, when compared to classic Java servers: no JVM, low RAM and CPU consumption, per-node fast embedded databases.
Even the small MVC web part is very promising (but seldom used).

With Delphi, you have the benefit of C/C++ deterministic execution, with the ease of a high level language like object pascal, based on interfaces and SOLID.
With mORMot, you even get some unique features like asynchronous callbacks over websockets which allow to deploy large event-driven systems without the need to use a message queue or dedicated libraries like ZMQ.
It is not a J2EE compliant system, so would not be as a replacement but was definitively built as an alternative.
This is what is great with SOA, and today convention like REST or JSON: you could mix services, and let J2EE services consume mORMot REST services, if needed.

Thereby who could be the target of a "Delphi for Linux"?

Windows is an awfully complex system for plain servers - at least until the Nano Servers would come.
Linux is much easier to administrate and secure.
Windows 2012 updates are a real PITA for production servers.
And I would not put a Windows server on the Internet without a dedicated hardware firewall in front of it, or without a domain controller...
Last but not least, Windows licensing can be very pricey...

We currently use Kylix and FPC for Linux compilation of our mORMot servers.
An official "Delphi for Linux" may definitively help.
Especially when Embarcadero, just acquired by another DB company, would like to focus on entreprise solutions.
Joseph Mitzen

Posts: 392
Registered: 6/9/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 3:18 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Thereby who could be the targer of a "Delphi for Linux"? Unluckily, it's the same target actually using GCC and writing C/C++ native applications. And it also needs to ask money, while all the rest is free.... where's the appeal?

I can't believe you're the only one who gets this. I'm reminded of a web page that wanted to show how fast Delphi was and pitted it against PHP and some other interpreted languages, but not a single compiled one.

I've run benchmarks of Delphi code against GCC myself and on Linux (as opposed to Windows) GCC is very finely tuned; I've yet to see GCC do worse than double Delphi's speed (Linux/GCC vs. Windows/Delphi). CLang is catching up to GCC in optimization but it's not quite there yet (although it compiles much faster).

I've been asking for years for someone to share with me how they would pitch the case for Delphi to a Director of IT or CTO or CIO. I worked in a company that dealt with business-to-business sales for eight years and I don't know how you're going to pitch a slower, more expensive compiler vs. a faster, free one. On top of that, Linux users are not going to develop in a VM running Windows (in fact, no developers except Delphi developers develop in a VM in the first place). In fact, many Linux users don't use big, heavy IDEs; they use Vim or Emacs or Sublime Text and command-line utilities and SSHing into servers, etc. The development model of Delphi itself is rather alien to the world of Linux. While we're at it, static linking is shunned in the world of Linux (one reason why Kylix failed to attract any Linux users). Proprietary languages are shunned everywhere nowadays.

As usual, the only market I see is a fraction of the already existing Delphi market that wants to cross-compile to Linux. You're not going to generate any new customers out of this, so they're still stuck with milking the cow rather than expanding the user base (which would lower prices).
Josh Kelley

Posts: 75
Registered: 3/6/08
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2015 7:20 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
On 10/26/2015 6:18 PM, Joseph Mitzen wrote:
While we're at it, static linking is shunned in the world of Linux.

Nitpick: Static linking is traditionally shunned in the world of Linux,
but Go is gaining a lot of traction and is statically linked by default.

--
Josh Kelley
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Linux server compiler features [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 5:27 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

I don't think this is true when it comes down to compiler (although
it can certainly be improved).

Object and memory management is a compiler matter.

Not with manual memory management.

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

"I never miss a chance to have sex or appear on television."
-- Gore Vidal
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 12, 2015 3:04 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Probably it will be almost the same as Mac OSX

OSX is essentially a desktop OS. Linux today is essentially a server
OS.

For the compiler, why should that matter?

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

"Why do you sit there looking like an envelope without any
address on it?" -- Mark Twain
Joseph Mitzen

Posts: 392
Registered: 6/9/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 2:55 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
Probably it will be almost the same as Mac OSX

OSX is essentially a desktop OS. Linux today is essentially a server OS.

Linux is everywhere from embedded (e.g. routers) to supercomputers. In fact, 495 of the top 500 supercomputers in the world run Linux.

That means very different applications and very different loads. Do not expect a compiler optimized for GUI desktop applications to perform well on heavy server applications.

How would a compiler optimize for a desktop application? The difference between desktop and server loads is dealt with via the Linux kernel scheduler and not via application optimization. There are Linux schedulers optimized for responsiveness/latency at a small expense to performance and there are schedulers tuned for heavy loads. There are even experimental schedulers now that are optimized for SSD vs. HDD systems.
Radek Cervinka

Posts: 68
Registered: 11/5/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 11:31 AM   in response to: Cesar Romero in response to: Cesar Romero
Cesar Romero wrote:
Dalija Prasnikar wrote:


What compiler features you expect/want/need on Linux?

Probably it will be almost the same as Mac OSX


I am not sure, try binary search in
"c:\Program Files (x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers)
<ExePath Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/>
<ExePath Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>

and dccOSX is only for 32.

R.
Cesar Romero


Posts: 462
Registered: 3/22/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 8:35 AM   in response to: Radek Cervinka in response to: Radek Cervinka
Radek Cervinka wrote:

I am not sure, try binary search in
"c:\Program Files
(x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers) <ExePath
Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/> <ExePath
Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>

and dccOSX is only for 32.

I think we are talking about Compiler and RTL features, isn't?

Regards,

Cesar Romero

Radek Cervinka

Posts: 68
Registered: 11/5/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 9:08 AM   in response to: Cesar Romero in response to: Cesar Romero
Cesar Romero wrote:
Radek Cervinka wrote:

I am not sure, try binary search in
"c:\Program Files
(x86)\Embarcadero\Studio\17.0\bin\Borland.Build.Tasks.Delphi.dll"
for dccLinux and you get (with another strange compilers) <ExePath
Platform="Linux32" Path="%BDS%\bin\dcclinux.exe"/> <ExePath
Platform="Linux64" Path="%BDS%\bin\dcclinux64.exe"/>

and dccOSX is only for 32.

I think we are talking about Compiler and RTL features, isn't?

Sorry I don't understand.
I think that 32 or 64bit is main compiler (and of course RTL) feature. This is real hint that maybe 64bit Linux compiler can exists.
So if I thinking of 64bit, I know that only public 64bit compiler for x86 is Win64, not OSX (compiler features).

If you look at source code of RTL in current Delphi, there are many IFDEF POSIX, IFDEF LINUX and so on.

system.pas
  {$ELSEIF defined(LINUX)}
    {$IFDEF EXTERNALLINKER}
      {$DEFINE ZCX_BASED_EXCEPTIONS}
    {$ELSE}
      {$DEFINE PC_MAPPED_EXCEPTIONS}
    {$ENDIF}
  {$ELSE}


or
{$IF defined(LINUX64) and defined(CPUX64)}
function GetCPUType: Integer;
begin
  Result := CPUPentium;
end;
{$ENDIF LINUX64 and CPUX64}


This two example function is important (External linker?)
Cesar Romero


Posts: 462
Registered: 3/22/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 9:17 AM   in response to: Radek Cervinka in response to: Radek Cervinka
Radek Cervinka wrote:

Sorry I don't understand.

Linux compiler and rtl features in Linux will probably match features
with OSX compiler, unless the feature is specific of the platform.


I think that 32 or 64bit is main compiler (and of course RTL)
feature. This is real hint that maybe 64bit Linux compiler can
exists. So if I thinking of 64bit, I know that only public 64bit
compiler for x86 is Win64, not OSX (compiler features).

If you look at source code of RTL in current Delphi, there are many
IFDEF POSIX, IFDEF LINUX and so on.

Yes, a Linux compiler exists since Kylix, but I also think that we will
se another one anytime in future, some Embarcadero employees already
mentioned that "Linux compiler is a work in progress", it only was not
high priority to release.

Regards,

Cesar Romero

Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 8:05 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Personally, I could probably live with ARC (performance wise), but if anything,

On LInux, I do expect a compiler able to generate code able to perfrom well on a heavy multithread server application (see very little need for desktop apps, there). ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better...
Radek Cervinka

Posts: 68
Registered: 11/5/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 11:38 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
Personally, I could probably live with ARC (performance wise), but if anything,

ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better...

ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 11:49 AM   in response to: Radek Cervinka in response to: Radek Cervinka
Radek Cervinka wrote:
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).

There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).

ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.

And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.

ARC would break a lot of existing Delphi code.
Radek Cervinka

Posts: 68
Registered: 11/5/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 11:52 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
Radek Cervinka wrote:
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).

There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).

Yes I agreed, I am only compared ARC and GC. I have no problems with manual memory handling.

R.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 12:05 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud wrote:

And currently, ARC has some performance issues in Delphi RTL.

Some of those have been addressed in Seattle (but not as well as they could
have been, but it is a start).

--
Remy Lebeau (TeamB)
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 1:51 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
Radek Cervinka wrote:
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).

There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).

ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.

And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.

ARC would break a lot of existing Delphi code.

Agreed
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 12:50 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud Bouchez wrote:
Radek Cervinka wrote:
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).

There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).

ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.

And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.

ARC would break a lot of existing Delphi code.

Can't argue that.

Which brings me to conclusion that introducing ARC in mobile
compilers was wrong decision.

Having compilers that operate under different memory management is
not exactly optimal solution in the long run.

--
Dalija Prasnikar
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 10, 2015 2:24 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Arnaud Bouchez wrote:
Radek Cervinka wrote:
ARC is better option - you know when memory is freed. There many articles on net about problems with GC and performance (in servers and in games), you never know when GC start freeing memory (your app need more memory reserved - if I remember correctly about 3x more - and there same performance spikes, when GC starting).

There is nothing wrong with full manual memory handling, either via try...finally free or with (TComponent) ownership.
There are already several reference-counted types in Delphi (strings, interfaces, dynamic array), and copy-only values (variant).

ARC could also leak memory, mainly due to circular references issues.
GC could also leak memory, mainly due to long standing pointers.

And currently, ARC has some performance issues in Delphi RTL.
You could have very high multi-thread performance with current Delphi memory system.

ARC would break a lot of existing Delphi code.

Can't argue that.

Which brings me to conclusion that introducing ARC in mobile
compilers was wrong decision.

Having compilers that operate under different memory management is
not exactly optimal solution in the long run.

--
Dalija Prasnikar
Dalija Prasnikar wrote:
Having compilers that operate under different memory management is
not exactly optimal solution in the long run.

Indeed.

About ARC general discussion, circular references and zeroing weak pointers:
http://blog.synopse.info/post/2011/12/08/Avoiding-Garbage-Collector%3A-Delphi-and-Apple-on-the-same-side
http://blog.synopse.info/post/2012/06/18/Circular-reference-and-zeroing-weak-pointers
http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11
http://clang.llvm.org/docs/AutomaticReferenceCounting.html

The FPC team did discuss about ARC some months ago.
There is even a branch with a starting implementation.

The discussion is worth reading.
See http://lists.freepascal.org/fpc-devel/2014-October/034668.html

The main idea was to try to implement ARC in parallel with non ARC.
As I proposed in http://blog.synopse.info/post/2012/10/06/Delphi-XE3-is-preparing-reference-counting-for-class-instances :

But one issue of the implementation as previewed from XE3 sources (in addition to its alpha stage and poor performance) is that it is global to the application: the TObject memory model will be either ARC-based or manually handled (just like before).
This is a breaking change in the Delphi way of coding, and I would rather prefer a dedicated TObject / class type, able to coexist with the huge amount of third-party source code. Even if most user-level code may work with no issue (since Free will use the reference counting), some lower level code may be broken by such a change.
A dedicated class type may allow clear distinction between the "classic" model expecting manual Free of instances, and the new ARC model with its own style of coding.

I like very much the FreePascal approach, with its syntax modes: you can have several syntax and even class models in the same application. It is used for instance to mix objective pascal and classic pascal classes in the same project. Clean and easy.
It will also make the OS X integration much easier than the current interface-based marshalling of the Objective C APIs within Delphi. A lot of plumbing which should be leverage at compiler level.
I hope Embarcadero has such features on the road map, otherwise its future could be problematic: not compatible with legacy code (which is its main strength), and with no obvious benefit when compared to alternatives.
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 3:53 AM   in response to: Luigi Sandon in response to: Luigi Sandon
ARC is no performance killer. ARC <> GC!!!

<Luigi Sandon> schrieb im Newsbeitrag news:735476 at forums dot embarcadero dot com...

Personally, I could probably live with ARC (performance wise), but if
anything,

On LInux, I do expect a compiler able to generate code able to perfrom
well on a heavy multithread server application (see very little need for
desktop apps, there). ARC would be a real performance killer if it does
serialize a lot. Better a GC, then, I guess it could scale better. If they
avoid both a GC and ARC and implement a good multithreaded memory manager,
the better...
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 4:42 AM   in response to: Ralf Stocker in response to: Ralf Stocker
ARC is no performance killer. ARC <> GC!!!

I know they're different, still they both try to manage objects lifetime on your behalf and thereby has to find a way to keep track of them. And here lie the issues. Do it in the wrong way - i.e. the need of serializing accesses to shared structures - and you're going to kill performance especially on the kind of applications usually run on a server.

ARC may have little impact on client, user driven applications - but it may have far larger one on server application serving many connections. A GC, despite its overhead, may work better in that situation, if you really want automatic memory management.

OSX doesn't use ARC everywhere. Objective-C uses ARC, but a lot of OSX is not written in Objective-C. A good slice is written in C/C++. Anyway, OSX is not a server operating system, nor are its Apple applications.

C++ chose RAII because it doesn't need shared structures. although I don't like it too because it had to rely soon on all the "smart pointer" semantic to overcome its limits - some of which may hit serialization too (i.e. shared_ptr) - at least it's up to the developer to design its application properly and use them only when needed (or avoid them altogether if possible).

If they stay away from ARC and GC, and let developers manage memory - after all if you're developing a server application I hope you know what you're going to do - the better.
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 4:52 AM   in response to: Ralf Stocker in response to: Ralf Stocker
On Fri, 9 Oct 2015 03:53:54 -0700, Ralf Stocker <nospam at nospam dot org> wrote:

ARC is no performance killer. ARC <> GC!!!

well, they alleviated it to some extent, see http://blog.synopse.info/post/2015/09/14/Performance-issue-in-NextGen-ARC-model

--
Vladimir Ulchenko aka vavan
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 12:45 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
Personally, I could probably live with ARC (performance wise), but if anything,

On LInux, I do expect a compiler able to generate code able to perfrom well on a heavy multithread server application (see very little need for desktop apps, there). ARC would be a real performance killer if it does serialize a lot. Better a GC, then, I guess it could scale better. If they avoid both a GC and ARC and implement a good multithreaded memory manager, the better...

If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.

--
Dalija Prasnikar
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 2:51 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.

--
Dalija Prasnikar

If ARC has problem for performance . We can not edit compiler or RTL. And all of us are at a loss what to do.

So i wish supply two object model. TObject TARCObject. Supply ARC, but leave the right of choosing memory management to the programmers.

By the way. The hidden field for lockable object is really should be selected by the users.

e.g. TSomeObject = class lockable (TObject)
Only such object will have the hidden field and can be locked.
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 4:16 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
If ARC would be a problem from performance side, then I absolutely
prefer manual memory management.

--
Dalija Prasnikar

If ARC has problem for performance . We can not edit compiler or RTL. And all of us are at a loss what to do.

So i wish supply two object model. TObject TARCObject. Supply ARC, but leave the right of choosing memory management to the programmers.

By the way. The hidden field for lockable object is really should be selected by the users.

e.g. TSomeObject = class lockable (TObject)
Only such object will have the hidden field and can be locked.

You have already ARC: Strings, dyn. Arrays. Isn't it performant?
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 4:34 AM   in response to: Ralf Stocker in response to: Ralf Stocker
You have already ARC: Strings, dyn. Arrays. Isn't it performant?

Yes. You're right. We also have PChar, static array. Is it?
They are peaceful.

No one is forced to use String, not PChar.
I am very glad I can make a choice according to the need.
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 5:31 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
You have already ARC: Strings, dyn. Arrays. Isn't it performant?

Yes. You're right. We also have PChar, static array. Is it?
They are peaceful.

No one is forced to use String, not PChar.
I am very glad I can make a choice according to the need.

Don't fear! There is no performance penalty with ARC. (ARC <> GC)!!!

Edited by: Ralf Stocker on Oct 16, 2015 2:33 PM
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2015 6:31 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Don't fear! There is no performance penalty with ARC. (ARC <> GC)!!!

Actually, that isn't true. ARC does have a performance penalty compared to manual memory management, and how large it is depends on how the ARC workings are implemented. That's true for a GC has well.

ARC may use less memory than a GC, because it would usually release memory earlier than a GC does.

And one thing is to have reference counting for just some types of data, another is having it for each and every memory allocation. Then there are all the issue related to weak references and so on...
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 9:46 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?

Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.


Except UFT-8 is not an 8 bit string encoding scheme. It is a variable width
encoding scheme that a single code point can be up to 4 bytes long.

https://en.wikipedia.org/wiki/UTF-8

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Learning is finding out what you already know. Doing is demonstrating that you
know it. Teaching is reminding others that they know it as well as you. We are
all leaners, doers, teachers. (R Bach)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 10:16 AM   in response to: Jeff Overcash (... in response to: Jeff Overcash (...
Jeff wrote:

Except UFT-8 is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be up to 4 bytes
long.

The same can be said of UTF-16:

"Except UTF-16 is not a 16 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 2 or 4 bytes long."

The same can be said of Ansi, for that matter:

"Except Ansi is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 1+ bytes long."

--
Remy Lebeau (TeamB)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 9, 2015 12:46 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Jeff wrote:

Except UFT-8 is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be up to 4 bytes
long.

The same can be said of UTF-16:

"Except UTF-16 is not a 16 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 2 or 4 bytes long."

The same can be said of Ansi, for that matter:

"Except Ansi is not an 8 bit string encoding scheme. It is a variable
width encoding scheme that a single code point can be 1+ bytes long."

+1

--
Dalija Prasnikar
Chris Rolliston

Posts: 332
Registered: 4/6/00
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 8, 2015 3:38 PM   in response to: Jeff Overcash (... in response to: Jeff Overcash (...
Except UFT-8 is not an 8 bit string encoding scheme. It is a variable width
encoding scheme that a single code point can be up to 4 bytes long.

Dalija didn't suggest otherwise. '8 bit strings' = strings with 8 bit, 'AnsiChar' elements in Delphi-land. A UTF8 string type with 16 bit, 'WideChar' elements would be odd, no?
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 19, 2015 12:54 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
What compiler features you expect/want/need on Linux?

Personally, I could probably live with ARC (performance wise), but if anything,
8-bit strings are crucial on Linux server side. It is UTF-8 all the way there.
UTF8 in -> UTF8 in the middle -> UTF8 out.


Well, UTF8String and RawByteString will be supported on Linux, and they will
also find their way to mobile compilers. Great :)

But it seems that Linux compiler will also have ARC. Fine for me, too.

https://plus.google.com/u/0/+HoracioJoseCavalcantiFilho/posts/eKEEmp3tCjx

--
Dalija Prasnikar
Arnaud BOUCHEZ

Posts: 143
Registered: 2/17/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 19, 2015 1:13 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

I missed the end of the discussion.
A lot of material here.

Well, UTF8String and RawByteString will be supported on Linux, and they will
also find their way to mobile compilers. Great :)

Good sign.

But it seems that Linux compiler will also have ARC. Fine for me, too.

I'm NOT fine with that.
It would disallow to share the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is not an easy task... very time consuming, for little benefit.
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 19, 2015 1:28 AM   in response to: Arnaud BOUCHEZ in response to: Arnaud BOUCHEZ
Arnaud BOUCHEZ wrote:

But it seems that Linux compiler will also have ARC. Fine for me, too.

I'm NOT fine with that.
It would disallow to share the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is not an easy task... very time consuming, for little benefit.

I think that is because long term goal is to merge compiler features and
have ARC everywhere. And while pushing ARC on Windows may be
risky because of all existing code, ARC on Linux does not carry that burden
and it can be perfect place to polish and improve performance.

Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms. That is the main
reason why I am looking forward to ARC on Windows (eventually). You
cannot embrace full power of ARC if you have to make your code work
on non-ARC compilers too.

--
Dalija Prasnikar
Arnaud BOUCHEZ

Posts: 143
Registered: 2/17/02
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 19, 2015 1:31 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms.

I agree.
But on the contrary, I did not ask for ARC, nor needed it.
I'm fine with current memory management in Delphi.
Introducing ARC did break the Delphi platform.

See what I wrote to Allen in the G+ post.

If the Linux compiler would be ARC, it would be difficult to work with for me.
It would disallow to re-use the same code between Windows and Linux, for server apps.
Maintaining both ARC + not ARC low-level code is possible, but not an easy task... just to release the resources when needed, or do proper circular references, you would definitively need $ifdef $endif blocks... very confusing and time consuming, for little benefit.
If only ARC would be a compiler switch, for the whole project? If you need ARC, just use it. If you want to re-use an existing code base, disable ARC and use the "classic" mode.
If there is no efficient Linux debugger (I guess it would be GDB-based), it would be very difficult to track ARC-related issues. On server side, a memory leak is even worse than on desktop side! For mobile platforms, most of the memory is allocated via TComponent ownership - so ARC was only used at lower level. But for a server running 24/7, any resource or memory bug would be a nightmare to track.
I usually stabilize a server app under Windows, then cross-compile with Kylix (or FPC) to get the Linux version, which runs with no surprise. If there are two diverse models, it would be very time - and therefore money - consuming, for no benefit.´╗┐
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Linux server compiler features
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 19, 2015 6:56 AM   in response to: Arnaud BOUCHEZ in response to: Arnaud BOUCHEZ
Arnaud BOUCHEZ wrote:
Dalija Prasnikar wrote:
Having two memory management systems in place is pretty bad situation
for people that have to manage code across platforms.

I agree.
But on the contrary, I did not ask for ARC, nor needed it.
I'm fine with current memory management in Delphi.
Introducing ARC did break the Delphi platform.

Agreed.

While I am fine with or without ARC I am fully aware that ARC may
be problem for others.

Like I said having two memory management systems is unbearable and
from that POV I will welcome ARC everywhere. But I am still not sure
whether introducing full ARC compiler in the first place was good or bad decision
and I am more inclined to the later.

--
Dalija Prasnikar
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02