Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Sun, 28 Apr 2024 03:59:28 -0500
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <v0l35j$v8sl$1@dont-email.me>
References: <dd1866c4efb369b7b6cc499d718dc938@www.novabbs.org>
 <acq62j98dhmguil5ebce6lq4m9kkgt1fs2@4ax.com>
 <kkq62jppr53is4r70n151jl17bjd5kd6lv@4ax.com>
 <9d1fadaada2ec0683fc54688cce7cf27@www.novabbs.org>
 <v017mg$3rcg9$1@dont-email.me>
 <da6dc5fe28bb31b4c73d78ef1aac2ac5@www.novabbs.org>
 <sdl82jpkpf1t0ctr8sgqm5bvqqireg08j5@4ax.com>
 <44fdd1209496c66ba18e425370a8b50d@www.novabbs.org>
 <ks8e2j1kquqpcupcgh32es7nci33nlajid@4ax.com>
 <ec69999967361c286afdbe60bc2443ea@www.novabbs.org>
 <dtel2j5kipf6tj9cabgp7pqk8eei14eo1a@4ax.com> <v0euek$3a2rc$1@dont-email.me>
 <ff78aaa73101509100f09f190838a2a7@www.novabbs.org> <IQSWN.4$nQv.0@fx10.iad>
 <v0jlf3$i3mh$2@dont-email.me>
 <3458ae0a6b7c1f667ef232c58569b5e1@www.novabbs.org>
 <v0k2kb$l21r$1@dont-email.me>
 <58f8e9f6925fd21a5526ea45fae82251@www.novabbs.org>
 <v0kodk$t520$1@dont-email.me> <v0ksrk$u1j2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 28 Apr 2024 10:59:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="437e2caa7a0d326db2a3a89ac4546326";
	logging-data="1024917"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18w9RyjH5JiRd/KShv7j2g89eI2amPVED4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZJeCb7Tk/mFQrQjGq0ShxG3CKWw=
Content-Language: en-US
In-Reply-To: <v0ksrk$u1j2$1@dont-email.me>
Bytes: 6249

On 4/28/2024 2:11 AM, BGB wrote:
> On 4/28/2024 12:56 AM, BGB wrote:
>> On 4/27/2024 8:45 PM, MitchAlsup1 wrote:
>>> BGB wrote:
>>>
> 
> ...
> 
>>
>>>>>> I guess some people are dragging their feet on FDPIC, as there is 
>>>>>> some debate as to whether or not NOMMU makes sense for RISC-V, 
>>>>>> along with its associated performance impact if used.
>>>>>
>>>>>> In my case, if I wanted to go over to simple base-relocatable 
>>>>>> images, this would technically eliminate the need for GBR reloading.
>>>>>
>>>>>> Checks:
>>>>>> Simple base-relocatable case actually currently generates bigger 
>>>>>> binaries, I suspect because in this case it is less 
>>>>>> space-efficient to use PC-rel vs GBR-rel.
>>>>>
>>>>>> Went and added a "pbostatic" option, which sidesteps saving and 
>>>>>> restoring GBR (making the simplifying assumption that functions 
>>>>>> will never be called from outside the current binary).
>>>>>
>>>>>> This saves roughly 4K (Doom's ".text" shrinks to 280K).
>>>>>
>>>>> Would you be willing to compile DOOM with Brian's LLVM compiler and
>>>>> show the results ??
>>>>>
>>>
>>>> Will need to download and build this compiler...
>>>
>>>> Might need to look into this.
>>>
>>> Please do.
>>>
>>
>> Extracting the ZIP file and "git clone llvm-project" etc, have thus 
>> far taken hours...
>>
>> Well, and then the commands to CMake were not working, tried invoking 
>> cmake more minimally, and it gives a message complaining about the 
>> version being too old, ...
>>
>> Seems I have to build it with a different / newer WSL instance (well, 
>> I guess it was either this or try to rebuild CMake from source).
>>
>>
>> Checks, download for compiler (+ git cloned LLVM) is a little over 6GB.
>>
>>
>> Well, OK, now LLVM is building... I guess, will see if it compiles and 
>> doesn't explode in the process. Probably going to be a while it seems.
>>
> 
> 
> 
> A little over an hour later and it still hasn't broken 50% yet...
> 
> I think LLVM rebuilds may have actually gotten slower than in the past...
> 
> 
> Well, at least my 112GB of RAM means it isn't swapping too much...
> 
> Computer is a little sluggish and the "System" process seems kinda 
> pegged out though...
> 
> 
> 
> I guess I will know sometime later whether or not all of this builds...
> 
> 

Still watching LLVM build (several hours later), kinda of an interesting 
meta aspect in its behaviors.

Sub-stage 1:
cc1plus processes, they start out mostly idle, sit around idle for a few 
seconds, CPU activity spikes and then they terminate (and a new one 
spawns to take its place).
During this sub-process, PC is generally sluggish.

Sub-stage 2:
"llvm-tblgen" runs; these processes are short lived and run at high CPU 
load; but PC stops being sluggish for the brief moments it is running 
these (but, soon enough, it is back to the former stage).


Overall CPU load is fairly modest, and HDD activity is also fairly 
reasonable. Seems like there is a bottleneck that "cc1plus" steps on.

The "System" process runs at somewhat higher than usual CPU load (~ 8%), 
process description "NT Kernel & System", where spikes in this process 
seem correlated with the "general sluggishness".


Seems likely related to the "teh crapton" of files it contained...
Also does not escape my notice that on the build drive in question, it 
has seemingly eaten over 100GB of disk space during the build project...


Like, seemingly, LLVM has managed to somehow become more absurd than it 
was in the past...

Dunno, maybe all this seems like pretty reasonable project design to 
some people, but at least to me, it all seems a little absurd.
Well, unless some people experience it building quickly and not eating 
huge amounts of HDD space.

Dunno, maybe related to me running the build on a drive with "Folder 
Compression" enabled?... (Often times, folder compression makes things 
faster, but this might be one of the times where it doesn't).


Some of this is kind of a disincentive to trying to build a compiler 
based on LLVM though. Trying to have this as a normal part of the build 
process seems implausible.

Like, if it makes Vivado synthesis and implementation seem fast and 
lightweight in comparison, this is not an ideal situation...

GCC is an ugly mess, but at least it builds moderately faster.

....