1)
Message boards :
Generalized Fermat Prime Search :
DO YOU FEEL LUCKY?
(Message 162812)
Posted 3 days ago by  composite
Stepping through the sieve range with a test factor as the constant step size has a declining
rate of candidate removal at higher sieve depth because of the increasing number of factors
which have been already tested through that range.
At what sieve depth would it be more efficient to perform "trial multiplication" of the test factor
by a list of sufficiently large primes to arrive at some exact candidates to remove?
Do we have a list of sufficiently large primes to do that, and if so is the list long enough that we
will get enough coverage in the sieve range to make a significant impact?
|
2)
Message boards :
Problems and Help :
PPS-SV GPU errors on 3 different hosts
(Message 162120)
Posted 25 days ago by composite
Sorry, I don't know what others have been seeing.
I have been running AP27 leading up to the new app.
|
3)
Message boards :
Problems and Help :
PPS-SV GPU errors on 3 different hosts
(Message 162118)
Posted 25 days ago by composite
<unhelpful>
I theorize that the PPS Sieve GPU app is merely throwing a fit because of all the attention being received by the new Cullen/Woodall Sieve GPU app.
There are still 20 times as many PPS Sieve tasks being run as C/W Sieve tasks.
</unhelpful>
|
4)
Message boards :
Problems and Help :
AMD ROCm CL_OUT_OF_HOST_MEMORY when running through BOINC
(Message 161957)
Posted 32 days ago by composite
# man clinfo
...
To selectively enable/disable platforms, one way is to move or rename the *.icd files present in
/etc/OpenCL/vendors/ and then restoring them one by one. When using the free-software ocl-icd
OpenCL library, a similar effect can be achieved by setting the OPENCL_VENDOR_PATH or
OCL_ICD_VENDORS environment variables, as documented in libOpenCL(7).
Other implementations of libOpenCL are known to support OPENCL_VENDOR_PATH too.
|
5)
Message boards :
Number crunching :
Hyperthreading Jiggery-Pokery
(Message 161742)
Posted 42 days ago by composite
I ran some tests of hyperthreading using a compute-intensive program that does no memory access.
It is apparent that there is actually just one compute resource in each core that is being shared by the
hyperthreads, so hyperthreads do not "accelerate" work in the way that using more cores would.
Rather, they prevent available core time from going to waste in idling.
In all these cases, exactly the same total computation work is completed.
Times rounded for clarity. The computer is idle except for these tests.
TEST A
A single task run twice in a row serially:
Real time = 96 sec, CPU time = 96 sec
TEST B
2 simultaneous tasks running on distinct cores:
Real time = 48 sec, CPU time = 96 sec
Two tasks are finished in the wall clock time it takes to run one task.
TEST C
2 simultaneous tasks running on the same core (different hyperthreads):
Real time = 94 sec, CPU time = 189 sec
The CPU sees that just one core is active so it boosts the core clock more than in TEST B,
accounting for the slightly lower times.
ALTHOUGH THERE IS ONLY 96 CPU sec of work available, the core activity timer counts
each task's waiting time as CPU run time and it reports almost twice the CPU time used
for the same amount of computation.
The utility of hyperthreading is to keep a core busy doing useful work while a thread is blocked
by a memory cache miss. Hyperthreading doesn't get CPU work done sooner in the way that
using more cores gets work done sooner.
In summary, CPU time includes the time that a task is waiting for cache to load from RAM,
and no amount of HT jiggery-pokery is going to hide this from the task. So leaning on HT as
a strategy to "speed it up" is only going to make CPU time usage increase. What will really
reduce CPU time is designing a program's RAM access pattern to have fewer cache misses.
|
6)
Message boards :
Number crunching :
Badges III
(Message 161393)
Posted 57 days ago by composite
The war on prime numbers? The War on Ukraine by Russia
Lithuania doesn't border Ukraine or Russia.
The news post is a joke about relocating PG to the Cayman Islands.
The flags for badges is what clues you in to the joke.
At first I thought PG was hacked.
Then I read the news item.
|
7)
Message boards :
General discussion :
Some questions from a newbie
(Message 161390)
Posted 57 days ago by composite
For the GFN in progress, we have
DYFL 673,000
That's ALOT of DYFL tasks in progress!!!
I think you misunderstood.
The "GFN in progress" means the kinds of subprojects available to work on.
The table shows the number of workunits expected to be processed before finding a prime in that subproject.
|
8)
Message boards :
Number crunching :
Badges III
(Message 161383)
Posted 57 days ago by composite
That does seem unfair - maybe the 12 hour rule shouldn't apply to an international prank? I was never aware of any time limit. We've always pranked each other at work all day. It's called April Fools DAY, not MORNING.
And I still don't get the joke with the flags. What has the Cayman islands to do with maths?
I guess you didn't read the latest item on the news forum.
|
9)
Message boards :
Number crunching :
VPN stalls uploads only to some projects
(Message 161330)
Posted 59 days ago by composite
Political discussion overwhelms all other subjects because everyone has an opinion.
There is little chance that talk about prime numbers will drown out talk about politics.
Many web sites encourage or at least tolerate political discussion. PrimeGrid isn't one of them.
There are so few web sites expressly for talking about prime numbers.
Let's not drown out talk about prime numbers with talk about politics.
Attaching some visuals to make this crystal clear:
you might feel OK about eating and shitting in the same place,
but you WILL offend everyone when you shit where they eat.
So join us for a meal.
Just the meal.
|
10)
Message boards :
Number crunching :
PPS Sieve CUDA be faster
(Message 161196)
Posted 68 days ago by composite
That's a convincing reposte.
The time to return the answer from the GPU is miniscule,
so doing that with a DMA transfer won't improve it.
In a related vein, there has not been a satisfactory explanation for
why it is necessary for the CUDA implementation of PPS Sieve to
use so much CPU time on Linux, while the CUDA implementation
of AP 27 Search on Linux uses so little CPU time.
|
