Tag - FreePascal

Entries feed - Comments feed

2014-06-30

Sub-optimized Win64 Delphi compiler: missing branch table for case of

As we already stated here, the Delphi compiler for the Win64 target performs well, as soon as you by-pass the RTL and its sub-optimized implementation - as we do for mORMot.
In fact, our huge set of regression tests perform only 10% slower on Win64, when compared to Win32.
But we got access to much more memory - which is not a huge gain for a mORMot server, which uses very little of RAM - so may be useful in some cases, when you need a lot of structures to be loaded in your RAM.

Slowdown on Win64 is mostly due to biggest pointer size, which will use twice the memory, hence may generate a larger number of cache misses (failed attempts to read or write a piece of data in the cache, which results in a main memory access with much longer latency).
But in Delphi, apart from the RTL which may need more tuning about performance (but seems not to be a priority on Embarcadero side), is also sometimes less efficient when generating the code.
For instance, sounds like if case ... of ... end statements do not generated branch table instructions on Win64, whereas it does for Win32 - and FPC does for any x64 platform it supports.

Continue reading

2014-06-27

RoadMap refreshed

We did some cleaning in the mORMot official RoadMap.
Now feature requests tickets will detail all to-do items we would like to implement.

Current framework RoadMap and implementation is in fact going into a pragmatic direction.
No need to make all framework's unit compatible at once: so we introduced some client-dedicated units, without any dependency on SynCommons.pas.

We would like to implement (in this order):

The CrossPlatform folder already contains units which compile under all Delphi compilers (VCL and FMX), and FPC.

But perhaps we would move the server to Linux, either via FPC, or using Delphi itself!

Continue reading

2014-05-30

Software Design, Brook, mORMot, RAD, SOLID and OOP

We got a very instructive discussion in our forums, with Silvio, the maintainer of the Brook Framework.
Brook is a nice framework for writing web applications using Free Pascal.

It comes to my mind what mORMot can offer.
We did not want to compare the features or say that one framework is better than the other, but it appeared to me that a lot of object pascal programmers are tied to 20th century programming model.

In fact, to embrace the potentials of mORMot, you need to switch your mind, and enhanced your RAD and OOP background, into 21th century SOLID model.

Continue reading

2014-02-28

Think free as in free speech, not free beer

After more than 5 years of opening some huge part of Delphi code base, just my two cents.

Free software means free as a bird.

In practice, most Open Source "consumers" focus on free as a free beer...
This is a reality, especially for "niche" projects like developing libraries for Delphi.

Here are some thoughts from my little experiment with mORMot.
If you ask what Open Source for libraries mean, it may help you!

Continue reading

2013-09-19

FreePascal Lazarus and Android Native Controls

We all know that the first Delphi for Android was just released...

I just found out an amazing alternative, using native Android controls, and FPC/Lazarus as compiler and IDE.

It creates small .apk file: only 180 KB, from my tests!

It makes use of direct LCL access of Android native controls, so it is a great sample.

Continue reading

2013-05-11

Delphi XE4 NextGen compiler: using byte instead of ansichar?

When I first read the technical white paper covering all of the language changes in XE4 for mobile development (tied to the new ARM LLVM-based Delphi compiler), I have to confess I was pretty much confused.

Two great mORMot users just asked for XE4/iOS support of mORMot.

Win32/Win64 support for XE4 will be done as soon as we got a copy of it.
I suspect the code already works, since it was working as expected with XE3, and we rely on our own set of low-level functions for most internal work.

But iOS-targetting is more complex, due to the NextGen compiler, mainly.

Continue reading

2012-11-13

Go language and Delphi

Do you know the Go language?

It is a strong-typed, compiled, cross-platform, and concurrent.
It features some nice high-level structures, like maps and strings, and still have very low-level access to the generated code: pointers are there, in a safe strong-typed implementation just like in pascal, and there is even a "goto", which sounds like an heresy to dogmatic coders, but does make sense to me, at least when you want to optimize code speed, in some rare cases.

It is created/pushed by Google, used internally by the company in their computer farms, and was designed by one of the original C creators.

Continue reading

2012-10-06

Delphi XE3 is preparing (weak) reference counting for class instances

In Delphi, you have several ways of handling data life time, therefore several ways of handling memory:

  • For simple value objects (e.g.  byte integer double shortstring and fixed size arrays or record containing only such types), the value is copied in fixed-size buffers;
  • For more complex value objets (e.g. string and dynamic arrays or record containing such types), there is a reference counter handled by each instance, with copy-on-write feature and compiler-generated reference counting at code scope level (with hidden try..finally blocks);
  • For most class instances (e.g. deriving from TObject), you have to Create then Free each instance, and manage its life time by hand - with explicit try..finally blocks;
  • For class deriving from TInterfacedObject, you have a RefCount property, with _AddRef _Release methods (this is the reference-counted COM model), and you can use Delphi interface to work with such instances - see this blog article.
With Delphi XE3, we were told that some automatic memory handling at class level are about to be introduced at the compiler and RTL level.
Even if this feature is not finished, and disabled, there are a lot of changes in the Delphi XE3 Run Time Library which sounds like a preparation of such a new feature.

Continue reading

