[QUOTE=rogue;624362]CPU utilization is used in the calculation. Short runtimes will skew the calculations too.[/QUOTE]

Very well. I noticed [I]srsieve2cl[/I] uses the CPU, to a point. Somewhere between 15% to 20% utilization.

[QUOTE=storm5510;624379]Very well. I noticed [I]srsieve2cl[/I] uses the CPU, to a point. Somewhere between 15% to 20% utilization.[/QUOTE]

I should have been more specific. It combines execution time in the GPU with processing time in the CPU. These are not necessarily 1::1. Execution time in the GPU is just a sum of (stopKernelTime - startKernelTime) for each kernel execution. It does not take into account utilization of the GPU. Processing time in the CPU is more precise. The value from the OS takes into account CPU utilization. This makes is easier for the code to compute the percentage of CPU cores that are used with 100% meaning full utilization of a single core.

[QUOTE=rogue;624382]I should have been more specific. It combines execution time in the GPU with processing time in the CPU. These are not necessarily 1::1. Execution time in the GPU is just a sum of (stopKernelTime - startKernelTime) for each kernel execution. It does not take into account utilization of the GPU. Processing time in the CPU is more precise. The value from the OS takes into account CPU utilization. This makes is easier for the code to compute the percentage of CPU cores that are used with 100% meaning full utilization of a single core.[/QUOTE]

Thank you!

The CPU utilization is being spread across 8 threads at 16%. However, the fine print near the top of the attached image says 100%. Some threads are being used more than others according to the graph. Combining the actual usage of each thread would put it at 100%. Since the removal rate is not real-time, the best thing I can do is use it like a sort of benchmark.

The 60% test I ran with [I]LLR[/I] indicated I needed to be consistently above 1,994 seconds per factor with what I am running. This test is real-time so I am not sure I can use this as an indicator of where I need to be with [I]srsieve2cl[/I].

As a heads up, with new versions of the ld program, the following warning comes up when compiling:

[CODE]/usr/bin/ld: warning: x86_asm/avx_powmod.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker[/CODE]

This is due to the fact that making the stack executable can result in a security risk (see [URL="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136"]this[/URL] for instance). There doesn't seem to be any ill effect with adding -z noexecstack to the LD_FLAGS in the makefile with regards to the program's performance (at least on small files), so it's probably worth adding this.

[QUOTE=Dylan14;624418]As a heads up, with new versions of the ld program, the following warning comes up when compiling:

[CODE]/usr/bin/ld: warning: x86_asm/avx_powmod.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker[/CODE]

This is due to the fact that making the stack executable can result in a security risk (see [URL="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136"]this[/URL] for instance). There doesn't seem to be any ill effect with adding -z noexecstack to the LD_FLAGS in the makefile with regards to the program's performance (at least on small files), so it's probably worth adding this.[/QUOTE]

Okay. I will look into this when I have some time.

Question for srsieve2
As I can remember I can do start sieving multiple sequence at once. Not it doesnot work. I enter few sequences in command line, but got output only for first one. Srsieve2 is from latest mtsieve package ver 1.6.8

[QUOTE=pepi37;624893]Question for srsieve2
As I can remember I can do start sieving multiple sequence at once. Not it doesnot work. I enter few sequences in command line, but got output only for first one. Srsieve2 is from latest mtsieve package ver 1.6.8[/QUOTE]

I would prefer to put all remaining sequences into a remain.txt and use it as inputfile.

[QUOTE=pepi37;624893]Question for srsieve2
As I can remember I can do start sieving multiple sequence at once. Not it doesnot work. I enter few sequences in command line, but got output only for first one. Srsieve2 is from latest mtsieve package ver 1.6.8[/QUOTE]

Each sequence requires -s so if you have 5 sequences there should be 5 -s arguments each with a different sequence.

[QUOTE=rogue;624895]Each sequence requires -s so if you have 5 sequences there should be 5 -s arguments each with a different sequence.[/QUOTE]

Or put all the sequences in a single text file, each on one line. [I]-s input.txt[/I], for example. It worked for me. :smile:

[QUOTE=storm5510;624921]Or put all the sequences in a single text file, each on one line. [I]-s input.txt[/I], for example. It worked for me. :smile:[/QUOTE]

Thanks Storm, first problem is solved

Now second one

[QUOTE]srsieve2 -P 50000000000000 -W8 -i b10_n.abcd -O factors.txt -l 0
srsieve2 v1.6.8, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Must use generic sieving logic because no memory is allocated for Legendre tables[/QUOTE]

If I use any other then 0 with -l option I got invalid factor. And if I read correctly -l build Legendre table so sieving with them should be faster?

And last, this is first time I got that on RTX 2070 Super sieving is 75% faster then on Ryzen 5700x ( 8 threads)

[QUOTE=pepi37;624956]Thanks Storm, first problem is solved

Now second one

If I use any other then 0 with -l option I got invalid factor. And if I read correctly -l build Legendre table so sieving with them should be faster?

And last, this is first time I got that on RTX 2070 Super sieving is 75% faster then on Ryzen 5700x ( 8 threads)[/QUOTE]

Yes, it should be faster with -l > 0. Please PM me with the details for the invalid factor.