cbuchner1
|
|
October 17, 2014, 05:43:32 PM Last edit: October 17, 2014, 05:56:04 PM by cbuchner1 |
|
those things are nothing but a bunch of p3 cores wonder what my dual tualatins can do at 1.8ghz lol
My "entry level" model has 57 superscalar Pentium cores with a sexy 512 bit vector unit (somewhat similar to AVX2), and 28.5 MB of distributed L2 cache connected by a ring bus to be specific - and 6 GB of RAM with a nicely high 240 GB/s memory bandwidth don't you dare compare this to dual tualatins
|
|
|
|
djm34
Legendary
Offline
Activity: 1400
Merit: 1050
|
|
October 17, 2014, 06:00:10 PM |
|
those things are nothing but a bunch of p3 cores wonder what my dual tualatins can do at 1.8ghz lol
My "entry level" model has 57 superscalar Pentium cores with a sexy 512 bit vector unit (somewhat similar to AVX2), and 28.5 MB of distributed L2 cache connected by a ring bus to be specific - and 6 GB of RAM with a nicely high 240 GB/s memory bandwidth don't you dare compare this to dual tualatins have you tried to run some cpu only algo on it ? (from what I read, you don't need to modify anything to parallelize (?))
|
djm34 facebook pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
cbuchner1
|
|
October 17, 2014, 08:14:29 PM |
|
have you tried to run some cpu only algo on it ? (from what I read, you don't need to modify anything to parallelize (?))
Eh no, without making use of this vector unit it's really pointless to run any scientific code on this device - and since this instruction set isn't AVX2 compatible you even have to develop entirely new optimized code and libraries. Intel already provides some useful libraries, but I really wonder if that includes any BIGNUM maths libraries for use in cryptography. Also: this does not support any previous Intel SIMD extensions like MME, SSE, SSE2, SSE3, SSE4.1 SSE4.2 or AVX instructions. So, just taking existing optimized code won't work either. But I'll stop discussing this board here right now, as it is off topic (oops, sorry!) Christian
|
|
|
|
kev7112001
|
|
October 17, 2014, 08:53:29 PM |
|
those things are nothing but a bunch of p3 cores wonder what my dual tualatins can do at 1.8ghz lol
My "entry level" model has 57 superscalar Pentium cores with a sexy 512 bit vector unit (somewhat similar to AVX2), and 28.5 MB of distributed L2 cache connected by a ring bus to be specific - and 6 GB of RAM with a nicely high 240 GB/s memory bandwidth don't you dare compare this to dual tualatins hey now i like my tualatins they can run crysis also beat the shit out of everyones p4 lol
|
MCXNOW MODERATOR
|
|
|
CryptoHobo
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
October 17, 2014, 09:16:06 PM |
|
and now i know why im not finding blocks anymore any news on the pool/'s?
|
|
|
|
cestballot
|
|
October 17, 2014, 11:46:23 PM |
|
Block 20000 diff 6.095448
|
|
|
|
yampi
|
|
October 18, 2014, 12:02:05 AM |
|
I am expecting that a pool will gain more than 50% of network hashrate when it gets launched.
|
|
|
|
Videlicet
Legendary
Offline
Activity: 868
Merit: 1058
Creator of Nexus http://nexus.io
|
|
October 18, 2014, 07:16:47 PM |
|
Yampi,
A] There will be multiple pools since I am releasing the pools open source B] The Hashing Channel will break Prime Channel streaks and vice-versa C] The Decentralized Checkpoints only allow the Main Chain to be built, not overwritten.
All this being said, we don't have to worry about 50% hashrates anymore. Each Feature reinforces the last to secure the Coinshield Network. Viz.
|
[ Nexus] Created by Viz. [ Videlicet] : "videre licet - it may be seen; evidently; clearly"
|
|
|
vedran82
Member
Offline
Activity: 111
Merit: 10
|
|
October 19, 2014, 11:50:44 AM |
|
Yampi,
A] There will be multiple pools since I am releasing the pools open source B] The Hashing Channel will break Prime Channel streaks and vice-versa C] The Decentralized Checkpoints only allow the Main Chain to be built, not overwritten.
All this being said, we don't have to worry about 50% hashrates anymore. Each Feature reinforces the last to secure the Coinshield Network. Viz.
You didn't answer my question. Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
|
|
|
|
cbuchner1
|
|
October 19, 2014, 01:48:02 PM Last edit: October 20, 2014, 06:39:34 PM by cbuchner1 |
|
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH (Chris84 on bitcointalk) and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version. Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all.
|
|
|
|
CryptoHobo
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
October 19, 2014, 06:51:44 PM |
|
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version. Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all. personally i find you guys inspiring, I've even started trying to code again!!
|
|
|
|
vedran82
Member
Offline
Activity: 111
Merit: 10
|
|
October 19, 2014, 06:59:14 PM |
|
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version. Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all. It doesn't matter if it is you or someone else, although I admire your work. You didn't get me. Supercomputing asked Viz in this thread should he make GPU miner for CPU channel. Viz posted that he wants this to remain CPU only. So I am asking him how fair would it be when he knows that multiple devs already use GPU miner. EDIT: and of course, like I told before, I think you have to be payed for your time and knowledge, it just not fair from coin devs side not to allow public GPU miner. Personally, I'm fine with this too.
|
|
|
|
Videlicet
Legendary
Offline
Activity: 868
Merit: 1058
Creator of Nexus http://nexus.io
|
|
October 19, 2014, 10:04:41 PM |
|
Everyone,
Supercomputing is on that as far as I understand [He said by the end of the year]; we are working within the circumstances presented before us. Our plans is to develop a CPU only channel with some GPU developers who will know how to make it deliberately difficulty to build a GPU miner for. This is of course down the line. I said to Supercomputing I am more concerned with getting the GPU Channel Activated before worrying about GPU miners for CPU Channel. Most likely the course that is going to become final is the Hashing Channel being the ASIC, Prime Channel being GPU, and new CPU channel being CPU only. I want with my efforts and others combined to be able to develop a stable CPU channel so that the little miners can eat too; my goal is to make it as fair as possible, but possible here is a very strong word.
Thank You, Viz.
|
[ Nexus] Created by Viz. [ Videlicet] : "videre licet - it may be seen; evidently; clearly"
|
|
|
jorneyflair
|
|
October 20, 2014, 04:54:20 AM |
|
so quiet here recently
|
|
|
|
cbuchner1
|
|
October 20, 2014, 08:57:43 AM Last edit: October 20, 2014, 07:56:09 PM by cbuchner1 |
|
I would agree with Videlicet's intent to properly (and completely) launch this coin before making hardforks in order to improve on existing features (like a more GPU resistant CPU mining channel).
In particular I'd like to see how the "assimilation" feature of this coin will play out. Will it really be able to eradicate other coins from the markets? What if some whale decides to play games with CoinShield, trying to defend the coins that CoinShield targets for assimilation? This will be fun to observe.
|
|
|
|
Chris84
Newbie
Offline
Activity: 69
Merit: 0
|
|
October 20, 2014, 05:36:45 PM |
|
Hiho,
I followed your discussion here and I also wanna write down some lines:
First things first: I believe, nobody will be able to write an algorithm that can be executed on a CPU but not on a GPU or an ASIC. Why? Because both are only some pieces of silicium that can do some low-level bitoperations. And both are programmable. So, basically it's useless to declare something as "CPU only". The meaning behind this term is to say "nobody is able to execute this algorithm on a high parallel computer (the GPU) more efficent, than on an sequential computer (the CPU)". And many algorithms out there are only "CPU only", because they make a hugh effort to become ported. (maybe including the seach for primeclusters)
So, what's an argument against a gpu-miner for prime-clusters? The proof that it is posible (or not) worths more than the native belief, that this algorithm is "CPU only". Why? Because this is very important for the belief in the coin. Imagine, what would be, if bitcoin were declared as "CPU only" and nearly nobody ever checked it? thousands of people would mine with a CPU, and maybe one or two hidden with ASICs...
On the other side, if there is a real "CPU only" coin that worth something, what will happen? First, the powercosts are very different from country to country. So, people from countrys with high power-costs arn't able to get in the power-costs (that's also for GPU-miners, but with an eye on the "fairness"...). The second problem is, that CPU-power is easier and cheaper (in compare with the hardware-costs) to rent than GPU-power. So, some people will rent many servers and the "small miner" will never be able get any coins.
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize. The best way (in my opinion) is to use a high amout of memory per thread. This isn't a problem for CPUs, but for GPUs, where you wanna have hundreds of threads running parallel.
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
So, don't worry, all we do is playing around with this. Our miner will never become "dominating", we are still at a point where mondern CPUs are more efficent. But we wanna take a look, how fast we can become (that is our hobby).
|
|
|
|
gatra
|
|
October 21, 2014, 02:32:05 AM |
|
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize.
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
BUT.... this is not inefficient to parallize and doesn't require much RAM per thread: all threads could work on the same sieve... The sieve of Eratosthenes is highly parallelizable: just use one different prime per thread. After that, testing the remaining candidates is also a highly parallelizable task. After all, the PoW has to be a parallelizable thing by nature, since all miners try to solve a block in parallel. So it's hard to make an algo that's more efficiently mined by a CPU than a GPU.
|
|
|
|
Chris84
Newbie
Offline
Activity: 69
Merit: 0
|
|
October 21, 2014, 09:58:58 AM |
|
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize.
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
BUT.... this is not inefficient to parallize and doesn't require much RAM per thread: all threads could work on the same sieve... The sieve of Eratosthenes is highly parallelizable: just use one different prime per thread. After that, testing the remaining candidates is also a highly parallelizable task. After all, the PoW has to be a parallelizable thing by nature, since all miners try to solve a block in parallel. So it's hard to make an algo that's more efficiently mined by a CPU than a GPU. Sure, you are able to parallize the algorithm itself. But you need many memory-accesses... And yes, you can also try to solve multiple blocks at a time, but here comes the high memory usage (if you wanna find a fair amount of candidates)... I don't know, how efficient this would be
|
|
|
|
skunk
|
|
October 21, 2014, 12:05:45 PM |
|
hi viz, are gpu miners ready for tonight's channel launch?
|
|
|
|
mumus
|
|
October 21, 2014, 12:51:59 PM |
|
/CoinShield/cpu# make -f makefile.unix g++ -c -pthread -static-libgcc -static-libstdc++ -Wall -Wextra -Wno-sign-compare -Wno-invalid-offsetof -Wno-unused-parameter -Wformat -Wformat-security -g -DBOOST_SPIRIT_THREADSAFE -DBOOST_THREAD_USE_LIB -I/home/CoinShield/cpu -I/home/CoinShield/cpu/build -I/home/CoinShield/cpu/hash -O2 -MMD -o build/prime.o prime.cpp In file included from util.h:5:0, from types.h:4, from core.h:5, from prime.cpp:9: hash/templates.h: In function ‘uint256 SK256(const std::vector<unsigned char>&)’: hash/templates.h:40:23: warning: unused variable ‘pblank’ [-Wunused-variable] In file included from core.h:5:0, from prime.cpp:9: types.h: At global scope: types.h:26:19: error: ISO C++ forbids initialization of member ‘fStopped’ [-fpermissive] types.h:26:19: error: making ‘fStopped’ static [-fpermissive] types.h:26:19: error: ISO C++ forbids in-class initialization of non-const static member ‘fStopped’ types.h: In member function ‘LLP:DOS_Score& LLP:DOS_Score:perator++(int)’: types.h:109:3: warning: no return statement in function returning non-void [-Wreturn-type] types.h: In constructor ‘LLP:DOS_Filter:DOS_Filter(unsigned int)’: types.h:119:22: warning: ‘LLP:DOS_Filter::cSCORE’ will be initialized after [-Wreorder] types.h:116:16: warning: ‘unsigned int LLP:DOS_Filter::BANTIME’ [-Wreorder] types.h:121:3: warning: when initialized here [-Wreorder] In file included from core.h:5:0, from prime.cpp:9: types.h: In constructor ‘LLP::Connection::Connection()’: types.h:231:18: warning: ‘LLP::Connection:DOS’ will be initialized after [-Wreorder] types.h:204:17: warning: ‘LLP::Packet LLP::Connection::INCOMING’ [-Wreorder] types.h:235:3: warning: when initialized here [-Wreorder] types.h: In constructor ‘LLP::Connection::Connection(LLP::Socket_t, LLP:DOS_Filter*)’: types.h:231:18: warning: ‘LLP::Connection:DOS’ will be initialized after [-Wreorder] types.h:204:17: warning: ‘LLP::Packet LLP::Connection::INCOMING’ [-Wreorder] types.h:236:3: warning: when initialized here [-Wreorder] In file included from prime.cpp:9:0: core.h: In constructor ‘LLP::Outbound::Outbound(std::string, std::string)’: core.h:66:19: warning: ‘LLP::Outbound::PORT’ will be initialized after [-Wreorder] core.h:87:79: warning: base ‘LLP::Connection’ [-Wreorder] core.h:87:3: warning: when initialized here [-Wreorder] prime.cpp: In function ‘void Core::InitializePrimes()’: prime.cpp:160:69: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘__mpz_struct*’ [-Wformat] prime.cpp: In function ‘double Core::GetPrimeDifficulty(CBigNum, int)’: prime.cpp:193:13: warning: statement has no effect [-Wunused-value] prime.cpp: In function ‘std::vector<unsigned int> Core::Eratosthenes(int)’: prime.cpp:258:81: warning: format ‘%i’ expects argument of type ‘int’, but argument 2 has type ‘std::vector<unsigned int>::size_type {aka long unsigned int}’ [-Wformat] prime.cpp: In function ‘long unsigned int Core::PrimeSieve(CBigNum, unsigned int, unsigned int)’: prime.cpp:502:8: warning: name lookup of ‘i’ changed [enabled by default] prime.cpp:332:16: warning: matches this ‘i’ under ISO standard rules [enabled by default] prime.cpp:375:21: warning: matches this ‘i’ under old rules [enabled by default] prime.cpp:527:15: warning: statement has no effect [-Wunused-value] In file included from /usr/include/boost/asio/read.hpp:540:0, from /usr/include/boost/asio.hpp:76, from util.h:23, from types.h:4, from core.h:5, from prime.cpp:9: /usr/include/boost/asio/impl/read.hpp: In function ‘std::size_t boost::asio::read(SyncReadStream&, const MutableBufferSequence&, CompletionCondition, boost::system::error_code&) [with SyncReadStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, MutableBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’: /usr/include/boost/asio/impl/read.hpp:71:76: instantiated from ‘std::size_t boost::asio::read(SyncReadStream&, const MutableBufferSequence&, CompletionCondition) [with SyncReadStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, MutableBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’ types.h:334:186: instantiated from here /usr/include/boost/asio/impl/read.hpp:43:3: error: no match for call to ‘(boost::system::error_code) (boost::system::error_code&, std::size_t&)’ /usr/include/boost/system/error_code.hpp:310:11: note: candidate is: /usr/include/boost/asio/impl/read.hpp:43:3: note: boost::system::error_code::unspecified_bool_type {aka void (*)()} <conversion> /usr/include/boost/asio/impl/read.hpp:43:3: note: candidate expects 1 argument, 3 provided /usr/include/boost/asio/impl/read.hpp:71:76: instantiated from ‘std::size_t boost::asio::read(SyncReadStream&, const MutableBufferSequence&, CompletionCondition) [with SyncReadStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, MutableBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’ types.h:334:186: instantiated from here /usr/include/boost/asio/impl/read.hpp:50:5: error: no match for call to ‘(boost::system::error_code) (boost::system::error_code&, std::size_t&)’ /usr/include/boost/system/error_code.hpp:310:11: note: candidate is: /usr/include/boost/asio/impl/read.hpp:50:5: note: boost::system::error_code::unspecified_bool_type {aka void (*)()} <conversion> /usr/include/boost/asio/impl/read.hpp:50:5: note: candidate expects 1 argument, 3 provided In file included from /usr/include/boost/asio/write.hpp:537:0, from /usr/include/boost/asio/buffered_write_stream.hpp:30, from /usr/include/boost/asio/buffered_stream.hpp:21, from /usr/include/boost/asio.hpp:34, from util.h:23, from types.h:4, from core.h:5, from prime.cpp:9: /usr/include/boost/asio/impl/write.hpp: In function ‘std::size_t boost::asio::write(SyncWriteStream&, const ConstBufferSequence&, CompletionCondition, boost::system::error_code&) [with SyncWriteStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, ConstBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’: /usr/include/boost/asio/impl/write.hpp:69:77: instantiated from ‘std::size_t boost::asio::write(SyncWriteStream&, const ConstBufferSequence&, CompletionCondition) [with SyncWriteStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, ConstBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’ types.h:339:165: instantiated from here /usr/include/boost/asio/impl/write.hpp:41:3: error: no match for call to ‘(boost::system::error_code) (boost::system::error_code&, std::size_t&)’ /usr/include/boost/system/error_code.hpp:310:11: note: candidate is: /usr/include/boost/asio/impl/write.hpp:41:3: note: boost::system::error_code::unspecified_bool_type {aka void (*)()} <conversion> /usr/include/boost/asio/impl/write.hpp:41:3: note: candidate expects 1 argument, 3 provided /usr/include/boost/asio/impl/write.hpp:69:77: instantiated from ‘std::size_t boost::asio::write(SyncWriteStream&, const ConstBufferSequence&, CompletionCondition) [with SyncWriteStream = boost::asio::basic_stream_socket<boost::asio::ip:: tcp>, ConstBufferSequence = boost::asio::mutable_buffers_1, CompletionCondition = boost::system::error_code, std::size_t = long unsigned int]’ types.h:339:165: instantiated from here /usr/include/boost/asio/impl/write.hpp:48:5: error: no match for call to ‘(boost::system::error_code) (boost::system::error_code&, std::size_t&)’ /usr/include/boost/system/error_code.hpp:310:11: note: candidate is: /usr/include/boost/asio/impl/write.hpp:48:5: note: boost::system::error_code::unspecified_bool_type {aka void (*)()} <conversion> /usr/include/boost/asio/impl/write.hpp:48:5: note: candidate expects 1 argument, 3 provided make: *** [build/prime.o] Error 1 all lib looks good, but probably bad version for one. any idear to solve this on V1.2 mining code? Best regards In types.h the Timer class should start like this: class Timer { private: boost::posix_time::ptime TIMER_START, TIMER_END; bool fStopped; public: Timer() { fStopped = false; } inline void Start() { TIMER_START = boost::posix_time::microsec_clock::local_time(); fStopped = false; }
and in the miner.cpp at the beginning of the MinerThread class should be look like this: class MinerThread { public: CBlock* BLOCK; bool fBlockFound, fNewBlock; LLP::Thread_t THREAD; boost::mutex MUTEX; unsigned int nSearches, nPrimes; MinerThread() : BLOCK(NULL), fBlockFound(false), fNewBlock(true), THREAD(boost::bind(&MinerThread::PrimeMiner, this)) { nSearches = 0; nPrimes = 0; }
|
|
|
|
|