< bitcoin-git> [bitcoin] dongcarl opened pull request #19685: depends: CMake invocation cleanup (master...2020-08-depends-misc) https://github.com/bitcoin/bitcoin/pull/19685
< sipa> random observation: on my 4-core 8-thread machine with 32 GiB of RAM, the functional tests run fastest with -j64
< sipa> 187s clock time, while -j6 needs 270s
< sipa> eh, -j8 needs 270s
< tryphe_> because of SMT? but 50% faster seems crazy for just throwing in more threads
< sipa> tests contain lots of sleeps
< tryphe_> ahh, wasted time
< sipa> while the python side is waiting for bitcoind to finish something
< sipa> they're generally very short sleeps (0.1s and less), but they add up
< phantomcircuit> sipa, there's lots of sleeps in the functional tests
< phantomcircuit> jynx sort of
< jeremyrubin> FYI there seems to be some issues with s390x testing
< jeremyrubin> WHere can I even get a s390x mainframe? Who the heck is using that
< sipa> you can get a free shell account on some ibm site
< luke-jr> jeremyrubin: I think the point is to have a BE build, not so much for the s390x
< sipa> yes of course
< sipa> it's the only BE platform on travis
< sipa> afaik
< jeremyrubin> oic
< wumpus> right, testing on BE can find some cases of implementation-defined / undefined behavior that we missed, the specific architecure doesn't matter
< wumpus> (thoug hhaving an actual CPU is nice, isntead of emulation, which is too slow to run the entire test suite in time for CI)
< luke-jr> too bad Linux doesn't support BE binaries on LE kernel
< luke-jr> though perhaps it'd be possible to do KVM on ppc64le -> BE
< wumpus> indeed, some architectures potentially support switching LE/BE between processes but Linux definitely doesn't support this
< wumpus> yes maybe with virtualization
< wumpus> while the python side is waiting for bitcoind to finish something <- this is true, but it's still somewhat surprising because you'd expect at least one thread of bitcoind to be busy 100%, otoh, it might also be waiting in turn for I/O or such
< luke-jr> hmm
< luke-jr> can qemu do user-mode virtualisation? lol
< wumpus> I just mean, the python script waiting for things to complete doesn't in itself mean that the tests are not CPU intensive
< wumpus> user mode virtualization, heh
< wumpus> paravirtualized system calls
< luke-jr> well, it does system-mode virtualization, and user-mode emulation..
< wumpus> I doubt it would be impossible but also that someone bothered to do this :-)
< luke-jr> I'm better user-mode virt is a missing area
< luke-jr> betting*
< luke-jr> I wonder if it would be less work to just make Linux support either endian
< wumpus> even user mode qemu (pure emulation) has problems with endianness and system calls
< wumpus> converting endianness between the emulated process and the kernel more or less works but there are some surprises, with deeper-buried structures, it's a very difficult problem to do it complete
< luke-jr> so probably less work to add to Linux <.<
< wumpus> (e.g. even some kernel-generated proc/sys files contain binary data with native endian, so something reading it compiled for another endian will expect its own endian but finds the host's)
< wumpus> yes maybe
< wumpus> nevertheless it would be a huge change
< wumpus> whole-system virtualization is much less complex becuase the paravirtualized APIs and emulated devices have a smaller API surface then system calls (or sometimes they are defined to be one endianness that can't be swithed)
< luke-jr> of course, there's also another layer deep: stuff like Box86 which emulates the program and wrap-translates calls to the libraries <.<
< wumpus> interesting, didn't know that project
< luke-jr> I think it doesn't even try to mess with endian differences
< luke-jr> IIRC it won't even cross the 32-bit/64-bit differences
< wumpus> it looks similar to the WINE approach though for linux-linux, emulating things at the library level not the deepest system call level
< wumpus> 32-64 bit bridging is another thing that sounds easy but is a horrible mess in practice :)
< wumpus> it's definitely relevant now that distro's are stopping shipping 32-bit libraries (though it's generally easy enough to install them in a chroot, if they keep the kernel support)
< luke-jr> also if they keep a 32-bit userspace build :p
< luke-jr> Ubuntu seems to have dropped that too
< wumpus> it doesn't have to be from the same distro :)
< luke-jr> true
< wumpus> 32-bit is basically only useful for running old games, but also people really want to run old games
< bitcoin-git> [bitcoin] theStack opened pull request #19687: refactor: make EncodeBase{32,64} consume Spans (master...20200807-util-make-encode-base3264-consume-spans) https://github.com/bitcoin/bitcoin/pull/19687
< bitcoin-git> [bitcoin] sanjaykdragon closed pull request #19586: test: moved from percent format to proper format for consistency (master...master) https://github.com/bitcoin/bitcoin/pull/19586
< bitcoin-git> [bitcoin] jonatack closed pull request #19611: p2p: refactor CInv::type from public int to private uint32_t (master...CInv-type-refactoring) https://github.com/bitcoin/bitcoin/pull/19611
< jonatack> #19610 now contains all the p2p changes from 19611 as well as jnewbery's 2020-07-split-already-have branch as we were both working on related code
< gribble> https://github.com/bitcoin/bitcoin/issues/19610 | p2p: refactor AlreadyHave(), CInv::type, INV/TX processing by jonatack · Pull Request #19610 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4b705b1c98f6...e349eeeb2c92
< bitcoin-git> bitcoin/master 90bd476 eugene: build: make clean removes .gcda and .gcno files from fuzz directory
< bitcoin-git> bitcoin/master e349eee MarcoFalke: Merge #19672: build: make clean removes .gcda and .gcno files from fuzz di...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19672: build: make clean removes .gcda and .gcno files from fuzz directory (master...fuzz_cov_cleanup_0806) https://github.com/bitcoin/bitcoin/pull/19672
< bitcoin-git> [bitcoin] hebasto opened pull request #19688: build, test: Add support for llvm-cov (master...200808-lcov) https://github.com/bitcoin/bitcoin/pull/19688