<s​yntheticbird:monero.social> ```cpp

<s​yntheticbird:monero.social> / if all available threads are already running// and there's work waiting, just run in current thread

<s​yntheticbird:monero.social> ```cpp

<s​yntheticbird:monero.social> // if all available threads are already running

<s​yntheticbird:monero.social> // and there's work waiting, just run in current thread

<s​yntheticbird:monero.social> ```

<s​yntheticbird:monero.social> This souds like a bad idea on paper. (common/threadpool.cpp 89)

<a​rticmine:monero.social> It will not work with data centers. The idea is to make use of underutilized hardware on consumer and small business devices.

<a​rticmine:monero.social> One can rent GPUs in a data center but that is a specialty service.

<a​rticmine:monero.social> This does bring up an interesting point. Support for parallel processing especially on GPU will help decentralize the network.

this means a ton of existing nodes will be gone harming the overall resiliance and decentralization of the project. it will also mean merchants will think twice if they want to accept monero if they need specialized hardware compared to all other cryptocurrencies.

I would have to turn off all my nodes, I don't have hardware with GPU that I could run 24/7

<a​rticmine:monero.social> Enabling parallel processing and GPU support does not immediately make existing data center nodes unable to keep up.

<a​rticmine:monero.social> It will enable more truly decentralized nodes

<a​rticmine:monero.social> ... and provide an alternative.

<a​rticmine:monero.social> Also fiber to the home is fast changing the biggest data center advantage.

<s​yntheticbird:monero.social> Again. consumer hardware and small business devices DO NOT SUPPORT COMPUTATIONAL API. Unless you want to make some very weird and insecure hack for calculating through graphics API, There are no reasonable way for a consumer grade gpu to be used for calculation. Especially for phone and laptops

<s​yntheticbird:monero.social> NVIDIA CUDA and OpenCL support were already a pain in the ass through their proprietary driver. Let's not talk about ROCm that is several years late at supporting latest AMD graphics card. Only option would be Mesa. But again Mesa is nowhere to be found on Windows, Android, MacOS and iOS.

<s​yntheticbird:monero.social> It's not a bad idea. It's just unfeasible in the world we live in

<a​rticmine:monero.social> Yet the Bitcoin network figured this out in 2010 in a few months.

<a​rticmine:monero.social> ... and now even multi-core CPUs are an issue.

<a​rticmine:monero.social> ... and Monero was mined with GPUs from 2014 until 2018.

<a​rticmine:monero.social> The issue is finding people who are willing to do this. That I can understand.

huh

u saying bitcoin core uses gpu to sync?

<a​rticmine:monero.social> It was mined with GPUs until 2013. As was Monero, and Ethereum. All using consumer grade hardware. Using GPUs and multi core CPUs for transaction verification is the same problem.

<a​rticmine:monero.social> It is a repetitive process that lends itself to parallel processing.

<a​rticmine:monero.social> I mean are the transactions in a Monero block dependent on each other?

that feels like a strained comparison in that GPU mining rigs are basically specialty hardware

<a​rticmine:monero.social> Not necessarily.

we have an assembler implementation of ed25519 and yet we don't use it during daemon sync out of risk that a slight implementation difference causes a chain split

<a​rticmine:monero.social> ... and in this case we don't have the cutthroat competition

I mean being able to use a GPU seems fun, no doubt, but I guess what I'm saying is that I think the software needs to be sufficiently performant on CPU, and not rely on GPU, which means it's not really an effective scaling soluition

we're already telling people "hey just get an SSD", don't really wanna add GPU to that. and I know you aren't talking about big discrete GPUs, but still

getting complex GPU code working bug free on various hardware is extremely complicated, and if it starts to be used in consensus relevant code it becomes a risk to the network

I found an old comment from sech1 on it reddit.com/r/Monero/comments/f5d3k3/comment/fhy4852

<a​rticmine:monero.social> First I agree it has to work in parallel on a CPU. The reality is that CPUs are scaling by number of threads

^^ for sure, to continue with the comparison to mining, I've done a bunch of GPU mining and that stuff is pretty finicky

<a​rticmine:monero.social> So making it work on multi core CPUs would in itself be a major gain

yes, improving CPU multi core is a more realistic short term goal

for sure

that said I did a full sync on a piece of shit dual core laptop like a week ago and it finished in 50 hours

could be a lot worse

full sync with or without fast-sync enabled?

with. all default settings except outpeers=24

no inbound peers

it's not so bad because it skipped a lot of the verification for known blocks

oh yeah I know

when blocks where full during the last weeks I was only syncing 1 blocks / second

that's why I'm worried of major ring size increases without any performance improvements

<a​rticmine:monero.social> I say focusing on multi core CPUs is the reasonable starting point. There are real performance gains.

s/where/were/

that's like a year's worth of blocks in 3 days, but I still share your concern about a major increase to verification time without corresponding performance improvements

<a​rticmine:monero.social> Thanks. This is very helpful. Mesa does make GNU / Linux a possible next step, after optimization of CPUs. l agree with not dealing with the proprietary DRM infected consumer operating systems., Windows, MacOS, iOS, and yes even Android.

<a​rticmine:monero.social> The real problem with most consumer devices is not the hardware, it is the OS.

<a​rticmine:monero.social> There is also the advantages of encouraging the running of nodes on GNU / Linux to avoid a DRM based attack by a centralized entity.

<k​ayabanerve:matrix.org> UkoeHB_: Maintain any Matrix accounts these days?

<s​yntheticbird:monero.social> Please this is the MRL. Let's not dive into the Windows is bad debate again. I think Luigi already had a lot to dealt with last time.

<s​yntheticbird:monero.social> But anyway. Looking forward seeing a RingCT OpenCL proof of concept 👍️

<a​rticmine:monero.social> That would be fantastic

<1​23bob123:matrix.org> Issue between matrix.org and monero.social. Better of using irc or monero.social account.

<1​23bob123:matrix.org> For now soon™️