2012-08-28

"Trop c'est trop" - No Client-Server for XE3 PRO users

Here is some unbelievable news retrieved from "Te Waka o Delphi" blog:

From XE3 onwards, your Delphi Professional EULA will prohibit you from using Delphi Professional for anything other than local data access.
If you want to build client/server database applications using Delphi Professional, you will be required to purchase a “Client/Server Add-On” pack.

This goes beyond the fact that you do not get (or can otherwise use or install) client/server drivers for the DBExpress or other “built in” data access frameworks, but extends even to 3rd party data access technologies.
That is, whatever you may be able to do or achieve – technically – using some 3rd party component or library with you Delphi Professional compiler, you cannot legally create a client/server application.
Never mind any 3rd party components or libraries, this same prohibition will apply even if you are using naked, unadorned Microsoft ADO.

Damn show-stopper for me.
Embarcadero is killing Delphi.

Our very own mORMot Open-Source framework is fully Client-Server oriented, and allow creating scalable Client-Server applications even with an Oracle DB system back-end, even with XE2 starter edition (direct access, without any DB.pas / DBExpress layer).

Continue reading

2011-12-04

Total Commander 64 bit is using... Lazarus and FPC

I'm a long-time registered user of Total Commander.

This tool is my daily file manager. I never use Windows Explorer, since Total Commander is just faster, more easy to use (especially with the keyboard), has a lot of plug-ins. I even created my own plug-ins to access some custom file formats, and navigate into them just like with any folder. And it includes a lot of well written commands for FTP access or file comparison, which made other tools (like WinMerge) unnecessary.

There is a new beta version of Total Commander available, which targets Windows 64 bit. I just thought: 'Whoo, this is a real-world Delphi XE2 64 application'. I downloaded and tried it. Worked as expected, and integrates seamlessly with Windows Seven (for the shell extensions). Then I took a look at the executable... and discovered it was not compiled with Delphi XE2... but with FPC !

Continue reading

2011-08-08

Our mORMot won't hibernate this winter, thanks to FireMonkey

Everybody is buzzing about FireMonkey...

Our little mORMot will like FireMonkey!
Here is why...

Continue reading

2011-05-26

Calling a 64 bit library from a Delphi 32 bit process

Since we are still waiting for a Delphi 64 bit compiler, the only available solution to access a 64 bit library from an application written in Object pascal, is to use the 64 bit version of the FreePascal Compiler.

But you just can not recompile your VCL/GUI based Delphi application with FPC:

  • Some low-level part of your code may not be directly compatible with a 64 bit process (e.g. since the pointer size changed);
  • The GUI part of the application can not be ported directly with FPC - the Lazarus project try to be as close as possible to VCL, but it can be a very difficult, either impossible if you use some third-party components.
I just found out a solution from CodeCentral, allowing to call any 64 bit dll from a Delphi 32 bit process.

Continue reading

2010-08-14

FPC and Delphi: toward a "fratricidal war"?

Speaking about [upcoming] 64 bit Delphi compiler, I did forecast they will surely release their compiler 5 years later than FPC's... hoping they will follow the FPC way, just as Intel did about 64 bits instructions, against AMD.

What I was referring to is that AMD was the first to publish a 64 bit x86 CPU, with a new instruction set. Intel released somewhat later their own 64 bit x86 CPU, following the same instruction set.
There are some variants between AMD and Intel CPU, some dedicated instructions or implementations.
But most instruction set is perfectly compatible.

And I suspect the more it gets, the less compatible FPC and Delphi will be.

The main difference between Delphi and FPC is that the first is a business company project (Embarcadero), the second an Open Source solution. They are not two billions dollars companies fighting each other, with some state-level institutions watching about any unfair competition or monopoly... FPC compiler is technically a great and robust project, but EMB follows business rules. I don't think anyone will play "Anti-monopoly" in favor of FPC.

Continue reading

2010-08-10

Writing Delphi code for 64 bits compiler

There will be an upcoming 64 bits Delphi compiler. Embarcadero promised it.

Florian (the architect of FPC) showed a first "Hello world" program for Win64 in March 2006.
This was remarkable since GCC and the binutils don't even support this target at this time.
In fact, FPC used its Internal linker on Win32 and Win64 platforms, just like Delphi does.

Here are some points on how you could make your code ready to compile under FPC 64 bits, therefore (I hope) under future Delphi 64 bits compiler.

Continue reading

2010-08-06

Save object, stop class hegemony!

In a recent thread in the Embarcadero Discussion Forums, Vedran Vuk posted some questions about object keyword.
His purpose was to use object instead of class to improve speed and memory consumption: 

I do use classes. I just want to use objects on smaller classes that don't really need initialization or RTTI. Plus, I can directly operate on it like a record with no need for constructors and it can be sealed and has inheritance. Every byte matters in this case.

Rudy posted on the EMB forum that

The "object" type is deprecated. As was said, it mainly exists for compatibility with old Turbo Pascal. That is why it is not documented very well. It's use is not promoted.

I have the same requirement sometimes, for example for our framework or for low-level units.
I do like such plain-old object type, and don't want to see this object feature marked as deprecated in future EMB versions.

Continue reading

page 3 of 3 -