SiSoft Sandra is a synthetic benchmark. It benchmarks relatively simple operations such as AES ciphers, perhaps "true" hashing of memory. They are small things, usually designed to adapt to a large set of hardware.
Cryptocurrency hashes might be jokes but they usually concatenate several operations, mangle memory. The processor has an harder time 'figuring out' the best thing to do.
In particular, the Opteron has L3 cache and I'm pretty sure no Core2 model has L3. This can affect syntactic benchmarks hugely, it also has a richer instruction set which could accelerate Sandra.
By contrast, most CPU miners are 'high compatibility' and often don't come with newer CPU support by default.

I think you might be interested in knowing how yescrypt performs on GPU when run in background while mining something else...

http://imgur.com/mFMsS2z

This was somewhat expected (I'll leave the technical details out) but I was expecting the hashrate to be cut in half, or perhaps to a quarter... not to 0.5%... the next yescrypt iteration is expected to slightly improve this situation... but so far everything is going fine in CPU-land and it seems it will stay that way for a while.

I've found the bounties irrelevant some time ago and I find them irrelevant now, just FYI.

What truly pisses me off about them is:

• you unilaterally set conditions about testing performance target. This is not how it works. I speculate you're not truly interested in being informative or you would offer bounties to investigate scaling.
• Just getting the hardware you specified mandates I waste most of the prize. FYI, an hi-end i7 is ~450USD here implying you only accept candidates who already got the hardware... let me elaborate: in my experience, most ppl buying anything over i5 does not even know what a GPU is, let alone how to use it. CPUs end at 100 bucks for me. OFC, to compare to a 450 bucks CPU one would need at least a 300 bucks GPU for proper comparison...
• you haven't got anyone to adopt your algo, thereby people with the hardware will most likely not find it very interesting (I sure don't).

As a side note, I was asked to provide an Ethereum miner. I didn't find that interesting either as I think requiring such amounts of memory is unacceptable for consumers - sure it is acceptable for the elitist 'core miner' mindset around here. No idea how much memory you need... I guess this a good indicator of how much your offers are interesting me.

My experience in graphics seems to collide with your statements. GPUs have extended 'hyperthreading-like' capabilities and natively out-of-order memory... oh I see you CPU guys got that as well at least... Leaving aside that some of the properties you mention can be proven theoretically as you already have an implementation you claim to be 'about as fast' I honestly wouldn't be so confident.

But just to be clear, I still take some time to inform you. After all, your job is original and you're trying to move things forward.

The exact same I quoted? Does not make much sense to me besides guessing. No idea how anyone can suggest to use a QRK ASIC 'if that exist' and talk about that being an educated guess.

I'll ask again: how is this 'educated'? Perhaps the word means something different to me than it does for you.

Easy suggestion with 'if's ... How is this 'educated'?

Very good news!
Also, kudos for the new signature. Very important!

It's very simple. The day when kernel contributions were first pushed out awaiting for donations have long passed by.
nVidia users 'donate' in advance, for some definition of 'donation' to development of optimized kernels.

When optimized, GCN can often be competitive (and hashing is not even complex enough to fully stress a GPU) but those private kernels are either kept secret or sold.

So, yes, there are more devs on nV side. It's just more rewarded.

Haven't been mining for a few weeks.
Windows10 crapScreen prevented it to run.
 

Now I read this I somehow figure out I forgot to run the miner in the last couple of weeks. Why? 

I mean as of async_work_group_copy & friends. I have very mixed feelings on them, on my hardware, they just don't perform well not even in terms of bandwidth usage. Maybe on GCN1.1 they work better, IDK.
BTW, I would suggest to put a barrier(CLK_LOCAL_MEM_FENCE) right after the T-tables load. Besides, just have it looped!
That's more or less what pallas suggests. It is a fully coherent read. LDS has full scatter/gather capability, as long as you end in a different bank you're safe (here, it happens by construction).
Alternatively the first block can be loaded by async_work_group_copy, and you can derive T1_L from T0_L, LDS should provide you a massive latency reduction by not having to round-trip to the (hot) L1 cache.
Loops such as this are fully unrolled in most cases.

What is your experience with async block reads?

It's not about being 'shady' only, more like having a reciprocal interest in transparency. It happens I have contacts with some "big business" peers, it's not just B2B. Most of the time, they even pull in trusted certified third parties and sometimes they even publish their contracts on appropriate media for public scrutiny.

Being transparent and fully traceable is often seen by both as a way to protect themselves in case a future hiccup occurs not only between themselves but also WRT other peers (e.g. the shipping company physically delivering the goods). Believe it or not, they are very often not concerned about this whole privacy thing.

Note: generate new addresses. As long as you keep your privkey secure, you're still behind a cryptographic-strength wall at no cost. Eventually consider stealth addresses.

While we're talking about opensourcing, did anyone manage to port my kernel to sgminer?
I still get 7500khs from my Radeon 7750 (core 850 Mhz) and I'm still looking for more feedback.

Not necessarily.
My miner is moving towards being fully data-driven and so far everything is either MIT or zlib. In theory I would be fully for zlib but for a reason or the other I ended up with MIT. So there is (will be) full source accessibility, ability to rebuild privately, fully legal to redistribute as the kernels can be plugged in as you plug in a new map in a game.
To be completely honest the whole point of this message is to ask you to take a look at the license.txt file I've used as I'm only about 99% sure it's compliant right now.

QFE. I don't think it's active unfortunately.

Psst, don't tell anyone! 
It's a joke cuz
bitcointalk sux!!!one!
No seriously, you can do whatever you want.

The joke originated from the fact months ago there was a lot of fuss about elite kernels which were rarely released anyway, plus some other behaviors happening pretty much only there. So I thought: what if I publish a miner for a different userbase, being different and advertising it differently. It's mildly interesting.
Aside, I don't have hardware to support core miners anyway, so maybe there will be a btctalk thread when I get to 1.0. Likely happening sometime in this decade.
:lol: intended.

It is absolutely over. It is over for LTC and pretty much never started for any other currency. You cannot just make income by forgetting there the miner, you'll have to invest time and effort into trading. I would be happy if I could make 4$ a day but I couldn't.

Upgrade, if you want, for other reasons. I personally find the 750ti a bit expensive but considering the alternatives that's probably the best you can get. (  )

Thank you Sirs!
I need more help. This is what I get by running it (added debug mode for some extra output):
AFAIK, my CPU has SSE3 (4a). This looks like some sort of memory access crash, it is not a dump due to bad instructions. But... I am 

I tried to download the SSE2 miner from OP. It seems MEGA removed it. Please update link!

In central EU you would be paying with EUR and in some EU countries the solar energy is sold at .14c/kWh. Oddly enough I was fairly ok with your argumentation specifically. I still suspect you should get in touch with real world when it comes to this but at least I admit you have given an elaborated answer!