01:37:09 <jeffro256[m]> moneromooo what is the difference between that and std::lock_guard?
03:21:25 <selsta> jeffro256[m]: did you check contrib/epee/include/syncobj.h ?
18:53:42 <jeffro256[m]> 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?
19:11:56 <Awaru> gotta reboot the server again for a moment, hold on
19:14:57 <Awaru> oops that wasnt meant to send on all channels lol sry
20:39:13 <jozsef[m]> 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/1abfd30ef5eb654bae616264c9dc9c4d55b134b7)
20:44:24 <jozsef[m]> s/gitlab/github/
20:48:50 <UkoeHB>  jozsef[m] I'm pretty sure the long builds are from unit tests, which take like 1.5hrs total.
21:08:40 <bootlegbilly[m]> <jeffro256[m]> "yeah I did. If I'm not mistaken..." <- That's correct
21:17:24 <jeffro256[m]> bootlegbilly selsta So it's just a std::lock_guard then right?
21:19:50 <selsta> jozsef[m]: one thing you could take a look at is reviewing this PR https://github.com/monero-project/monero/pull/8046
21:20:00 <selsta> it speeds up transaction generation
21:22:08 <selsta> 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
21:22:21 <selsta> moneromooo might have some ideas
21:22:34 <selsta> jeffro256[m]: not sure honestly
21:36:47 <moneromooo> 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.
21:37:26 <moneromooo> Transaction verification would also be nice to speed up. The code is multuthreaded to some extent, but not hugely.
21:38:02 <moneromooo> Transaction generation is worth improving only if it's low hanging fruits, compared to verification.
21:39:51 <moneromooo> 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).
21:40:33 <moneromooo> There'd be a fair bit of cpu->gpu copies though, which might limit the benefit.
21:41:46 <fluffypony> what about using OpenCL during IBD?
21:42:08 <fluffypony> I think wallet sync speed ups are (somewhat) a solved issue with viewtags
21:42:19 <fluffypony> but IBD is brutal on a lot of hardware
21:42:34 <moneromooo> That has the same issue (probably worse) as using the asm crypto code we use in the wallet - possible forks. 
21:42:53 <moneromooo> But I'd like to see it :D
21:43:05 <fluffypony> could be opt-in
21:43:27 <fluffypony> and might be particularly useful on Android / Raspberry Pi if you can offload to the Mali GPU or w/e
21:44:20 <moneromooo> Also, I think a daemon opencl impl that doens't suck will require a lot more work than for the wallet.
21:44:31 <fluffypony> that's true
21:44:32 <moneromooo> There is a lot more done to verify a tx.
21:44:51 <fluffypony> but the net positives are pretty huge, more people running nodes
21:45:04 <moneromooo> Then again, a fair bit of this work is the same as if you want to make verification multithreading better.
21:45:17 <moneromooo> So it's worthwhile work eihter way.
21:53:00 <jozsef[m]> Thank you everyone. I took some notes. fluffypony could you please define IBD?
21:53:45 <fluffypony> jozsef[m]: initial block download 
21:54:02 <jozsef[m]> Thanks. ;-)