.merges

.merge+ 7959 7960 7978 7976 7958 7954

Added

<hyc> "re:#7953 "There is no difference..." <- I believe he has a bias on storing the data externally, not on his SD card.

A new report is out: memory usage for compilation. It matters for parallel compilation, because you might run into a situation, when too many heavy files are being compiled on your rig with limited RAM. This will lead to a large deal of swapping.

Currently the average of 4 largest files is 2.56 GB per core.

The remedy would be splitting the large files into smaller chunks, which share similar dependencies.

Another idea would be to perform the build in 2 steps - one for the basic libraries with `nproc`, and one for the high level targets with just -j2

If you don't like moving code around that much.

Can confirm, I've had my laptop freeze during compilation by running out of memory after I went with -j `nproc`

for most typical PCs you'd need to break it down to at most 1GB per core

I tried this early on (back in 2016 or so) with little success

too much crap was implemented in header files, boost, etc

so even a minimal source file always had >1GB compilation overhead

<hyc> "too much crap was implemented in..." <- Tell me about it...

#6932 tries to tackle a part of the problem.

(a manageable part that is)

while it's been mostly just an inconvenience, it's a critical problem if you need to build debug binaries on windows

all of the cruft of templates etc results in unique symbols for each instance, and it overflows the symbol table of a windows .obj file

which maxes out at 32767 elements

it was basically impossible to get a debug build for windows until I did some surgery on things back in 2016

what you're working with now is better than it was then ;)

Does it not with -mbigobj or similar name ? I think it was that limit.

<hyc> "what you're working with now..." <- I can feel your pain.

bigobj only raised the limit from 32767 to 65535. still wasn't enough

(or something like that, I don't remember the exact details now)

selsta: Are you planning to fix the CI for OSX, since you own a Mac, or should I try instead?

I can't reproduce the issue locally unfortunately

will try again today to see if I can find the difference between environments

i've started working with my POWER9 workstation again. is anybody else here working with P9?

ullbeking: I've been playing with RISC-V; would be interested to see what Monero's efficiency is like on P9

fluffypony: I have to regain access to my P9 workstation, should be soon. I am interested in

seeing how to implement RandomX on P9

I heard there was some issue that prevents JIT on P9 on Linux?

hyc was playing with P9 a few years ago

in 2018 iirc

oh and tpearson actually managed to get a miner working I think

<selsta> "I can't reproduce the issue..." <- I'll try to manipulate `depends` to get that openssl 3

don't think it's depends related

thank you fluffypony

i wanted to develop bitcoin in 2015 and i got a job at a very corporate financial organization doing enterprise software engineering hoping to pivot to bitcoing devlopment internally, but that never happened. then other life things happened, i've just finished a six month contract, and now i'm jumping in the deep end of cryptocurrency development

selsta: I mean I will use depends to simulate what goes on on CI, by forcing the download of openssl3

i'm particularly interested in...

*locally

monero, bitcoin, and namecoin

mj-xmr[m]: right but the issue is related to homebrew and how cmake finds openssl, you likely won't trigger that with cross compiling

willl see. cmake is also used there.

I'm talking about this line

Thanks. That's some clue.

mj-xmr[m]: ok solved it, will PR a fix

ullbeking: there's a surprising amount of overlap in ideology among Bitcoin, Monero, and Namecoin, so not surprised to hear those are your areas of interest :)

fluffypony: really?! that's so coincidental!

why do you think this is?

probably a better convo for #monero, let's move it there :)

cool!

core tests are failing for this person, what kind of issue could this be? hardware issue, compiler, ... ?

correction, not core tests but other tests

no idea but i can try to repro it on my manjaro pinebook over the weekend, if it's not resolved before then

does the getmonero.org home page collect any metrics? such as page views?

no client side tracking

server side, don't know, use the Tor page if you worry about that

dMartian[m]: nothing server side, we've tuned most logging down to a bare minimum if anything

thanks fluffypony

I presume it's a given that tracker shortlinks to gemonero.org are antithetical in this community, so I wanted to see if there was any data recorded to compare against our marketing efforts