From: bc@freeuk.com
On 30/10/2025 16:22, Scott Lurndal wrote:
> bart writes:
>> On 30/10/2025 14:13, Scott Lurndal wrote:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>> bart wrote:
>>>>> On 29/10/2025 23:04, David Brown wrote:
>>>>>> On 29/10/2025 22:21, bart wrote:
>>>
>>>>>
>>>>> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are:
>>>>>
>>>>> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make
>>>>>> output
>>>>>
>>>>> real 0m49.512s
>>>>> user 0m19.033s
>>>>> sys 0m3.911s
>>>>
>>>> Those numbers indicate that there is something wrong with your
>>>> machine. Sum of second and third line above give CPU time.
>>>> Real time is twice as large, so something is slowing down things.
>>>> One possible trouble is having too small RAM, then OS is swaping
>>>> data to/from disc. Some programs do a lot of random I/O, that
>>>> can be slow on spinning disc, but SSD-s usually are much
>>>> faster at random I/O.
>>>>
>>>> Assuming that you have enough RAM you should try at least using
>>>> 'make -j 3', that is allow make to use up to 3 jobs. I wrote
>>>> at least, because AFAIK cheapest PC CPU-s of reasonable age
>>>> have at least 2 cores, so to fully utilize the machine you
>>>> need at least 2 jobs. 3 is better, because some jobs may wait
>>>> for I/O.
>>>>
>>>> FYI, reasonably typical report for normal make (without -j
>>>> option) on my machine is:
>>>>
>>>> real 0m4.981s
>>>> user 0m3.712s
>>>> sys 0m0.963s
>>>>
>>>
>>> Just for grins, here's a report for a full rebuild of a real-world project
>>> that I build regularly. Granted most builds are partial (e.g. one or
>>> two source files touched) and take far less time (15 seconds or so,
>>> most of which is make calling stat(2) on a few hundred source files
>>> on an NFS filesystem). Close to three million SLOC, mostly in header
>>> files. C++.
>>
>>
>> What is the total size of the produced binaries?
>
> There are 181 shared objects (DLL in windows speak) and
> six binaries produced by the build. The binaries are all quite small since
> they dynamically link at runtime with the necessary
> shared objects, the set of which can vary from run-to-run.
>
> The largest shared object is 7.5MB.
>
> text data bss dec hex filename
> 6902921 109640 1861744 8874305 876941 lib/libXXX.so
Well, I've done a couple of small tests.
The first was in generating 200 'small' DLLs - duplicates of the same
library. This took 6 seconds to produce 200 libraries of 50KB each (10MB
total). Each library is 5KB as it includes my language's standard libs.
The second was to compile a single program of 7.5MB. This was done by
taking one 300KB project and duplicating one of the bigger source
modules a large number of times (130 copies for the 4.5MB result).
However that ran into some problems; possibly, running out of memory (I
have 6GB available), or something. In any case it's not worth my time
looking at it right now.
I did manage to produce a 4.5MB executable, and that took about 1
second. The total source code was 500K (about 9 bytes per source line;
how about that!)
To summarise:
Generate 200 x 50KB DLLS: 6 seconds (1.7MB/s) (1000Kloc so 170Klps)
Generate 1 x 4.5MB EXE: 1 second (4.5MB/s) (500Kloc so 500Klps)
This is on a machine that David Brown suggested was hopelessly old and
slow. All source code compiled was in my language.
I then did the same test using an existing C port of that library, with:
gcc -O0 -s -shared libnnn.c -o libnnn.dll
It took 72 seconds, with each DLL now being 100KB. Source code is the
bare library so only 1.7Lloc, giving a throughput of 4.7Klps.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
