00:27 < eeeee> serverless as in without a game server, not the cloud or internet of shit meaning 00:51 < needs1> I don't think you need a blockchain to achieve that, do you? 00:57 < WolfAlex_> needs1: eeeee: you can not use a blockchain for that, blockchain always also means a currency (otherwise -> why would someone "mine" a block) 00:58 < WolfAlex_> poor word "blockchain" getting abused 00:58 < needs1> Not really, blockchain could work even without incentive for mining 00:59 < vali> Hello my friends. 01:01 < WolfAlex_> needs1: no, does not work; how do you think it would work? 01:02 <@heinrich5991> without an incentive for mining, it's hard to determine the winner chain 01:02 <@heinrich5991> that's the only thing being lost without an incentive for mining if I see that correctly, maybe needs1 doesn't need that 01:04 < WolfAlex_> thats the idea of the blockchain... getting one database that every participant agrees on 01:07 < needs1> heinrich5991: My point is that mining reward is not necessary to get a blockchain working. However it might be needed to actually have enough people mining to secure the blockchain, from a practical point of view. 01:09 < needs1> It is like droping any notion of money from Bitcoin, leaving only blocks with some kind of meaningful data. 01:10 < needs1> meaningful data must have some kind of ordering so that the longest blockchain can still be infered 01:11 < WolfAlex_> needs1: it is needed. if there is no reward the costs of attacking the blockchain will fall by time. the miner wont invent in new eq(why?) 01:11 < WolfAlex_> why -> because why should they 01:12 < needs1> From a practical point of view, miner incentive is likely to be needed to sustain a good enough difficulty for 50% attack. 01:14 < needs1> I'm sure that some kind of blockchain without any incentive for miners could still bring anough people to mine, just for the sake of securing the system. I would personally. 01:18 < needs1> That could make huge mining farm very costly, hence reducing the probability of someone with more than 50% hashrate 01:18 < needs1> Pools will still be a problem tho 01:21 < WolfAlex_> i'm also sure it it not possible 01:21 < WolfAlex_> also there is no reason for pools (because there is nothing to share...) 01:21 < needs1> Good point 03:00 < vali> Im sexy and I know i, You are ugly and you show it 13:16 <@heinrich5991> if I can choose between a syscall and a memory allocation, can one say which one is generally faster? 13:50 < needs1> Memory allocation may need a syscall anyway 13:50 < needs1> Either brk() or mmap() if I'm not mistaken. 13:59 < deen> heinrich5991: I don't think one is always faster than the other. syscalls can also be replaced by your c lib with userspace code 13:59 < deen> why not measure it? 14:21 <@heinrich5991> needs1: the key is "it *may* need a syscall". so does that mean it will generally be faster? 14:22 <@heinrich5991> deen: in that case I'm reading from a file, I don't think the c lib does stuff with that (with read, not fread) 14:22 <@minus> if it's small allocations i guess 14:22 <@minus> just mmap the file 14:23 <@heinrich5991> (one downside of mmap is the inability to report errors) 14:27 < deen> heinrich5991: I remember doing some benchmarks and manually reading to 4k buffer was same performance as memmap 14:28 < deen> very basic stuff though: https://github.com/def-/nim-unsorted/blob/master/wcl.nim 15:51 < needs1> Maybe ask ##c on freenode 15:52 <@heinrich5991> won't they tell me that there is no concept of syscalls in C? ^^ 15:53 < koomi> just test it for your specific use case, noone will be able to give you a general answer 15:53 <@heinrich5991> koomi: why not? to me, this seems like it could be a case where it is clear-cut 15:54 <@heinrich5991> also, I'm probably not gonna test it for every use case, I'd like to have something to default to if I don't want to benchmark it 15:55 < needs1> Then using a fixed size like 4k should be good enough I guess 15:57 < koomi> heinrich5991: because in general you can't say what your libc will do 15:58 < koomi> you can use fread and let the libc deal with making that tradeoff 15:58 < koomi> and you'll probably want to measure anyway, regardless of what someone on IRC tells you 15:59 < deen> koomi: I think everyone on IRC told him to measure :P 15:59 <@heinrich5991> measuring is a solution that doesn't scale 15:59 <@heinrich5991> I can't measure performance of my program every time I read from a file 16:00 < koomi> but believing stuff you heard on IRC does? 16:00 < koomi> and that's why you let libc deal with it 16:01 < deen> which is faster could also change with time, depending on OS, libc, CPU arch etc 16:02 < deen> best to measure on one instance, and implement it for that. later when someone reports that another approach is faster on another system, you can #ifdef or something 16:03 < deen> but glibc source code was also surprisingly readable last time I checked something, so that might give some more insight 16:05 * koomi would check if reading that file is actually a bottleneck and if so, if it's not the disk that is slow before optimizing anything (beware caching) 16:05 < koomi> glibc? readable? 16:05 < koomi> you must have looked at a different glibc than I did 16:06 < koomi> it's layers upon layers of macros in my experience 16:22 < deen> maybe I just read the wrong part, who knows