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
>
>
>> That will me an idea of
>> the true LoC for the project.
>
> There is really no relationship between SLoC and binary size.
Yes, there is: a rule of thumb for x64 is 10 bytes of code for line of C
source. But disproportional use of header files may affect that.
> There are about 16 million SLOC (it's been a while since I
> last run sloccount against this codebase).
>
> $ sloccount .
> Totals grouped by language (dominant language first):
> ansic: 11905053 (72.22%)
> python: 2506984 (15.21%)
> cpp: 1922112 (11.66%)
> tcl: 87725 (0.53%)
> asm: 42745 (0.26%)
> sh: 14333 (0.09%)
>
> Total Physical Source Lines of Code (SLOC) = 16,484,351
> Development Effort Estimate, Person-Years (Person-Months) = 5,357.42
(64,289.00)
> (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
> Schedule Estimate, Years (Months) = 13.99 (167.89)
> (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
> Estimated Average Number of Developers (Effort/Schedule) = 382.92
> Total Estimated Cost to Develop = $ 723,714,160
> (average salary = $56,286/year, overhead = 2.40).
>
> The bulk of the ANSI C code are header files generated from
> YAML, likewise most of the python code (used for unit testing).
> The primary functionality is in the C++ (cpp) code.
> The application is highly multithreaded (circa 100 threads in
> an average run).
>
>>
>> How many source files (can include headers) does it involve? How many
>> binaries does it actually produce?
>>
>>> $ time make -s -j96
>>> real 9m10.38s
>>> user 3h50m15.59s
>>> sys 9m58.20s
>>>
>>> I'd challenge Bart to match that with a similarly sized project using
>>> his compiler and toolset, but I seriously doubt that this project could
>>> be effectively implemented using his personal language and toolset.
>>
>> If what you are asking is how my toolset can cope with a project on this
>> scale, then I can have a go at emulating it, given the information above.
>>
>> I can tell you that over 4 hours, and working at generating 3-5MB per
>> second, my compiler could produce 40-70GB of binary code in that time,
>
> That's a completely irrelevent metric.
>
For me it is entirely relevant, as the tools I use are linear. If my car
averages 60mph, then after 4 hours I expect to do 240 miles.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
