moneromooo what is the difference between that and std::lock_guard?

jeffro256[m]: did you check contrib/epee/include/syncobj.h ?

yeah I did. If I'm not mistaken CRITICAL_REGION_LOCAL(m) creates an epee::critical_region_t with mutex m, which locks mutex m on construction, and releases it on destruction. Is that more or less correct?

gotta reboot the server again for a moment, hold on

oops that wasnt meant to send on all channels lol sry

Hey folks, monero newbie here. I have a science/engineering background with programming and software engineering skills (C, C++17, CMake), with 10+ years experience solving physics equations (fluid dynamics) with large clusters (100K+ CPUs), parallel computing and code performance optimization, targeting reducing... (full message at libera.ems.host/_matrix/media/r0/do…30ef5eb654bae616264c9dc9c4d55b134b7)

s/gitlab/github/

jozsef[m] I'm pretty sure the long builds are from unit tests, which take like 1.5hrs total.

<jeffro256[m]> "yeah I did. If I'm not mistaken..." <- That's correct

bootlegbilly selsta So it's just a std::lock_guard then right?

jozsef[m]: one thing you could take a look at is reviewing this PR monero-project/monero #8046

it speeds up transaction generation

otherwise wallet sync is CPU heavy, we already did speed it up with having some of the cryptography operations written in ASM but I think it still could be improved

moneromooo might have some ideas

jeffro256[m]: not sure honestly

Wallet scanning can probably be improved, it's massively parallel really. The vast majority of cases will be making the same ops on different data, and bail.

Transaction verification would also be nice to speed up. The code is multuthreaded to some extent, but not hugely.

Transaction generation is worth improving only if it's low hanging fruits, compared to verification.

From time to time, someone floats the idea of using opencl or the like to perform those wallet sync ops (few of htem, done a lot).

There'd be a fair bit of cpu->gpu copies though, which might limit the benefit.

what about using OpenCL during IBD?

I think wallet sync speed ups are (somewhat) a solved issue with viewtags

but IBD is brutal on a lot of hardware

That has the same issue (probably worse) as using the asm crypto code we use in the wallet - possible forks.

But I'd like to see it :D

could be opt-in

and might be particularly useful on Android / Raspberry Pi if you can offload to the Mali GPU or w/e

Also, I think a daemon opencl impl that doens't suck will require a lot more work than for the wallet.

that's true

There is a lot more done to verify a tx.

but the net positives are pretty huge, more people running nodes

Then again, a fair bit of this work is the same as if you want to make verification multithreading better.

So it's worthwhile work eihter way.

Thank you everyone. I took some notes. fluffypony could you please define IBD?

jozsef[m]: initial block download

Thanks. ;-)