mtsieve enhancements

[ET_]

Any hope to have either gfndsieve or dmdsieve on an ARM-64 platform, either with an ASM translation or with plain c routines?

Just asking for a friend of mine...

[rogue]

Originally Posted by ET_

Any hope to have either gfndsieve or dmdsieve on an ARM-64 platform, either with an ASM translation or with plain c routines?

Just asking for a friend of mine...

It might be possible, but I have no way to compile or test such code. I'm hoping that my wife will let me get an Apple laptop with the M1 CPU next year, but don't have a lot of hope for that. I believe that someone posted some ARM ASM FPU routines earlier in this thread. Someone with access to an ARM CPU could make the changes and do some testing. Fortunately gfndsieve and dmdsieve should be easy to get working if one has the necessary ARM functions. Until then I will look at producing versions that do not require ASM.

[pepi37]

Where srsieve2 store legendre table file?


I use this command but after I stop srsieve2 I cannot find any new file



srsieve2.exe -l -L legendre .txt -P 176362230330 .....

[rogue]

Originally Posted by pepi37

Where srsieve2 store legendre table file?

I use this command but after I stop srsieve2 I cannot find any new file

srsieve2.exe -l -L legendre .txt -P 176362230330 .....

That code is not implemented yet. It is not a small task. I started a while ago, but have a ways to go. You can continue to use sr1sieve/sr2sieve for now.

[Happy5214]

Originally Posted by ET_

Any hope to have either gfndsieve or dmdsieve on an ARM-64 platform, either with an ASM translation or with plain c routines?

Just asking for a friend of mine...

Originally Posted by rogue

It might be possible, but I have no way to compile or test such code. I'm hoping that my wife will let me get an Apple laptop with the M1 CPU next year, but don't have a lot of hope for that. I believe that someone posted some ARM ASM FPU routines earlier in this thread. Someone with access to an ARM CPU could make the changes and do some testing. Fortunately gfndsieve and dmdsieve should be easy to get working if one has the necessary ARM functions. Until then I will look at producing versions that do not require ASM.

That would be me and my ODROID-C4, though I apparently forgot to post a tarball of the entire set of translated ASM files (attached here). I haven't done any actual integration work with the mtsieve code yet, though I do have sample programs that check out. Looking at the two sieves in question, they appear to utilize the untranslated asm-ext routines in the App class (I only translated the x87 routines), so that would have to be dealt with.

As an aside, I briefly experimented with an Advanced SIMD/NEON implementation, but I gave up quickly when I realized that I couldn't vectorize the integer instructions, so all the instructions I thought I'd be saving would still have to be executed in some form.

[rogue]

Originally Posted by Happy5214

That would be me and my ODROID-C4, though I apparently forgot to post a tarball of the entire set of translated ASM files (attached here). I haven't done any actual integration work with the mtsieve code yet, though I do have sample programs that check out. Looking at the two sieves in question, they appear to utilize the untranslated asm-ext routines in the App class (I only translated the x87 routines), so that would have to be dealt with.

As an aside, I briefly experimented with an Advanced SIMD/NEON implementation, but I gave up quickly when I realized that I couldn't vectorize the integer instructions, so all the instructions I thought I'd be saving would still have to be executed in some form.

I forgot about those. The easiest thing for now would be to disable -x and associated logic when building on a non-x86 CPU.

[rogue]

There is a bug in this release that affects all exes that was introduced with factor validation. I'll fix it later today.

[rogue]

I have posted 2.1.1 over at sourceforge and removed 2.1.0. Here are the changes:

2.1.1 - December 29, 2020
   framework:
      Fixed an infinite loop that occurs with the special CPU worker in GPU builds.
      
      Removed the factor validation logic added in 2.1.0 do to an issue with how I
      implemented it.
   
   gcwsieve, gcwsievecl:  version 1.5
      Added working factor validation logic with -I.
      Improved GPU speed by another 10%.  Thanks to Yves Gallot for the code.
   
   mfsieve, mfsievecl:  version 1.8
      Added working factor validation logic with -I.
      Fix bug triggering invalid factor in the CPU code when minN is odd with factorials.

[pepi37]

Did you increase upper limit in srsieve2?

[rogue]

Originally Posted by pepi37

Did you increase upper limit in srsieve2?

Funny that you ask...

I just posted 2.1.2 over at sourceforge.

2.1.2 - December 30, 2020
   framework:
      Retain factor counts when workers are rebuilt.

   srsieve2:  version 1.3
      Added factor validation logic when using -I.
      Switched to Montgomery mulitplication, which is about 20% faster than the previous
      logic.  This also gives a 20% speed bump and adds support for p up to 2^62.

And I have this on my wish list:

Added on December 29, 2020
   framework:
      Add ARM support

This is my last release for 2020.

[pepi37]

Great! so let test it!


and first bug found


fbncsieve.exe -P 6000000000000000 -i 1100.txt -o 1100.txt -f N -W6 -O s53factodes.txt
fbncsieve v1.4, a program to find factors of k*b^n+c numbers for fixed b, n, and c and variable k
Sieve started: 347880187459691 < p < 6e15 with 75104 terms (1014 < k < 1999948, k*10^1100000+1) (expecting 5887 factors)
p=0, 22.89M p/sec, no factors found