[ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency

[bulanula]

More fail by BitcoinExpress. No wonder. CPU mining is here to stay 

[1713565241]

1713565241

[1713565241]

1713565241

[1713565241]

1713565241

[1713565241]

1713565241

[1713565241]

1713565241

[Lolcust]

Good doggie.

Now play dead.

Good puppet master.

Now go pump and dump them brix !!! Wonder why TBX price is so low now  

On another note, what about our genius' revelation ? BitcoinExpress said that virtually all these CPU only currencies can easily be made into GPU currencies by IE9 hardware accelerator !? How true is that for Tenebrix ?

If that's the case they should release this for everyone to use.

The script source code is here: http://cpansearch.perl.org/src/GRAY/Crypt-Scrypt-0.05/src/src/lib/crypto/crypto_scrypt-sse.c

But...  this algorithm is supposed to be memory-hard but only takes 7MB of RAM on my system? (minerd.exe)  But maybe memory-hard in this instance refers to cache size on the CPU?  GPUs are based around something requiring large amounts of sequential memory access, and if the data is not constantly being reused but instead overwritten GPU computing might be inefficient.  An easy way of destroying GPU efficiency is just to make an algorithm require it to access memory randomly instead of sequentially.

It should be pointed out that there is nothing impossible in doing  mining through a browser app, irrespective of whether that is cpu or gpu mining, and that browser-mining does not itself make scrypt GPU-friendly

(but it does bring up an interesting question as to possibility for mining-enabled "rich content" banners that bring you both ad-money and coinsez)

as to TBX memhardness, this is relevant https://bitcointalk.org/index.php?topic=45849.0

[tacotime]

It should be pointed out that there is nothing impossible in doing  mining through a browser app, irrespective of whether that is cpu or gpu mining, and that browser-mining does not itself make scrypt GPU-friendly

(but it does bring up an interesting question as to possibility for mining-enabled "rich content" banners that bring you both ad-money and coinsez)

as to TBX memhardness, this is relevant https://bitcointalk.org/index.php?topic=45849.0

I see now,

Basically, instead of aiming for "enough memory use to hit external memory on any device", aiming for "small enough to fit in L2 cache on CPUs, big enough to require too much on-chip memory/cache for running enough parallel instances to make GPU/FPGA/VLSI worth it."

Which makes sense.  But most CPUs have L3 now too, so why not use a problem size that is effective into that range as well?

This article too helps make sense of it:

Another important distinction in memory performance between the GPU and the CPU is the role of the cache. Unlike the cache on the CPU, the GPU texture cache exists primarily to accelerate texture filtering. As a result, GPU caches need to be only as large as the size of the filter kernel for the texture sampler (typically only a few texels), which is too small to be useful for general-purpose computation. GPU cache formats are also optimized for locality in two dimensions, which is not always desirable. This is in contrast to the Pentium 4 cache, which operates at a much higher clock rate and contains megabytes of data. In addition, the Pentium 4 is able to cache both read and write memory operations, while the GPU cache is designed for read-only texture data. Any data written to memory (that is, the frame buffer) is not cached but written out to memory.

What does this mean for general-purpose computation on GPUs? The read-write CPU cache permits programmers to optimize algorithms to operate primarily out of the cache. For example, if your application data set is relatively small, it may fit entirely inside the Pentium 4 cache. Even with larger data sets, an application writer can "block" the computation to ensure that most reads and writes occur in the cache. In contrast, the limited size and read-only nature of the GPU cache puts it at a significant disadvantage. Therefore, an application that is more limited by sequential or random read bandwidth, such as adding two large vectors, will see much more significant performance improvements when ported to the GPU. The vector addition example sequentially reads and writes large vectors with no reuse of the data—an optimal access pattern on the GPU.

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter32.html

So as long as the algorithm requires a cache utilization of above 128kB, it will probably be pretty slow on ASICs or GPUs.  This is not an easily remedied problem because the only way to make this cache memory to physically add billions of more transistors onto the die for it.

[tacotime]

In other news post your K/H rates

Phenom II 1055T @ 3.8GHz/2.6GHz NB:
1.78KH/s per core

Phenom II 940BE @ 3.6GHz/2.0GHz NB:
1.75KH/s per core

Getting about 150 TBX/day solo mining

[ArtForz]

Good doggie.

Now play dead.

Good puppet master.

Now go pump and dump them brix !!! Wonder why TBX price is so low now  

On another note, what about our genius' revelation ? BitcoinExpress said that virtually all these CPU only currencies can easily be made into GPU currencies by IE9 hardware accelerator !? How true is that for Tenebrix ?

If that's the case they should release this for everyone to use.

The script source code is here: http://cpansearch.perl.org/src/GRAY/Crypt-Scrypt-0.05/src/src/lib/crypto/crypto_scrypt-sse.c

But...  this algorithm is supposed to be memory-hard but only takes 7MB of RAM on my system? (minerd.exe)  But maybe memory-hard in this instance refers to cache size on the CPU?  GPUs are based around something requiring large amounts of sequential memory access, and if the data is not constantly being reused but instead overwritten GPU computing might be inefficient.  An easy way of destroying GPU efficiency is just to make an algorithm require it to access memory randomly instead of sequentially, but the same goes for CPUs...  So the only thing I can think of that this algorithm would do to make it GPU proof would be requiring to read and write to the cache memory that is on board a lot.  There should be no way GPUs can compete with large CPU level 2 and 3 caches that have way faster write rates.

Yup, 128KiB, which goes for the "small enough to easily fit in L2, big enough to not be able to fit more than a few instances in a GPUs on-chip memory/caches" point.
If I could change the parameters again I'd probably add more margin and go for scrypt(4096,2,1) = 1MB of randomly-accessed-array per instance.
Still small enough to mostly hit L2 on a CPU, but even on future GPUs with several MB of fast on-chip cache/store you could only fit a few instances.
Should do about 300 hash/s on a high end cpu core, at least 50 or so on a crappy one, so it'd be barely fast enough to not hinder block verification *too* much (you'd have to add some protection to avoid having your node spammed with bullshit blocks, but nothing too fancy).
It'd also pretty much eliminate Cell as a contender (SPEs local memory is 256KiB...) and completely eliminate low end FPGAs (LX150 only has ~ 512KiB total block ram, and external memory is *way* too slow to make sense).
Going for L3 or external memory is imo a bad idea in this case as that's a shared resource = running a miner on even one core pretty much kills memory subsystem performance.

