Abstract support for multiple algorithms

[veox]

There are several forks and branches that implement support for algorithms other than Litecoin-style vanilla scrypt. However, most of these implementations are incompatible.

To do this cleanly and to allow easier extension with other algorithms, this has to be abstracted. Otherwise, we will keep adding conditionals to random functions to the point their purpose becomes incomprehendible.

IMO it would be much better to introduce a single --algorithm option.

Implementations and notes:

• zuikkis/master (changes) - allows using all current kernels, but does not account for N-factor change based on block timestamp; I have made a few minor fixes in branch nfactor-zuikkis;
• troky/nscrypt (changes) - pulls in changes from vertminer, does account for N-factor change, but requires a special kernel; pulled into branch nfactor-troky;
• veox/nfactor - nfactor/zuikkis with a few improvements, including the initial implementation discussed in this issue, scheduled to be merged into master;
• veox/scrypt-jane - rmdavidson's patches applied by @tonobitc, does not work; does not used functionality discussed in this issue;
• sph-sgminer - haven't looked yet into as to how algorithm selection is implemented there; not variable-N-factor or Keccak.

Related issues/PRs:

https://github.com/veox/sgminer/issues/10 - Add scrypt-jane for alternate scrypt coins; https://github.com/veox/sgminer/issues/92 - Add Scrypt-Adaptive-Nfactor algorithm; https://github.com/veox/sgminer/pull/110 - Zuikkis' Scrypt-nfactor support; https://github.com/veox/sgminer/pull/111 - rebase of the above.

[Zuikkis]

I'm not sure if the block timestamp based nfactor is necessary. To my understanding, this is always coin-dependant? The current timestamp code probably only works for vertcoin, and not other possible future coins.

What's more, in nfactor-zuikkis version the kernel is compiled for the given nfactor. When nfactor changes (once a year, I think), kernel recompile is necessary. This might not be a problem if sgminer could restart itself automatically when it detects that kernel constant parameters have changed?

Vertminer and nfactor-troky use real runtime nfactor parameter in the kernel, but this is a big penalty hit because it changes a lot of the constant calculations to variable calculations! IMHO it's better to run at 5% higher hashrate for one year, then restart sgminer, than to run 5% slower without the need for annual restart. :)

[troky]

I am not sure vertminer use real runtime nfactor parameter in the kernel. It is calculated in (sgminer) code and passed as parameter to (already compiled) kernel. No penalty hits.

[Zuikkis]

It is passed as parameter and then realtime interpreted by the kernel... It is a penalty hit.

Vertminer kernel tries to be clever and passes the value as connstant to scrypt_core, but it doesn't change anything.. All the calculations like NFACTOR/2 are still calculated runtime, because the value of nfactor is not known at compile time. On 3 Mar 2014 20:13, "troky" notifications@github.com wrote:

I am not sure vertminer use real runtime nfactor parameter in the kernel. It is calculated in (sgminer) code and passed as parameter to (already compiled) kernel. No penalty hits.

Reply to this email directly or view it on GitHubhttps://github.com/veox/sgminer/issues/126#issuecomment-36539462 .

[veox]

I'm not sure if the block timestamp based nfactor is necessary. To my understanding, this is always coin-dependant? The current timestamp code probably only works for vertcoin, and not other possible future coins.

Most possible.

In either case, Vertcoin N change is rare enough to perhaps sacrifice automatic switching in the name of efficiency. And if other CCs have a different schedule, then hard-coding the changes is nearly useless: there will likely be as many Vertcoin clones as there are Litecoin clones. So I tend to agree with your reasoning on this point.

OT: I'm currently looking into whether https://github.com/veox/sgminer/commit/e18bcc25822c3a09053140e84819e963d862866f didn't introduce a penalty, too - looks like it hasn't, since the same compile-time optimisations should apply, but it's not necessarily true that const[#define] is the same as #define.

[Zuikkis]

Yeah I looked at your NFACTOR change in kernel source, I almost commented but then I figured it must be ok because it is all constant math anyway. I haven't tried it yet, though..

[Humancell]

I'm curious ... I know how to pull down the source and build on Linux, but am not sure that I want to undertake the Windows build process just yet. Who has been doing the Windows builds, and is there anyway that they might do a weekly build (e.g. v4.1.yyyymmdd) for testing purposes, and to allow us access to some of the evolving features?

I know that if I have to ... I might have to become that person ... but I'm trying to avoid it if someone else already has the build environment set up. :-)

[Bllacky]

I am building for Windows every few days. If you want, I can make the build available. But right now, I want to focus on getting to build both 32-bit and 64-bit versions. I can only build 32-bit.

[Humancell]

That would be great ... I'm also going to begin to see if I can set-up Visual Studio to build ... :-)

[veox]

@Humancell @Bllacky please do not sidetrack the issue discussion further.

[veox]

Implemented, see comparison: https://github.com/veox/sgminer/compare/11cf733edee96556989e5a179aa3b04e2f38bafc...nfactor

[sh1ny]

So, how do i run scrypt-jane ? Do i need to specify it as kernel and --algorithm adaptive-nfactor --nfactor 12 ( current for ultracoin ) and --kernel scrypt-jane.cl ?

[veox]

@sh1ny There's been some work (by @tonobitc) that I pulled into branch scrypt-jane, but it doesn't work as far as it's been reported (100% hardware errors).

IMO it'd be better to work on that once branch nfactor with its algorithm struct is merged into master, reusing code from scrypt-jane.

[veox]

This has been merged into master together with branch nfactor.

[vizakenjack]

IMHO, algo should be in pool settings, not in primary conf file. Because it would allow to set multiple pools with different algorithms, scrypt+nfactor f.e.

[veox]

@Vizakenjack see https://github.com/veox/sgminer/issues/134