Lazarus on Cortex a53

[superc]

Hello,

I'm watch an interesting board (RockPi e) based on Rockchip RK3328, I would like to know from you, if Lazarus can be used with this processor,
 thanks in advance.

[af0815]

a Cortex a53 is similar to a RasPi3 CPU, so it looks it is possible for fpc. Lazarus is the IDE, fpc is the compiler.

[TRon]

I'm watch an interesting board (RockPi e) based on Rockchip RK3328, I would like to know from you, if Lazarus can be used with this processor,

If your question is truly about /can/ then yes if you question is if it is feasible to develop on the machine itself with Lazarus then most probably no. The E edition comes with a max of 2Gb of memory which is about the amount of memory required to rebuild Lazarus (and your OS needs some of that 2Gb memory as well). So unless wanting to do a lot of swapping I would not recommend using it to develop with Lazarus on the machine itself. Other than that from a development perspective it is just a Linux machine (it runs debian/ubuntu) with some extra hardware (probably not supported by FPC ootb).

[superc]

Thank you for the replies, now i will try to create a small example server program with the crosscompiler and make a small report in the forum.

[af0815]

crosscompiling to such a device is one of the best choices. Be careful and use the correct libs for linking. I think you will use the Debian distribution for this device. https://rockpi.eu/RockpiE

[superc]

ok , compiled a simple 'hello world' command line program with fpc 2.2.6: target CPU family AArch64 and linux for os.....
I don't understand why it works with this CPU target, so I'll try to do more tests and then report the result, thanks again.

[TRon]

I don't understand why it works with this CPU target, so I'll try to do more tests and then report the result, thanks again.

It seems like a stupid question but why do you not understand ?

aarch64 is arm 64-bit (Linux) and that is exactly what CPU your hardware has (ArmV8) and I assume the operating system that you have running is 64-bit (as well).

[JuhaManninen]

The E edition comes with a max of 2Gb of memory which is about the amount of memory required to rebuild Lazarus (and your OS needs some of that 2Gb memory as well).

I remember people built and used Lazarus in Raspberry Pi with half a GB memory.
I personally still use an e-machines x86 mini-laptop with 1 GB memory and MX Linux. Lazarus builds without problems while Firefox browser is also open.
Swap partition is needed which can be slow indeed in a card computer.
Anyway the swapping algorithms of Linux are clever.

[TRon]

I remember people built and used Lazarus in Raspberry Pi with half a GB memory.

Done so myself on a Pi 3B and 3B+ (though that has a whole GB) 

I am not in disagreement with what you wrote (it is possible) except that indeed when using a micro sd card it is a real PITA.

Also note that the memory hungry-ness (is that even a word ?  ) of a Lazarus rebuild has grown (and seem to be growing) by/for each new release. It was (relatively speaking) fine with 2.2.4 but grew extensively with 2.2.6 and practically undoable with 3.0RC1 (improvements seem to come with a price  ).

I would personally promote cross-compiling in/for such cases but also realize that it also depends on the actual (used) specifications (which afaik we currently do not know).

[superc]

I don't understand why it works with this CPU target, so I'll try to do more tests and then report the result, thanks again.

It seems like a stupid question but why do you not understand ?

aarch64 is arm 64-bit (Linux) and that is exactly what CPU your hardware has (ArmV8) and I assume the operating system that you have running is 64-bit (as well).

Hello,
for the raspberry pi3 b+ I have to select (if I remember correctly) Arm as target cpu: this processor is an arm why should I select aarch64? I expected the settings to be the same as the RP but I tried and it doesn't work.

[TRon]

@superc:
Back in the day (i do not know for sure if you refer to those days as well) there was only a 32 bit OS available for the pi3. It was not until later that the 64 bit version emerged.

For a more detailed answer, see for example this SO question (first answer) but you can also have a peek at the wikipedia entry. I agree that using different naming schemes for basically the same thing is a bit confusing.

[superc]

