Amiga-Development

Please login or register.

Login with username, password and session length
Advanced search  

News:

Created for developers of all Amiga camps

Pages: 1 [2] 3

Author Topic: Compile speed and binary size on AmigaOS 3  (Read 546 times)

0 Members and 1 Guest are viewing this topic.

Chain-Q

  • Newbie
  • *
  • Posts: 9
  • Stealth Ranger
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #15 on: August 04, 2017, 02:19:34 PM »

Such huge difference for the Vampire, and the reason your A4000 lacks behind, and the fact that my 060 is barely faster than an ACA 030 I think shows that vlink is somehow indeed RAM bandwidth limited, which is really strange. I can't really tell what's going on internally with vlink, but I already informed Frank Wille, the author of vlink. Maybe he has some ideas. Although it's hard to classify this as a bug.

An alternative would be to try to use GNU AS and GNU LD. But for that you need to rebuild the entire FPC package, because vasm/vlink works with ELF objects (for several technical reasons), while the old Amiga GNU AS/LD works with aout objects. The additional disadvantage would be to lose the "section smartlinking" feature, which means you would be back to the 260KiB hello world. We added vasm/vlink support precisely to reduce the end binary size.

There are also plans for internal assembler and linker in FPC for Amiga (it already exists for Win32, so the infrastructure is there), but these are waaay ahead in the future, unless someone steps up to work on it before I have to.
Logged

asrael22

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #16 on: August 04, 2017, 03:04:27 PM »

I think using vlink and vasm is fine.
Maybe Frank Wille has some ideas.


Manfred
Logged

ALB42

  • Moderator
  • Newbie
  • *****
  • Posts: 39
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #17 on: August 04, 2017, 08:05:32 PM »

for small one-unit program you could also use the online compiler ;) http://home.alb42.de/fpamiga/indexold.html works very nicely with IBrowse and much faster ;) I even use that mostly if only short/fast want to try something.
« Last Edit: August 04, 2017, 08:27:12 PM by ALB42 »
Logged

asrael22

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #18 on: August 04, 2017, 08:34:55 PM »

Well, it's not that I don't have a fast AmigaOs system available.
FS-UAE, or UAE in general is probably the fastest you can get.
But it's not the real thing.


Manfred
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #19 on: August 07, 2017, 12:47:11 AM »

In my experience, vasm/vlink is using about the same amount of memory that gnu tools are using (vasm/vlink can probably do with a lot less). Slow memory will most definitely show its colours there.

My first suggestion was to let you compile form ram as indeed mostly the delay originates from slow HD/Filesystem but slow ram for sure will not help there  :(

PS: Probably not something you are wanting to hear, but have you considered cross-compiling ? Free Pascal is pretty good (read: fast) at that  ;)
« Last Edit: August 07, 2017, 12:50:43 AM by magorium »
Logged

asrael22

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #20 on: August 07, 2017, 08:32:33 AM »

Hi.

Cross-compiling is not really an option. I'd like to code stuff in Cubic IDE (now that I've gotten used to the key shortcuts :).
I don't have a large project as of now, should I have that then I can also compile on UAE. On my Mac using FS-UAE the helloworld builds in 0.5 secs. Pretty fast.


Manfred
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #21 on: August 07, 2017, 12:05:13 PM »

ok, no problem asrael22.

It was just a suggestion. uae does the job just as well when really required (and in case you can live with that).

My memory cracks and crumbles... wasn't there something on classic with regards to adding buffers to a drive ? or was/is that for floppy only ?
Logged

Chain-Q

  • Newbie
  • *
  • Posts: 9
  • Stealth Ranger
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #22 on: August 07, 2017, 12:18:33 PM »

wasn't there something on classic with regards to adding buffers to a drive ? or was/is that for floppy only ?

There was, but it is mostly unrelated in this case. vlink is slow while working in memory. Actually, the recent versions are much faster, but the named sections feature (namely we put everything (all functions/data tables) in a separate section, so then the sections could be garbage collected during the final step, so the resulting executable can be small) puts some internal vlink architecture under loads it was not designed to take. Frank Wille already improved it a lot on our request by making it using hashtables instead of walking linked lists at some places, but I guess there's still room for improvement. But in fact, the entire section garbage collection was added on our request, so he supported us greatly in many ways already. But yes, further improvements should be done if possible, so it improves native compilation speeds.

BTW, this linking slowness also occurs on Atari TOS, where FPC also uses vlink, so it's not even Amiga specific, I think.
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #23 on: August 07, 2017, 01:35:51 PM »

Thank you for the clarification/elaboration on the topic Chain-Q !

You are far more proficient with/knowledgeable on (v)linker internals then i am, for sure.

fwiw: for me personally it is a bit of a non discussion as i usually cross-compile. I am aware of the pro's and con's of choices made, and am very happy with the vlinker/vasm support because their combination produces much smaller executables. (which for me is yet another non-discussion for the 'usual' targets).

