thoughts?
Targeted at Bitcoin/Namecoin full nodes.
If you want to run (only) MaidSafe, buy Raspberry Pi or something cheaper and with more RAM.
The main obvious remark is that with Rust we have to wait a wee while to regain ARM support. Other than that, seems like a really well balanced hardware spec for a SAFE node. But yes, it is rather expensive - I hadnāt looked at the price yet.
Nice to have more options, and great to see open source hardware. Pricey though, and overkill for SAFE maybe?
Much depends on how quickly I can push decentralised computing. a quad-core 2 GHz processor is pretty sweet though for such a board
i really would like to see decentralised computing soon in maidsafe =)
quad-core that fast really seems cool, but wonāt the parallela board ( The Parallella Computer ā AI ) be more efficient in distributed computing ā¦? of course each core is only 700 mhz but programs being made for parallel computation will be faster with 160.7=11.2GHz than with 4x=8Ghz i suppose ⦠okay not really a huge difference and the parallela board only has 1GB Ram (chainbot 2GB) ⦠but the parallela board is roughly half the price, so ā¦
oh i forgot ⦠parallela 160.7+21.2 = 13.6Ghz (If I remember correctly) But ARM like the raspberry
GPU architectures complement general purpose CPU architectures. Much will depend on the application, and support for both only makes sense
oh of course you are right! i completely forgot about the GPU =)
but that in mind ⦠it could be a little bit tricky to hand the right task to the right node ⦠iām not a specialist in these things ⦠but seems to me the ranking system would get pretty complex if you really want to get the best performance for every task ā¦?
Thereās nothing to distribute with Parallella..
Data distribution is done by MaidSafe s/w.
and if you do have 18 cores to offer maidsafe will be able to accept 18 tasks in parallel i would suppose ā¦
if that wouldnāt be the case only one core of each participant in the maidsafe network could be used ⦠i donāt see how that would make sense ⦠everyone would have to start many instances of maidsafe to be able to offer more than one core to the network ā¦
- MaidSafe is not going to be CPU-intensive
- Even if it was, task parallelization wouldnāt buy you anything since data movement between different systems would cost more than one could gain by distributing compute workload across different systems
- In previous discussions most participants agreed that MaidSafe system will be idle most of the time, with occasional āhitsā to fetch a non-cached data chunk.
sorry i donāt mean to be rude ⦠but did you read the posts above?
we were talking about distributed computing inside maidsafe network, which would make maidsafe not only a super-huge cloud but also one extremely cool supercomputer that everybody could use at low cost
sorry that probably was a little bit harsh - i know iām new here but iām not stupid - only for a data node it wouldnāt think about needing 18 cpus for 100 dollars if a raspberry costs way less ā¦
oh haha sorry i do want to correct myself ⦠for a farmer it might be wise to take the 18 cores ⦠18 instances of maidsafe >>> ~6 dollars per instance running (5/18 Watt per instance peak power consumption) - the limiting factors would be your network connection and the Ram ⦠but depending on how much idle time the vaults do have ⦠that might not be a huge problem ā¦
Yes, I read the post above. I explained what I think about the parallelization idea (why I think it doesnāt make sense).
But for any given node, the app (whatever it is) would have to fetch data from the network.
What I claim is that this part cannot be efficient because for MaidSafe you would want to buy h/w that is just enough to power MaidSafe. If you wanted to (also) run some other workload (like this parallel stuff), then it would either perform very poorly, OR youād have to overprovision h/w when you buy it, and after that your parallel apps would have to fetch data they work on from the network which would be inefficient and very likely impact your chances to provide good farming service.
After all it seems you also recognize why itās a lot of trouble. A hosting company can give you a core of 64-bit Intel CPU, 512 MB RAM and 20GB SSD (should be enough for almost any distributed compute task) for $5/month. Compare that with the additional cost of overprovisioned farming rig and consider which of the two can actually perform useful, chargeable compute work.
hmmm - i would say there is pretty much speculation around here ā¦
in my experience with FEM my pc needed for an e.g. 100MB File and a single ~3GHz cpu + enough Ram 10-15min ⦠so letās solve it in parallel (100x) with 0.7GHz 100/1003/0.710min/100 = 26 seconds ⦠1 MB of data to download (of course you need to upload the results again and this is just a very rough estimation) ⦠but i would think there is enough time for down/upload and being busy most of the time ⦠and maybe even farming in between ā¦
I know iām speculating here too but that is how i think about it and why i think that way ⦠(but maybe i remember wrong⦠havenāt done simulations for a year⦠:-\ )
⦠and we havenāt seen it in action ⦠we donāt know when the first decentralized applications will come (or the ability to implement them ; ) ⦠weāll see what happens and how we can supply useful compute work =)
oh and again iāve been too fast ⦠yes with 18 cores youāll have not 1MB youāll have 18MB maybe down and up in 26 seconds ⦠you will obviously need a fast upload for that - yes
Just a note, for decentralised computing, it would precisely be interesting to run the computation on the node that is storing that data; there is an obvious problem that Self-Encryption would make this impossible (thatās what it is designed for), but data intended to be calculated upon should simply be stored differently then private data.
Yes, of course, thatās what MapReduce does. But apart from data access problem (which could conceivably addressed by ātrustless job containersā, or working on public data sets) youād also need to know where to dispatch jobs which would require that location of data chunks be disclosed to the compute job owner which would pose security risks.
those are the relevant questions indeed !
happy to keep such discussions going, because they are not all answered at this point
On the resources issue, i think itās a moot point because parallel computing isnāt about naked efficiency, itās about speeding things up to give new capabilities.
What I mean is: it might be more efficient to have a single processor and immediate access to all the relevant data, but it is going to take too long. So you waste a lot of time and energy dividing the problem up into little chunks that can be done in parallel. Thatās less efficient.
Now regarding SAFE, this would not be attractive to farmers unless they get treated for providing the excess CPU resource needed for this (as @janitor points out). So whether it āworksā (or rather what works) will depend on whether farming CPU is adequately catered for. Not at present maybe, but why not add this? zkSNARK might be part of this.
Itās not the only enabling factor, there are no doubt other hurdles, but the opportunity is so immense I think it will be worthwhile to put it mildly!
It will almost inevitably be part of enabling distributed computing that routing has some understanding of the ācomputational capabilitiesā of the nodes on its network. And as such the related question is indeed how should safecoin be allocated for these resources.
and @happybeing: thank you for bringing up this very valid point on high performance computing: itās a balancing act, and brute force parallelising it is rarely the best solution.
hmmm and as @janitor mentioned the 64bit; parallela and raspberry (i think) 32bit ⦠i assume youād have to decide to use either everywhere 32bit or every program has to be defined to run on a 32 or a 64 bit machine
(or maidsafe itself could identify and distribute it smart ⦠that would be awesome)