@superc:
Back in the day (i do not know for sure if you refer to those days as well) there was only a 32 bit OS available for the pi3. It was not until later that the 64 bit version emerged.

For a more detailed answer, see for example this SO question (first answer) but you can also have a peek at the wikipedia entry. I agree that using different naming schemes for basically the same thing is a bit confusing.

Thanks, now I understand the situation. 

[JuhaManninen]

Also note that the memory hungry-ness (is that even a word ?  ) of a Lazarus rebuild has grown (and seem to be growing) by/for each new release. It was (relatively speaking) fine with 2.2.4 but grew extensively with 2.2.6 and practically undoable with 3.0RC1 (improvements seem to come with a price  ).

That is unexpected. At least 2.2.4 -> 2.2.6 should make no difference to build time. It only added bug fixes.
3.0 has new code and packages but still the difference should not be so dramatic.
Building has 2 parts, compilation and linking. Which one hogs memory? I guess linking.
Have you compared with the exact same set of packages installed?
If the compilation part hogs memory, it may be caused by parallel compilation of packages. By default the IDE uses as many threads as there are CPU cores but it can be adjusted.

[TRon]

That is unexpected. At least 2.2.4 -> 2.2.6 should make no difference to build time. It only added bug fixes.

If I remember correctly (I do not measure each and every time I installed a component) it went from around 1.2~1.4 to 1.8gb. Before 2,2,4 it was around 800 MB.

Measured (or actually more eyeballed but with min and max presented)  with system monitor (standard desktop tool).

Building has 2 parts, compilation and linking. Which one hogs memory? I guess linking.

The peak seem to be at the compilation but when that is running down the linker picks up the 'hogging'. Overall the linking seem to be using less memory than the compilation (except for that one last step).

I have never searched/looked for the real reason(s) as I have assume that is the nature of progress (at least when it comes to software).

If you are aware of any available measuring methods that could provide us with (more/better) useful information then please do share. As said I never paid that much attention to it so am not that familiar how to measure such things in a more accurate manner.

Have you compared with the exact same set of packages installed?

No, not really. It is something that you become aware of when using the setup as a daily driver and try to install some (or a) package(s) as the time it takes to rebuild increases. That is why I was never fond of installing packages in the IDE when using the Pi. 15-20 minutes of your life waiting for a rebuild is 15-20 minutes wasted.

Do note that I am not complaining, just observing and trying to prevent people from running into the same issues that I was running into. The more modern SBC's are much more powerful and have better/faster storage facilities (not to mention usually more memory).

If the compilation part hogs memory, it may be caused by parallel compilation of packages. By default the IDE uses as many threads as there are CPU cores but it can be adjusted.

You are right on that. The compilation process is opportunistic in that it takes what it can get. I never measured the difference between the two so perhaps should pay attention to that.

If this is something that is close to your heart or wish to pursue then I'm more than happy to run some tests. If even to proof me wrong Other than that and for me personally, it does not have any priority for me.

[JuhaManninen]

If this is something that is close to your heart or wish to pursue then I'm more than happy to run some tests. If even to proof me wrong Other than that and for me personally, it does not have any priority for me.

Performance and speed of programs are close to my heart. That is why I like compiled Pascal instead of languages with GC, virtual machines, interpreters etc.
The bloat has crept also to Lazarus project, true. SW is usually developed in fast machines and the attitude is to rely on them getting yet faster.
I was able to reduce the startup time of the IDE in some commits. I like snappy apps that start quickly.

I have not paid attention to the compilation or link times. It sounds alarming if they went up so much.
I can do some experiments with my e-machines mini-laptop when I have time and energy. The mini-laptop has Intel Atom CPU and was bought in 2009. The battery is not so good any more and many web pages are getting sluggish with it. The bloat is creeping to web pages, too. Annoying!

Note, there are 2 different build systems for the Lazarus IDE. Makefiles and a built-in system in the IDE. Did the slowdown happen in both?