As a side note: whatever measure you get for AMD GCN be advised users running Windows will (hopefully soon) have access to improved kernels.

This miner mangles Qubit, a form of chained hashing: Luffa, CubeHash, Shavite, SIMD, Echo. The ending _X is the amount of kernel parallelism used.

SIMD stands for "SIMD is a message digest". Silly jokes.

Legacy kernels build a big function out of all those algorithms. In my implementation instead, the phases are clearly separated. This allows me to reconfigure GPU ALU more appropriately. Most of the benefit comes from the improved SIMD and Echo implementation.

Note: same algorithms but different implementations.

To your project, the value is mostly in the new codebase which is hopefully easier to understand. I do not claim it to be complete nor efficient but it is surely more compact.

I was initially very interested but my excitement went down with the first fork and it's going down with the next. Besides not inspiring much confidence, I have a serious problem: a small company around here realized they have (probably around 64) very low loaded cores for a few hours day. So, this is not "a large farm", it's just a small company wanting to diversify.

With little information about hashrate and a planned fork I have no idea how I could assess this coin profitability.

Besides, changing algo keeping the same name is just brain damaged. No idea how anyone could figure out something like this.

The main problem is: as long as you mine using mass produced hardware, of course it will not be profitable.
It's just an implication of how the system works, to be profitable you must have more power than the others and this is unlikely to happen as they have access to the very same hardware, with difficulty equalizing everything.

Back to the point.
What is the 'best' coin to mine with CPUs?

I've been looking at XMG a bit... but I'm not at ease with their "fork every other week" approach.
Following.

I don't know if VTC will survive the competition agains others. But I want it to survive.
Why? Stealth addresses for one and I believe in its mission to stay decentralized.

At least change algo name. Keeping the same name makes no sense.

A small company around here contacted me to explain them this crypto thing. I am supposed to give them a rough estimation of what they can produce with the few xeons they cannot manage to load (I think we're talking about 64 cores at most, for a few hours day).

Where can I find performance data?
I've seen some coins using google docs for this and I've been positively impressed with the usability.

As a side note, the proposed fork is a nice coincidence. I can tell for sure this will give me quite some troubles.

Officially, I don't know others.
But in theory it is possible to do HDD-assisted mining for pretty much everything as the algos are deterministic in nature. Whatever it's also profitable I cannot tell.

Good question! Problem is, when in the design phase, an ASIC is still a very vague thing. They have a lot of weapons we don't and I see no way to put this in ELI5 version. Sure thing is using more memory increases resistance but other means must also be explored.

Making something quantum resistant is not considerably different from ASIC resistant.

If something can be computed then it can be optimized, the hardware can be optimized. With quantum computing not being a real product and with basically no expertise available, you can bet no VTC quantum computing will take place in the next 10 years.

Be real. There are usually not even GPU otimized kernels, and GPUs have been on mass market for nearly 20 years.

Yes, changing algo at the end of November (thanks valsens).

Holy crap man, this sucks beyond words! Try to get through it!

I'd like you to take a look at my miner, designed to be understandable and easy to use.
First miner with GPU specific kernels, solved overspilling. Proper GPU OpenCL kernels (instead of just running CPU code on GPU). MIT license. Sort-of-C++11.

If you can add kernels for the coin of your choice that would rock!
Or, you could optimize the kernels since I speculate there's another 70% to squeeze out.

The amount of consumed power is massive and by the way, peltiers don't really "cool"... think at them like moving the heat a few millimeters from the device. You still need a heatsink for the hot side and as the hot side gets hotter, the efficiency becomes even worse.
Granted, your chip will be cooler if you do the homework but with the cost of electricity for GPU mining already too high I'm afraid that will just be an nothing more than an interesting experiment.

Isn't the fork supposed to take place at the end of the month? Maybe they could still sort it out.
The proposals of "forking temporarily" are jokes.

Yes. To average user, Apple Pay and crypto is same thing. Except Apple Pay is by Apple so it must be innovative, right?

Seriously dudes, expecting Apple consumers to know what they're talking about is a pipe dream.

They keep surprising me day after day. What else can be screwed up?

I apologize. It was not clear to me from the wording.

No, the old outdated documentation is confusing people. There's no such thing as "shaders" in AMD GCN, the numer you are referring to is probably the "total number of concurrent work items in flight", which is a multiple of the hardware concurrency. I admit the wording could have been better.

If memory serves 290 has 44 CU so that would be 11264 to me. Besides, as I said the number of threads in flight at the same tick for 7970 has 32 CU and it already keeps in flight (at the same tick) more work items than your computations suggest.
No idea what "shader count" is supposed to mean I admit, the concept is largely obsolete and last time I checked sgminer didn't use it. Is it the SIMD lane count? Concurrenty per clock? Per timeslice? Scheduler limit? Please explain how you obtained that number.
Please explain me the connection to "threads" as well.

Reference: AMD APP, Appendix D "processing elements".

Happy birthday... sort of  you can keep the cigar, I don't smoke.
I assume you will hang around for another few thousands years.

Actually decreasing thread concurrency is more likely to cause HW rather than solve them.
The thread concurrency setting does not do what you think it does. A better name would be "size of the concurrent thread scrypt scratchpad buffer".

I strongly suggest to keep the thread concurrency parameter as high as possible: 2x the total shader count worked for me. Lower numbers increase the chance threads smash each other. At thread concurrency == shader count the risk of hardware errors is close to 100%.

7970 has 32 clusters. This means it will keep in flight 32*256=8192 threads at the same "tick".

WinMain does not spawn a window FYI.