When will this project get Android support?

I got curious ever since I first read your question. I took some time to look into it.

I started running one CPU task on my old I5-3570K and after 16 hours it's at 40%. Coincidently, it will take a total of 40 hours total to complete. That's running 3 out of 4 cores with one core dedicated to GPU processing. Geekbench 5 reports that I5 rated at 950 for one core and 3600 for all 4 cores so I used 2700 as a proxy for 3 cores.

My current phone is a Galaxy A52 5G for which Geekbench 5 rates 630 for 1 core and 1900 for all 8 cores (not nearly as powerful in multicore compared to the I5). Using 1900 vs 2700, it would take 57 hours to complete a single task (40 * 2700 / 1900) on the phone.

Newer technology is far more efficient from a power standpoint the I5 runs at 77W and the Samsung runs at 5W if you were to compare 15 phones to the desktop the phones would win out handily.

My 4060 Ti runs work units in under 5 minutes. It will process 500 WUs in the time the 3 core CPU completes one and it runs ~100W (again, newer tech). It would process 715 WU in the time my phone would do one CPU WU.

Lastly, I did do Einstein WUs back in the day with an android and after not too long the battery ballooned out. They are not designed for constant heavy use thermally. It was a phone I didn't care about thankfully.

Not worth the trouble on the CPU side of things IMHO

The GPU side, my phone is 450 GFLOPS but only OpenCL 2.0 and my 4060 Ti is 22,100 GFLOPS or 49 times faster. I hope this is the correct way to think about things but if it is, then my phone's GPU would do a WU in about 4 hours or 6 WU per day. That's doable but again the heat issue is what I would be afraid of.

The issue with the ballooning batteries is not only caused by the heat but even more so by keeping it charged constantly at 100%. The batteries don't like that at all. Newer phones offer a setting of limiting the charge to 80% which I would recommend.

---

Yes, I have phone plugged in all the time that I don’t use it cause I’m going somewhere, and I have the 80% charging limit feature enabled, and also, It’s a snapdragon 8 Elite chip, so it has way better thermals than most other Android phones, and It’s only utilizing the CPU cores, not the GPU cores, compared to when gaming, and it doesn’t get hot, at all, while using all 8 CPU cores running BOINC.

And also, every little bit of compute helps, and if people wanna use their Android phones for BOINC, that’s up to them, and people saying there isn’t enough demand for it, it’s the classic, you gotta make the product attractive, for demand to increase, instead of waiting to make an attractive product, until demand is there, cause that demand will never come to a bad product, even though this is free of course.

And I’d love if you could donate money to specific causes within these projects, like it will cost X amount of money to add Apple Silicon support, X amount of money to add Android support, based on, roughly, how much time it will take, and the cost of having to spend this time on it, for the people doing, that they have to take away from their normal job.

I'm currently testing the Android version on Ardeno 750 (which is the 2nd fastest mobile GPU). Even if it functions correctly, the performance appears to be VERY bad

> The GPU side, my phone is 450 GFLOPS but only OpenCL 2.0 and my 4060 Ti is 22,100 GFLOPS or 49 times faster. I hope this is the correct way to think about things but if it is, then my phone's GPU would do a WU in about 4 hours or 6 WU per day. That's doable but again the heat issue is what I would be afraid of.
You can't do that, because there are other factors:
1/ Mobile GPUs use shared memory, which significantly limits memory bandwidth compared to a desktop GPU like the 4060 that has dedicated VRAM.
288.0 GB/s for 4060 Ti vs ~50 GB/s DDR5 (also shared with the CPU)
2/ NVIDIA GPUs have great INT32 performance, whereas mobile GPUs often emulate INT32 operations to conserve power, since these operations are generally relevant for gaming workloads. Even if FP32 performance numbers look good, INT32 performance is much worse.
3/ The cache sizes on mobile GPUs are very small (if any), which forces the app to rely on system memory. The system memory already suffers from limited bandwidth and higher latencies.
4/ In general, code isn't optimized for mobile GPUs. Achieving good performance often requires various tricks, like avoiding certain features or adapting to architectural quirks. It's challenging because these GPUs have very limited resources, and no developers go to that level of optimization. Especially when it takes around 100 top-end phones to match the performance of a single 4060 Ti. It simply doesn't make sense.

I had to rewrite the code a little because Android does not support named semaphores:

NOINLINE Semaphore::Semaphore()
{
    if (sem_init(&mySemaphoreInternal, 0, 0) != 0)
    {
        std::cerr << "Failed to initialize unnamed semaphore, errno " << errno << std::endl;
        boinc_finish(-1);
    }
}

class Semaphore
{
public:
    Semaphore();
    FORCEINLINE ~Semaphore() { sem_destroy(&mySemaphoreInternal); }

    FORCEINLINE bool Signal() { return sem_post(&mySemaphoreInternal) == 0; }

    FORCEINLINE bool Wait()
    {
        while (sem_wait(&mySemaphoreInternal))
        {
            if (errno == EINTR)
            {
                errno = 0;
            }
            else
            {
                return false;
            }
        }
        return true;
    }

private:
    sem_t mySemaphoreInternal;
};

ok, it took about 3 days :D
https://sech.me/boinc/Amicable/result.php?resultid=100264226

It technically works, but since even low-end GPUs can complete a work unit in about 10 minutes, it's not really practical.

The only project that runs reasonably well on mobile GPUs is Einstein@Home. PrimeGrid and Amicable use 32-bit integers, which perform terribly, at least on Adreno GPUs. Mali might handle them better, but even then, we're still looking at work units that take days to complete.

Amicable use 32-bit integers

64-bit integers for the most part, because we're dealing with 21-, 22-digit numbers already.