Having said that, i am also aware of the importance of those improvements that were kindly made by Frank Wille as our Amiga related targets are a bit more underpowered. I don't think i could ever thank Frank enough for his work (and of course to you for bringing these issues to the attention of Frank).

tbh i was not aware that these (major) improvements were made on our behalf, so thank you for mentioning that aspect.

In my experience it is always a choice between evils, e.g. speed vs size / memory consumption and imho the trick with such things is usually to find a good balance between those two (or actually three).

Although i understand, i admit that i was truly surprised to see both gnu linker and vlink rapidly devouring about 200-300 mb of memory for (cross-)compiling a rather simple project. I never considered that it would take such huge amount of memory these days. I take it this is due to the same balance as i've mentioned above in my post ?
Logged

Chain-Q

  • Newbie
  • *
  • Posts: 9
  • Stealth Ranger
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #24 on: August 07, 2017, 02:06:44 PM »

Although i understand, i admit that i was truly surprised to see both gnu linker and vlink rapidly devouring about 200-300 mb of memory for (cross-)compiling a rather simple project.

Does this still happen? vlink had a huge memory leak in some versions with many sections, I could make it run out of RAM even on my MacBook which had 16G RAM. But this has been fixed in recent versions at least. Although there were several issues which were only MorphOS related (happenned in the ELF writer) and some only happenned on Amiga (HUNK writer), and I can't recall any more which was where. :)
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #25 on: August 07, 2017, 02:45:04 PM »

Latest version that i have tried/tested is vlink 0.16 from may.

Just to make sure that we are on the same page: the 'max' mem usage seems to be around 250mb on windows (and does not seem to be increasing beyond that 'magic' number and might be due to my compiled projects).
Logged

asrael22

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #26 on: August 07, 2017, 03:39:42 PM »

In my experience it is always a choice between evils, e.g. speed vs size / memory consumption and imho the trick with such things is usually to find a good balance between those two (or actually three).

Although i understand, i admit that i was truly surprised to see both gnu linker and vlink rapidly devouring about 200-300 mb of memory for (cross-)compiling a rather simple project. I never considered that it would take such huge amount of memory these days. I take it this is due to the same balance as i've mentioned above in my post ?
I would assume that how much memory is used for doing the job faster is determined on how much memory is available. If less is available more disk operations have to be done.

Manfred
Logged

asrael22

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #27 on: August 07, 2017, 03:41:58 PM »

It was just a suggestion. uae does the job just as well when really required (and in case you can live with that).

So, how is the cross-compiling being done, say, when I'm on Mac.
Can I cross-compile with FreePascal for a different target?


Manfred
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #28 on: August 07, 2017, 04:12:07 PM »

I would assume that how much memory is used for doing the job faster is determined on how much memory is available. If less is available more disk operations have to be done.
Yes, one would think that as it is most logical of choices...

... unfortunately practice for gnu linker (with default settings, i have no idea if gnu linker can be tamed that way) means that it takes everything that is available and simply crashes when running out of memory. Might be an platform specific issue though, but at least AROS and Amiga show this behavior.

Admittingly, i have not tried the same test with vlinker on native.

PS: i probably should rephrase myself and not put all the blame on gnu linker: the build process crashes/halts.
« Last Edit: August 07, 2017, 04:38:30 PM by magorium »
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: Compile speed and binary size on AmigaOS 3
« Reply #29 on: August 07, 2017, 04:25:57 PM »

So, how is the cross-compiling being done, say, when I'm on Mac.
To put it into very simple words (practice can sometimes be a bit tougher, especially since i have no hands on experience with mac):
- Download and install latest point release of Free Pascal for your Mac (native compiler)
- install (cross)-binutils
- download latest Free Pascal sources from trunk (or if you prefer download sources of latest stable point release of Free Pascal).
- compile the sources for your host (macOs). can be skipped if you want to use point release as you already installed that.
- cross compile the downloaded sources for preferred target(s) and add units/cross compiler to either your existing Free Pascal installation or the newly compiled FPC compiler that you compiled from trunk.
- Configure your installed Free Pascal correctly
- Open up an editor and write simple helloworld program.
- compile and/or cross-compile the helloworld example using preferred options for your target.
- copy compiled executable(s) over to your target(s).

Quote
Can I cross-compile with FreePascal for a different target?
Yes, see also steps mentioned above. e.g. not by default.

There are some wiki pages on that as well, see here

It might perhaps sound complicated but once you've done it once, it actually isn't. The most difficult part is to get the binutils into place (because usually they do not exist in a already compiled form).

In case you wish more detailed information for each step (or certain steps) then please feel free to ask. For me helping you it would be a bit trail and error, but perhaps ALB or Chain are able to chime in and offer some advise.
Logged
Pages: 1 [2] 3