[Lolcust]

Well, should the need arise, TBX could make a PoW "update" + "anti-blockspam" at nHeight > x, right ?

Also, I'd feel bad about throwing out PS 3 hobbyists completely (I'd be quite content with making dedicated PS3 farms comparatively uncompetitive while leaving opportunistic gamers in)

[tacotime]

Well, should the need arise, TBX could make a PoW "update" + "anti-blockspam" at nHeight > x, right ?

Also, I'd feel bad about throwing out PS 3 hobbyists completely (I'd be quite content with making dedicated PS3 farms comparatively uncompetitive while leaving opportunistic gamers in)

I don't think Cell will have a huge comparative advantage due to only have 7 SPEs clocked at 3GHz...  The TDP is similar for Cell (~120W for older models and ~80W for newer ones) and it would probably have performance comparable to a Phenom II X6 if that.  Not only that, but PS3s probably don't have the means to properly thermally regulate themselves in comparison to computers and would face shorter lifespans.

[Adamlm]

I have one question about solo mining: how many threads should I use in minerd on Core i5 2410M - 2 or 4 ? This processor has 2 cores but 4 threads.. ?

[Lolcust]

http://ark.intel.com/products/52224

Has hyper-threading, so up to 4, but I would advise no more than 3 unless it is a dedicated TBX mining station.

[Frozenace]

I turn on minerd when I go home from work, haha.

[Lolcust]

With expenses of zero, your profit is INFINIIITEEE!

[Bobnova]

Also illegal and likely to result in your termination if they find out.
People have been fired over running FAH/Rosetta on their work computers.

Then again, CPU coins are built for botnets and other dubiously legal applications, so have at.  Just don't bitch to us if you get fired.

[bulanula]

Also illegal and likely to result in your termination if they find out.
People have been fired over running FAH/Rosetta on their work computers.

Then again, CPU coins are built for botnets and other dubiously legal applications, so have at.  Just don't bitch to us if you get fired.

And believe me, they WILL find out when the computer is sluggish and somebody reports it to the IT people and they find your little trojan.

[Lolcust]

Well, if he does it right, he can actually claim that it was done by a trojan

[grod]

Hell, if I found out my employee was stealing power and running something that might destroy company property (just what are the CPU temps on that work machine overnight, anyway?) I'd not only terminate them but I'd see if company counsel can get an embezzlement criminal charge to stick.

Granted, your risk is basically 0.  But so is your reward.  Meh.  Go nuts, but yeah.  No whining if you get canned for cause.

[Lolcust]

Wouldn't you first investigate as to whether it was the employee or some third-party Evil h4x0r ? ~__^

[grod]

Wouldn't you first investigate as to whether it was the employee or some third-party Evil h4x0r ? ~__^

Oh absolutely.  To avoid paying unemployment (never mind the embezzlement thing) you have to have a pretty good case.  Luckily IT-manged corporate PCs have very good monitoring and session recording on par with malware.  Wouldn't take much to show the employee was the one starting the "trojan" before going home every night.  Might even get a bunch of non-business related web browsing for good measure.

[bulanula]

Wouldn't you first investigate as to whether it was the employee or some third-party Evil h4x0r ? ~__^

Nope. Occam's Razor.

It is simpler proposition that your employee looked to scam you rather than some aliens mining on your CPUs etc. !

[Lolcust]

Note to community:
Do due diligence and make it look really hard to distinguish from actual third party invasion. If you can. ~__^

Wouldn't you first investigate as to whether it was the employee or some third-party Evil h4x0r ? ~__^

Nope. Occam's Razor.

It is simpler proposition that your employee looked to scam you rather than some aliens mining on your CPUs etc. !

While aliens are indeed implausible, third party  infecting a work PC with one of them "miner" strains through them intertubes is not.

[Bobnova]

Are you honestly supporting theft and botnets?
Cause that's really what it's starting to look like.
No need for the boxes to be sluggish, assign the tasks low priority and run threads equal to 75% of the CPU, rounding down.