Conversation with #monero-pow at Fri 01 Mar 2019 06:10:29 PM EST on hyc@irc.freenode.net (irc)
(06:10:29 PM) #monero-pow: The topic for #monero-pow is: Discussing the future of Monero PoW. Chat log at http://highlandsun.com/hyc/monero-pow-0.txt[1] and -1.tx
(06:10:29 PM) #monero-pow: Topic for #monero-pow set by IsthmusCrypto!sid302307@gateway/web/irccloud.com/x-maqoxnwklscfpitx at 07:43:44 PM on 10/19/2018
(06:10:29 PM) List of 39 users: [ antanst8 ][ binaryFate ][ cjd ][ el00ruobuob ][ endogenic_ ][ geonic ][ gingeropolous ][ hyc ][ Inge- ][ investanto ][ Isthmus ][ johnhmay ][ jwinterm ][ kensheng ][ kenshi84 ][ kico ][ kinghat9 ][ klp ][ ksk ][ lithiumpt ][ moneromooo ][ [-mugatu-] ][ needmoney90 ][ OhGodAGirl ][ oneiric_ ][ parasew[m] ][ patap0n ][ philkode ][ rodolfo912 ][ scoobybejesus ][ sech1 ][ selsta ][ sgp_ ][ stoffu ][ suraeNoether_ ][ tevador ][ victorSN ][ vtnerd ][ wowario ]
(06:51:50 PM) midipoet [uid316937@gateway/web/irccloud.com/x-yezzobjsosfkxkzo] entered the room.
(07:10:56 PM) sech1 left the room (quit: Quit: Leaving).
(08:09:40 PM) kinghat9 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(08:10:00 PM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(08:52:45 PM) sgp_: stoffu advocating for ASIC-friendly algo in Aeon. Not sure if on-topic enough here: https://www.reddit.com/r/Aeon/comments/aw2xhn/proposal_to_switch_to_sha3_proof_of_work/[1]
(08:53:31 PM) sgp_: ^ contains some general arguments that have mostly been discussed before
(08:56:25 PM) hyc: meh. He's wrong.
(08:58:17 PM) hyc: and Aeon is barely a blip on the radar, not even on any major exchanges. them leading the way with SHA3 isn't going to draw *anybody's* attention in the ASIC/FPGA scene
(09:11:33 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:16:12 PM) hyc: Everybody in that discussion keeps saying "we tried to be ASIC-resistant and it didn't work" which is completely misrepresenting what "we" did.
(09:16:41 PM) hyc: we tossed out a couple temporary changes to give time for randomX to be finished.
(09:17:04 PM) hyc: they think because those temporary changes didn't have permanent effects, they were a failure. which is utterly stupid.
(09:17:44 PM) hyc: and stoffu and everyone else who is actively involved in MRL or development should know this
(09:18:07 PM) hyc: and should NOT be perpetuating this mis-represented story to the wider community
(09:19:11 PM) hyc: there's too many false assumptions in that thread. can't even get more than half way thru it.
(10:24:27 PM) oneiric_: the linked medium article was a good read. lot of variables at play
(10:25:42 PM) oneiric_: will be interesting to watch grin's experiment with dual pow play out
(10:26:07 PM) oneiric_: same with aeon, wish them luck if they decide on sha3
(10:31:13 PM) oneiric_: having an affordable foss asic design + plenty suppliers / makers would be dream
(10:31:48 PM) oneiric_: dunno how realistic that is short-medium term
(10:54:36 PM) stoffu: I understand and respect your view, and that’s why I believe adopting SHA3 could/might be barely possible for Aeon, never for Monero, and hence I never intend to bring this topic to Monero.
(10:55:12 PM) stoffu: Even Aeon won’t be able to do so, in which case I’ll launch a new coin.
(10:59:41 PM) stoffu: s/won’t be/might not be
(11:00:59 PM) oneiric_: yeah, that's cool that you're taking a measured approach
(11:25:40 PM) investanto left the room (quit: Quit: Changing servers).
(11:25:52 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(11:29:39 PM) wowario: all the noise from the “community” doesn’t really matter anyway, they will follow whatever Smooth and you decide to do
(11:44:42 PM) investanto left the room (quit: Quit: Changing servers).
(11:44:54 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(11:45:47 PM) stoffu: wowario: That’s definitely not true
(11:48:50 PM) jwinterm: does anyone think that network security is improved by attempting to keep consumer hardware viable? 
(11:49:04 PM) jwinterm: or it's just a matter of the block reward?
(12:39:47 AM) investanto left the room (quit: Quit: Changing servers).
(12:39:59 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:01:26 AM) ArticMine [~ArticMine@S0106ac202ecaeb73.vn.shawcable.net] entered the room.
(01:24:51 AM) investanto left the room (quit: Quit: Changing servers).
(01:41:05 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:48:49 AM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(02:07:49 AM) gethh [uid264798@gateway/web/irccloud.com/x-vwvwdiliwuqkdqbv] entered the room.
(02:19:49 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:35:15 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bdhrdwlpixgmdvws] entered the room.
(04:27:49 AM) wowario left the room (quit: Remote host closed the connection).
(04:27:49 AM) oneiric_ left the room (quit: Read error: Connection reset by peer).
(04:28:32 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(04:29:02 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(05:54:52 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(08:19:47 AM) antanst8: Regarding the AEON thing
(08:20:01 AM) tevador: this was interesting read: https://medium.com/@CobraBitcoin/the-sad-story-of-sha-256-and-why-we-need-a-new-pow-algorithm-6ffe9d919cfb[1]
(08:20:11 AM) antanst8: Repeating what I said on Twitter:
(08:20:18 AM) antanst8: If Monero adopts RandomX as a stopgap measure, it will be in an excellent position to reconsider it's ASIC resistant stance
(08:20:26 AM) antanst8: The "early-stage-monopoly" effect can be avoided by announcing an ASIC-friendly PoW one or two years before the switch.
(08:20:59 AM) antanst8: There's one chance to do this right, and that's by taking advantage of the time frame that RandomX will give us.
(08:22:29 AM) antanst8: By "doing this right" I mean ending the whole "fork twice a year with PoW changes" thing, that's clearly not sustainable in the future.
(08:22:46 AM) tevador: antanst8 I agree
(08:24:16 AM) tevador: but I'm not sure if announcing ASIC friendliness in advance is enough by itself to prevent monopolies
(08:24:38 AM) antanst8: The ASIC-friendly PoW can be phased in gradually, like the Grin guys have done. 
(08:24:53 AM) antanst8: tevador: Agreed, it's definitely not enough
(08:25:31 AM) antanst8: Look like how the Grin guys have done this, looks like it's working for them so far. Cuckatoo31 ASICS are already been developed I believe.
(08:26:55 AM) antanst8: Ideally the ASIC-friendly algorithm specs and the migration plan will be announced at the same time with the RandomX fork
(08:26:55 AM) antanst8: And afterwards, it's a matter of keeping our promise, I guess.
(08:33:00 AM) antanst8: tevador: I guess the larger the PoW migration window is and the easier the ASIC algo is implementable, the more chances that a monopoly will be avoided...but maybe I'm grossly simplifying things. Market is unpredictable.
(09:54:46 AM) gethh: Initializing 64 virtual machine(s) ...
(09:54:46 AM) gethh: Running benchmark (100000 nonces) ...
(09:54:46 AM) gethh: Calculated result: 6b75c9504202c15bc58d3579bb37f029c3fa711bad4a8182d7284ff612dc08f2
(09:54:46 AM) gethh: Performance: 11319.7 hashes per second
(10:01:51 AM) tevador: gethh what machine is this?
(10:02:26 AM) gethh: Epyc 7601 dual
(10:02:28 AM) tevador: also a 9 second test is probably too short
(10:03:26 AM) tevador: so it's NUMA
(10:03:39 AM) gethh: yes 8 way NUMA 
(10:03:49 AM) tevador: you can probably get 20+ KH/s by segmenting the nodes correctly
(10:03:59 AM) gethh: I think so
(10:04:17 AM) gethh: but strange thing with huge_pages
(10:04:25 AM) gethh: performance goes down to ~2k
(10:04:34 AM) tevador: https://github.com/tevador/RandomX/issues/25#issuecomment-468789587[1]
(10:04:52 AM) gethh: Dataset (4 GiB) initialized in 6.80591 s
(10:04:52 AM) gethh: Initializing 64 virtual machine(s) ...
(10:04:52 AM) gethh: Running benchmark (1000000 nonces) ...
(10:04:52 AM) gethh: Calculated result: 38f1097eb1f1a77973559d8142273db7de8e679303b6cdb6c46ea9e6420c5e8d
(10:04:52 AM) gethh: Performance: 17711 hashes per second
(10:05:35 AM) tevador: so maybe you could get 30 KH/s if you run once instance per node plus large pages
(10:05:58 AM) gethh: I will play with two instances and eight 
(10:06:12 AM) gethh: but I am getting AMD Rome tests soon
(10:06:21 AM) gethh: that is going to be interesting
(10:06:29 AM) gethh: 4MB L3 per core , 64 core per socket
(10:06:43 AM) tevador: yes, I'm also interested to see the results
(10:07:00 AM) tevador: they should be released in July, no?
(10:07:30 AM) tevador: it's also Ryzen 3000 series
(10:07:39 AM) gethh: around may 
(10:08:02 AM) gethh: they already have printed some larger than for tests quantity
(10:08:30 AM) tevador: on this arch, you can run 2 threads per core
(10:08:52 AM) tevador: should be a monster in RandomX
(10:09:20 AM) gethh: yea crazy numbers are possible like 80kh
(10:12:30 AM) gethh: 28800H/s with eight instances , one per numa node
(10:13:08 AM) gethh: seq 0 7 | xargs -P 0 -I node numactl -N node ./randomx --mine --init 8 --threads 8 100000
(10:13:14 AM) gethh: Performance: 3610.01 hashes per second
(10:13:18 AM) gethh: ...... etc
(10:19:27 AM) sech1: So we're getting the first RandomX ASIC this summer and it's called AMD Rome :D
(10:23:54 AM) tevador: pretty much :D
(10:24:33 AM) tevador: gethh can you post your result here? https://github.com/tevador/RandomX/issues/25[1]
(10:32:29 AM) gethh: sure
(10:42:36 AM) gethh: https://github.com/tevador/RandomX/issues/25#issuecomment-468931339[1]
(10:48:26 AM) moneromooo: That 4 GB buffer is usable by a single thread, right ? So a CPU with 4 cores can only use more than 1 if it has at least 8 GB free ?
(10:49:12 AM) tevador: moneromooo no, it's usable by all threads
(10:49:32 AM) tevador: just in the case of NUMA, it's better to have a separate buffer for each NUMA node
(10:49:47 AM) moneromooo: OK, thanks.
(10:51:16 AM) tevador: normally, each NUMA node has it's own memory controller and dedicated DIMMs
(10:51:26 AM) gethh: yep
(10:51:46 AM) gethh: however in Rome one will probably be good with one instance due to architecture
(10:52:38 AM) gethh: they go around numa issues with dedicated 14nm die for that stuff in CPU
(10:53:44 AM) gethh: maybe it will be optimal to set 4GB buffer per availiable memory channel or sth like that
(10:59:43 AM) tevador: I'd like to see the results from Threadripper 2990WX
(10:59:51 AM) tevador: it has 32 cores, but only 4 memory channels
(11:00:48 AM) tevador: so it could be memory bound to some extent
(11:00:48 AM) tevador: although DDR4 is much better for parallelism than DDR3
(11:02:09 AM) gethh: yea but the machine I test has only 0.5TB RAM in 64GB DIMMs
(11:02:17 AM) gethh: so 8 dimms for 2 sockets :)
(11:03:22 AM) gethh: I guess 2990WX will be easly 50+ % of that result
(11:04:05 AM) tevador: not so sure about it, 16 cores have to memory controller, so the latency will be higher there
(11:04:16 AM) tevador: have no* memory controller
(11:07:58 AM) gethh: ouch then you're right , I did not know about that
(11:08:36 AM) tevador: China is no longer shy about its ASICs: https://miningpoolstats.stream/monero[1]
(11:22:19 AM) wowario: antanst8: I agree post-RandomX, attention should shift to an ASIC-friendly PoW, but with the caveat that there would be an open hardware ASIC/FPGA design available in advance to the public
(11:31:23 AM) antanst8: wowario: That would be great if it happens
(11:49:34 AM) hyc: right, Rome has a central IO chiplet that all the CPU chiplets connect to, so should be UMA
(11:57:42 AM) tevador: hyc I think a hypothetical RandomX ASIC would look exactly like that
(11:59:42 AM) ksk left the room (quit: Killed (Sigyn (Spam is off topic on freenode.))).
(12:07:36 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(12:07:46 PM) tevador: lol, someone in supportXMR chat is calling monero devs incompetent for not forking "within hours of hashrate spiking"
(12:15:28 PM) needmoney90: Link pls 
(12:18:00 PM) sech1: http://supportxmr.chatango.com/[1]
(12:22:06 PM) hyc: so easy to direct from the sidelines
(12:24:11 PM) hyc: I'm presuming someone in our conversations is /u/exitingAvocader on r/monero
(12:25:21 PM) hyc: fireice must be pretty desperate to launch a 2nd attempt to shill CN-GPU in 2 weeks
(12:27:06 PM) hyc: I wonder what's psychocrypt's motivation for teaming up with a loser like fireice
(12:27:15 PM) hyc: even the ryo faithful see thru the BS https://www.reddit.com/r/CryptoNoteTech/comments/aw4jkq/cngpu_a_new_path_to_asic_resistance/ehlyqd6/
(12:27:16 PM) sech1: I'm eagerly waiting for CN-GPU to be adopted be many coins then ASIC'd to the ground
(12:27:22 PM) hyc: lol
(12:27:22 PM) sech1: just to watch them fail miserably
(12:27:47 PM) hyc: only tiny shitcoins would ever adopt it, nobody will budget an ASIC for that
(12:28:34 PM) hyc: https://coinmarketcap.com/currencies/ryo-currency/
(12:28:42 PM) tevador: CN-GPU is just the same situation repeating as with CN-heavy
(12:28:45 PM) hyc: market cap less than half a million
(12:28:54 PM) hyc: no ASIC maker could justify the effort
(12:29:17 PM) hyc: yeah, pure stupidity
(12:37:02 PM) tevador: found the original repo for CN-heavy: https://github.com/curie-kief/cryptonote-heavy-design[1]
(12:37:02 PM) tevador: 50% of the description is attacking Monero
(12:37:07 PM) tevador: same as CN-GPU
(12:38:39 PM) sgp_: not surprising
(12:38:56 PM) sgp_: they don't need to be right, they just need to be annoying
(01:18:06 PM) oneiric_: ^
(01:18:32 PM) tevador: someone should make a block of 3.141592653590 monero on 14th March (Pi day)
(01:18:32 PM) oneiric_: inorite, fuck people for trying different approaches. fucking idiots
(01:20:03 PM) oneiric_: would be pretty epic tevador
(01:20:31 PM) cjd: hey hey oneiric_ 
(01:20:57 PM) oneiric_: ho ho cjd
(01:21:16 PM) oneiric_: you up?
(01:21:24 PM) cjd: yeah, it's only 19:21
(01:21:36 PM) cjd: working on some stuff with posits (floating point standard)
(01:22:35 PM) cjd: I'd really like to shove some float operations into my PoW, but I want to use posits rather than ieee754 because PacketCrypt is really designed so that it will be easily mineable on "hardware that should exist" rather than current CPUs
(01:23:03 PM) cjd: and posits are really impressive
(01:23:17 PM) ***oneiric_ searches posits
(01:23:49 PM) tevador: never heard of posits
(01:24:55 PM) cjd: https://posithub.org/
(01:25:18 PM) cjd: They are more exact than ieee754 and they require significantly less hardware
(01:25:45 PM) cjd: the inverse of a number is it's 1's complement (IIRC) so you can divide by taking the 1's complement and multiplying
(01:26:14 PM) cjd: or something similarly simple, I don't remember exactly what the inverse is but division is trivially more expensive than multiplication
(01:28:15 PM) tevador: so what is the catch?
(01:28:23 PM) tevador: I'm guessing there must be some
(01:28:49 PM) cjd: https://www.youtube.com/watch?v=aP0Y1uAA-2Y[1]
(01:29:00 PM) cjd: AFAICT none, just that hardware doesn't currently support them
(01:29:55 PM) kinghat: bringing the 6276's out of retirement to see what they will do on the R and X.
(01:30:38 PM) cjd: The regime is kind of complicated to think about at first, it's a string of bits which is anywhere between 2 bits and <length of the entire posit>
(01:30:42 PM) kinghat: saw hyc post results of 62XX variant iirc.
(01:31:52 PM) cjd: every time the regime grows by 1, the number of bits available for the exponent and mantissa shrinks by 1, which makes a very nice "hump" shape of very high accuracy at the numbers near to 1 and lower and lower accuracy as the number approaches 0 or infinity
(01:32:23 PM) tevador: that sounds like it would be more complex in hardware
(01:32:56 PM) cjd: mmm, it's a CLZ and a shift I guess
(01:33:27 PM) cjd: apparently facebook has been experimenting with using posits in their AI stuff on FPGAs
(01:34:11 PM) cjd: because you can often use a posit16_t in place of a binary32
(01:35:03 PM) cjd: I really want to add some posit math to PacketCrypt just because I want someone to put posit math into a general purpose processor
(01:35:33 PM) cjd: that youtube is a cool thing to watch when you have an hour
(01:39:59 PM) tevador: sounds interesting, but the lack of compatible hardware makes it unusable
(01:40:31 PM) tevador: people use IEEE754 not because it's good but because their hardware supports it
(01:41:32 PM) cjd: yes
(01:41:36 PM) cjd: Your objectives are slightly different from mine
(01:42:06 PM) cjd: You're trying to prevent any ASIC from ever developing, I'm trying to guide the development of new processors through the PoW
(02:03:56 PM) hyc: kinghat yep, quad socket 16-core per socket
(02:07:34 PM) kinghat: whoops, your tests were quad?
(02:15:14 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:22:01 PM) hyc: yes
(02:23:25 PM) kinghat: mine are only dual boards. probably wont fare well then.
(02:31:10 PM) tevador: hyc can you retest the opterons and use only 7 threads per NUMA? I think it could run faster
(02:31:27 PM) tevador: due to cache sizes
(02:32:22 PM) gingeropolous: im currently testing on 6276, quad. prolly same mobo as hycs
(02:32:33 PM) gingeropolous: unfortunately only 4 gb per cpu
(02:33:11 PM) gingeropolous: hence why it prolly took 1.5 minutes to initialize
(02:34:22 PM) gingeropolous: these high end server #'s are ridiculous. 
(02:36:47 PM) tevador: gingeropolous then you have to run only 2 copies instead of 8
(02:36:55 PM) tevador: or maybe 3 copies
(02:37:17 PM) gingeropolous: yeah right now top shows like 1% CPU usage for the randomx threads
(02:37:45 PM) tevador: is it swapping?
(02:37:54 PM) tevador: if yes, then shut it down, no point
(02:37:58 PM) gingeropolous: probably. yeah
(02:38:18 PM) tevador: you would be lucky to get 0.1 H/s
(02:38:59 PM) gingeropolous: well i have no idea what numa is doing. should prolly read the manual. with 3 ... things.. i prolly need it to distribute the memory across all 4 nodes or something
(02:39:05 PM) gingeropolous: oh it finished with 3
(02:43:18 PM) rottensox left the room (quit: Remote host closed the connection).
(02:43:31 PM) tevador: quad 6276 has 8 numa nodes and you'd need at least 64 GB of RAM to make it run at full speed
(02:44:23 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:44:43 PM) tevador: since you have 16? GB, you can only run 3 copies of the dataset (12 GB total), but 5 of the 8 nodes will have to access the 'wrong' memory
(02:45:19 PM) tevador: so you should see 3 fast nodes and 5 slow ones
(02:52:16 PM) gingeropolous: and of course i can't figure out hugepages
(02:55:50 PM) gingeropolous: the standard sudo sysctl -w vm.nr_hugepages=128
(02:55:50 PM) gingeropolous:  does nuzzing
(03:01:13 PM) kinghat: lels i only have 1gb sticks of ram for these 6276s.
(03:01:20 PM) kinghat: even worth testing?
(03:03:00 PM) gingeropolous: so... how does randomx stand up to the economics of ASICs.... looks like the most beastly thing out there will get 28 kh/s. Anyone got a cost on that server? ebay is giving me $8k for a single 7601 epyc server
(03:03:27 PM) tevador: gingeropolous you need a lot more pages than 128, more like 2500 per instance of RandomX
(03:03:32 PM) tevador: since each page is 2 MB
(03:03:52 PM) gingeropolous: ah ok. i went up to 1024 and figured it was time to get advice
(03:05:06 PM) tevador: kinghat depends on how much RAM do you have in total
(03:05:25 PM) gingeropolous: the original cryptonight asics were what... 220 kh/s, and they were asking.... $3k?
(03:05:39 PM) tevador: $12k for the first batch
(03:05:48 PM) gingeropolous: wowzers
(03:06:25 PM) tevador: and you cannot directly compare CN and RX hashrates
(03:06:40 PM) gingeropolous: ok. And consumer grade CPUs are getting somewhere between.... 1.5 - 3 kh/s
(03:06:43 PM) gingeropolous: higher ends
(03:07:08 PM) tevador: Ryzen is consumer and gets >4 KH/s
(03:07:13 PM) kinghat: i dont even know, but with my current sticks i can only give it 8gb/cpu. not sure i have that many sticks though.
(03:07:34 PM) gingeropolous: so ... the most beastly thing that could be considered "unfair" is a high end server which has an asic compariable cost and only gets 8-10x performance
(03:07:35 PM) moneromooo: Is there an estimate of how much an ASIC might reach per watt or fiat ?
(03:08:09 PM) gingeropolous: but its a general purpose hardware that can travel the globe freely and is produced by benign parties
(03:08:14 PM) tevador: gingeropolous but per watt should be pretty similar to your house PC
(03:08:37 PM) gingeropolous: well my server did not like my command: sudo sysctl -w vm.nr_hugepages=12000
(03:08:56 PM) kicoo [~kico@unaffiliated/kico] entered the room.
(03:09:34 PM) tevador: moneromooo no estimates have been made, we are simply trying to max out a CPU
(03:10:05 PM) tevador: gingeropolous maybe because 12k huge pages requires more 24 GB of RAM
(03:10:22 PM) tevador: 1 page = 2 MB
(03:10:27 PM) moneromooo: What are the hash rate ratios between high end CPU and "normal" CPU for randomX and CNv2 ?
(03:10:29 PM) gingeropolous: i gotta have some more sticks downstairs....
(03:11:05 PM) gingeropolous: well, lets see what happens if i try to kill this systctl command. my gut tells me im looking at a fresh install
(03:11:07 PM) kico left the room (quit: Ping timeout: 246 seconds).
(03:11:08 PM) tevador: moneromooo depends on what you consider a normal CPU
(03:11:23 PM) tevador: Ryzen 2600 seems pretty mainstream to me
(03:11:34 PM) moneromooo: Pick one.
(03:11:49 PM) gingeropolous: yah gethh , that'd be interesting to see what the CNv2 hashrates on the epyc are
(03:11:52 PM) moneromooo: I just want to know whether the ratios are mostly the same depending on which "end" you use.
(03:11:58 PM) gethh: gingeropolous 3.8k
(03:12:07 PM) gingeropolous: and CNv4 ?
(03:12:20 PM) gethh: the current monero
(03:12:31 PM) gingeropolous: ok
(03:12:42 PM) gethh: gingeropolous you can get 7551P for much cheaper
(03:12:53 PM) gethh: or even 7401P 24 version 
(03:12:56 PM) tevador: moneromooo dual epyc had 28 KH/s, Ryzen 2600 around 4 KH/s
(03:13:00 PM) gingeropolous: yeah the prices i got on ebay were for 7551
(03:13:16 PM) gethh: whole machine ?
(03:13:26 PM) gingeropolous: yeah
(03:13:51 PM) gethh: 7551P , 256GB RAM , Intel 4510 4TB , Melanox 25Gbit dual cost 5.9k$
(03:14:09 PM) gingeropolous: thats a single, right:?
(03:14:13 PM) gethh: yes
(03:14:16 PM) gingeropolous: ok gotcha
(03:14:34 PM) moneromooo: Do you know what their CNv2 (or CNvx) are ?
(03:14:38 PM) moneromooo: hash rates*
(03:14:42 PM) gingeropolous: we need a table
(03:14:53 PM) tevador: gethh your dual epyc gets 3.8 KH/s in CNv2?
(03:15:05 PM) gethh: yes , 3650-3800 
(03:15:09 PM) gethh: more likely
(03:15:17 PM) tevador: the ryzen gets afaik around 550-600 H/s
(03:15:22 PM) moneromooo: ty
(03:15:23 PM) tevador: sech1 can confirm
(03:15:47 PM) gingeropolous: a table comparing consumer cpus, server cpus, asics, GPUs, and hr from cnv2 / cnv0 and randomx
(03:16:09 PM) moneromooo: So that's about 6-7 ratio for both, that's good :)
(03:18:09 PM) tevador: this comparison is a little favorable because it's literally the same chip
(03:18:09 PM) tevador: Ryzen and Epyc
(03:18:09 PM) gethh: I'm glad randomX utilise DDR , that will hurt botnets 
(03:18:09 PM) tevador: we don't have a lot of data for Intel
(03:18:09 PM) gethh: I can do some intel tests
(03:18:09 PM) tevador: my laptop does 1650 H/s in RandomX, 210 H/s in CNv2
(03:18:09 PM) tevador: Intel 8550U
(03:19:23 PM) tevador: gingeropolous you have a 7700K?
(03:20:45 PM) kinghat: a single 6276 needs 8gb of ram then?
(03:21:03 PM) gethh: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz 
(03:21:13 PM) gethh: i'll test that one tomorrow and post results
(03:22:24 PM) tevador: kinghat ideally you want to run 2 instances per CPU, so you need more than 8 GB
(03:22:24 PM) tevador: each of those 6276 has 2 dies with separate memory controllers
(03:23:03 PM) kinghat: so 8gb per die?
(03:23:16 PM) kinghat: 16gb/cpu?
(03:23:38 PM) tevador: well, 6 GB per die should be enough
(03:23:43 PM) tevador: 12 GB per CPU
(03:24:11 PM) kicoo left the room (quit: Quit: Leaving).
(03:25:15 PM) kinghat: gotcha. is it possible to extrapolate the hash using 8gb/cpu to 12gb/cpu if i cant do 12gb/cpu atm?
(03:26:24 PM) tevador: with 8 GB per CPU, you'd have to use just 1 instance per CPU, so you cannot extrapolate
(03:26:46 PM) tevador: it depends on what the die-die latency is for the CPU
(03:27:06 PM) kinghat: k. maybe gingeropolous has moar sticks 😛
(04:02:23 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(04:04:48 PM) kico [~kico@unaffiliated/kico] entered the room.
(04:05:22 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(04:45:10 PM) gingeropolous:  tevador yeah its a 7700k
(04:46:06 PM) rottensox left the room (quit: Ping timeout: 264 seconds).
(05:08:16 PM) tevador: gingeropolous can you test it again with large pages?
(05:08:34 PM) tevador: your previous test is just 1500 H/s, which seems low
(05:09:00 PM) tevador: someone posted a 4790K with >2500 H/s
(05:09:12 PM) tevador: that's 3 generations older
(05:32:28 PM) lithiumpt left the room (quit: Ping timeout: 250 seconds).
(06:12:49 PM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(06:34:29 PM) sech1 left the room (quit: Quit: Leaving).
(07:05:14 PM) hyc: rerunning with 7 threads per NUMA node now
(07:05:26 PM) hyc: dropped nonces to 500000 to save a bit of time
(07:22:25 PM) tevador: hyc is it still running?
(08:09:12 PM) hyc: finished, looks a touch slower
(08:10:20 PM) hyc: 834.423 / 833.579 / 829.77 / 829.763 / 827.164 / 826.748 / 825.877 / 784.618
(10:51:42 PM) gingeropolous: tevador, sure. lemme try these large pages
(11:09:33 PM) gingeropolous: ok, im getting up to Performance: 2122.8 hashes per second
(11:10:28 PM) gingeropolous: i wonder if its my compiler? was the 4790k with the compiled bin?
(11:27:47 PM) gingeropolous: damn i cannot get it over 2k
(11:46:23 PM) syrius_ [~jsmith@bas10-montrealak-67-68-233-207.dsl.bell.ca] entered the room.
(11:47:29 PM) syrius_ left the room (quit: Client Quit).
(11:48:02 PM) gingeropolous: i wonder if going to ubuntu 18 would help
(11:48:46 PM) patap0n left the room (quit: Ping timeout: 246 seconds).
(11:50:53 PM) patap0n [~jsmith@unaffiliated/patap0n] entered the room.
(12:07:21 AM) gingeropolous: looks like opticflow got the wrong hash
(12:07:41 AM) gingeropolous: wait gah
(12:11:09 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(12:23:54 AM) rottensox left the room (quit: Ping timeout: 264 seconds).
(12:25:03 AM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(12:33:29 AM) gingeropolous: ah u got me into my favorite sat night activity. pizza, beer, and overclocking
(12:40:59 AM) endogenic_ is now known as endogenic
(01:18:30 AM) gingeropolous: yeah i can't get over 2.5 kh/s . CPU seems to not get over 4.2 Ghz , even though the bios says its set at 4.9
(01:20:25 AM) gingeropolous: https://askubuntu.com/questions/971142/cannot-disable-cpu-throttling-on-ubuntu-16-04-lts[1]
(01:20:30 AM) gingeropolous: first answer on this is great
(01:21:41 AM) jwinterm: just set it to 50000000
(01:28:59 AM) gingeropolous: naaaoooo thnat wont work
(02:05:50 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(02:56:22 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:08:27 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(03:09:38 AM) rottensox left the room (quit: Client Quit).
(04:18:11 AM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(04:22:14 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(05:33:46 AM) tevador: gingeropolous the 4790K result was with the Windows binary
(05:37:00 AM) sech1: tevador are we sure 4 GB is enough to deter botnet mining? Maybe increase scratchpad to 6 GB?
(05:37:13 AM) sech1: and select random 4 GB window within it for each nonce
(05:38:05 AM) sech1: we can actually have scratchpad of any size > 4 GB, even growing scratchpad like DAG in ETHash
(05:39:52 AM) sech1: Most notebooks sold today have 8 GB RAM or less, so 6 GB (and growing) scratchpad would be very noticeable for users
(05:44:20 AM) tevador: I think 4 GB is noticeable enough
(05:44:59 AM) sech1: What about growing scratchpad? Something like +256 MB/year
(05:45:19 AM) sech1: ASICs with fixed RAM size would be obsolete
(05:45:35 AM) tevador: scratchpad is 2 MB, did you mean 256 KB per year?
(05:45:50 AM) sech1: No, I mean the "big" one
(05:45:54 AM) sech1: 4 GB one
(05:46:10 AM) tevador: and then choose a 4 GB window for the random access?
(05:46:13 AM) sech1: yes
(05:46:27 AM) sech1: to avoid big refactoring of existing code
(05:46:35 AM) tevador: that would be possible I think
(05:47:01 AM) tevador: any 64-byte aligned window could be used
(05:47:13 AM) sech1: I think it's one of the reasons why ETHash held so well against ASICs
(05:47:56 AM) tevador: the window would have to be per program not per nonce
(05:48:09 AM) sech1: even better
(05:48:14 AM) tevador: because otherwise ASICs could just skip the nonces that go outside of their RAM
(05:48:20 AM) sech1: so it would change 8 times per nonce?
(05:48:24 AM) tevador: yes
(05:48:43 AM) sech1: it's easy to do for CPU, just change the base pointer register you use in generated instructions
(05:49:04 AM) sech1: I mean were it points to
(05:49:07 AM) sech1: *where
(05:49:12 AM) tevador: yes, the base pointer has a dedicated register at the moment
(05:49:25 AM) tevador: so it's very easy
(05:50:01 AM) sech1: and increase it by 1 MB every 1024 blocks when the big scratchpad is updated
(05:50:17 AM) sech1: it would grow by 256 MB/year then
(05:50:57 AM) sech1: Ah, it's called dataset, not scratchpad
(05:51:03 AM) tevador: how fast does ETH DAG grow?
(05:51:47 AM) sech1: DATASET_BYTES_GROWTH = 2**23      # dataset growth per epoch
(05:52:02 AM) sech1: 2^23 bytes every 30000 blocks
(05:52:26 AM) sech1: 561 MB/year
(05:52:49 AM) tevador: so we could do 2 MB per epoch in RandomX
(05:52:54 AM) sech1: yes
(05:55:31 AM) tevador: an ASIC with a 1-year lifespan would have to ship with at least 4.5 GB
(05:56:40 AM) sech1: Or they would have to use normal DDR4 slots and more complex memory controllers for them
(05:56:55 AM) sech1: Which would make them slower than embedded DRAM option
(05:58:12 AM) sech1: Actually, even 4.01 GB makes it much worse for ASIC. They can't use single 4 GB chip anymore
(05:59:15 AM) sech1: And they have to use many parallel DRAM chips to achieve good hashrate, so this adds up to higher production costs
(06:00:12 AM) tevador: a single chip is good for about 1500 H/s, so they would use more chips anyways
(06:00:26 AM) tevador: but >4 GB makes it more awkward
(06:01:12 AM) sech1: yes, that and continuously growing dataset makes it worse for ASIC
(06:02:46 AM) tevador: growing by 2 MB per epoch is also good because a hugepage is 2 MB
(06:09:52 AM) tevador: what is wrong with github? sometimes I get an email notification about a comment, but the comment doesn't exist
(06:10:23 AM) hyc: person probably deleted their comment
(06:10:44 AM) sech1: hyc http://highlandsun.com/hyc/monero-pow.txt[1] is disconnected again
(06:11:04 AM) hyc: bah. another netsplit I guess. 1 sec
(06:12:41 AM) hyc: ok, relinked
(06:12:52 AM) tevador: for example here sech1 is replying to a post that comes in the future: https://github.com/monero-project/monero/pull/5126#issuecomment-465976374[1]
(06:12:59 AM) tevador: but the email notification came earlier
(06:13:22 AM) hyc: LeoChains commented twice
(06:13:30 AM) hyc: edited or deleted his original one
(06:13:30 AM) sech1: No, he deleted his old comment and then posted the same again
(06:13:38 AM) sech1: I replied before his second comment
(06:13:47 AM) tevador: that explains it
(06:14:05 AM) sech1: I got 2 e-mail notifications back then
(06:14:08 AM) hyc: yeah I remember being confused at that too but I saw both of his comments
(06:15:49 AM) tevador: I got just 1 notification, so it looked like the comment came after the email
(06:26:38 AM) tevador: I wonder if there is any benefit to using 1 GB pages for RandomX
(06:26:46 AM) tevador: newer CPUs support also this page size
(06:27:23 AM) tevador: the number of required paged would be reduced 2048 -> 4
(06:27:51 AM) sech1: Only Linux supports it
(06:28:25 AM) sech1: there is only 1 way to find out
(06:28:29 AM) sech1: someone needs to test it
(06:49:50 AM) hyc: I don't recall how you configure other hugepage sizes
(06:50:10 AM) hyc: but leaving more TLB slots free for other uses is probably a win anyway
(07:19:57 AM) gethh: posted results for Xeon(R) Gold 6138 
(07:20:02 AM) gethh: ~16kh
(07:20:19 AM) gethh: on single 4GB Performance: 12634 hashes per second
(07:27:34 AM) tevador: gethh the xeon has 27.5 MB of L3 cache, so you should test with 13-14 threads
(07:28:22 AM) gethh: Xeon has non inclusive L3
(07:28:28 AM) gethh: and 1MB of L2
(07:28:34 AM) gethh: but I'll test for you :)
(07:28:47 AM) tevador: 1 MB of L2 per core?
(07:28:53 AM) tevador: that changes things
(07:30:01 AM) gethh: 13 threads Performance: 6207.15 hashes per second
(07:30:07 AM) tevador: then you can test 23 threads
(07:30:09 AM) gethh: 14 threads Performance: 6436.93 hashes per second
(07:30:13 AM) gethh: I did 
(07:30:22 AM) tevador: it has 20+27.5 = 47.5 MB
(07:30:27 AM) gethh: let me do it again , I did not notice big change
(07:31:00 AM) gethh: Performance: 8267.5 hashes per second
(07:31:14 AM) gethh: little bit more than 20
(07:31:44 AM) tevador: every little bit counts
(09:14:41 AM) sech1 left the room (quit: Read error: Connection reset by peer).
(09:14:50 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(09:15:49 AM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(09:16:36 AM) sech111 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(09:19:05 AM) sech1 left the room (quit: Ping timeout: 255 seconds).
(09:20:26 AM) sech11 left the room (quit: Ping timeout: 255 seconds).
(09:21:20 AM) sech111 left the room (quit: Ping timeout: 255 seconds).
(09:40:45 AM) cjd left the room (quit: Ping timeout: 252 seconds).
(09:40:54 AM) cjd [~user@2a01:e0a:149:fcb0:70c2:daff:feda:1be2] entered the room.
(09:53:59 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(10:07:01 AM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(10:10:23 AM) sech1 left the room (quit: Ping timeout: 255 seconds).
(10:14:03 AM) sech11 left the room (quit: Quit: Leaving).
(11:03:43 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:15:29 PM) suraeNoether_ is now known as suraeNoether
(02:17:34 PM) gethh left the room (quit: Quit: Connection closed for inactivity).
(02:41:20 PM) gethh [uid264798@gateway/web/irccloud.com/x-sutjgabtjchcdqge] entered the room.
(05:07:10 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(06:54:37 PM) tevador left the room (quit: Ping timeout: 245 seconds).
(07:07:11 PM) patap0n left the room (quit: Quit: patap0n).
(07:25:55 PM) sech1 left the room (quit: Quit: Leaving).
(10:12:15 PM) patap0n [~jsmith@unaffiliated/patap0n] entered the room.
(11:20:20 PM) gingeropolous: so a thought about the whole commoditization thing combined with the ASIC rationale of "the hardware is single purpose so they won't attack the network"
(11:21:26 PM) gingeropolous: once this stuff is commoditized and miners are sticks in swag bags, that reasoning may start to get unraveled
(11:22:58 PM) gingeropolous: there could be boatloads of idle hardware. literally boatlods.
(11:23:46 PM) gingeropolous: and literally as in actual literally. can't believe websters did that. 
(12:18:03 AM) rottensox left the room (quit: Quit: Leaving).
(01:12:04 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(01:40:02 AM) antanst8 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(01:40:32 AM) antanst [~antanst@62.169.219.213] entered the room.
(01:50:09 AM) antanst left the room (quit: Quit: The Lounge - https://thelounge.chat).
(01:50:29 AM) antanst [~antanst@62.169.219.213] entered the room.
(01:59:27 AM) antanst left the room (quit: Quit: The Lounge - https://thelounge.chat).
(02:02:21 AM) antanst [~antanst@62.169.219.213] entered the room.
(02:02:25 AM) antanst1 [~antanst@62.169.219.213] entered the room.
(02:06:31 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:19:48 AM) antanst1 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(02:22:25 AM) antanst1 [~antanst@62.169.219.213] entered the room.
(02:30:57 AM) el00ruobuob left the room (quit: Ping timeout: 244 seconds).
(02:34:14 AM) sech1 left the room (quit: Quit: Leaving).
(02:44:58 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(02:59:13 AM) tevador left the room (quit: Ping timeout: 245 seconds).
(03:08:41 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(04:17:29 AM) midipoet [uid316937@gateway/web/irccloud.com/x-cwlnqhzxypwllbfu] entered the room.
(05:33:34 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(06:07:04 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(06:10:59 AM) antanst left the room (quit: Ping timeout: 255 seconds).
(06:12:19 AM) antanst1 left the room (quit: Ping timeout: 250 seconds).
(06:16:12 AM) antanst [~antanst@62.169.219.213] entered the room.
(06:16:49 AM) antanst1 [~antanst@62.169.219.213] entered the room.
(07:58:22 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(11:11:48 AM) sech1 left the room (quit: Quit: Leaving).
(11:22:06 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:46:41 AM) el00ruobuob left the room (quit: Ping timeout: 255 seconds).
(12:16:01 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(12:19:23 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(12:21:47 PM) el00ruobuob left the room (quit: Ping timeout: 240 seconds).
(01:29:07 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:33:07 PM) rottensox left the room (quit: Ping timeout: 246 seconds).
(03:25:18 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(03:37:53 PM) kico left the room (quit: Remote host closed the connection).
(03:39:16 PM) kico [~kico@unaffiliated/kico] entered the room.
(06:05:31 PM) sech1 left the room (quit: Quit: Leaving).
(07:27:11 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:22:02 PM) gingeropolous: i think the scratchpad growing thing is interesting, but i'm concerned with having it respond to time .. to be dependent on block height
(11:22:08 PM) tevador left the room (quit: Ping timeout: 245 seconds).
(11:22:25 PM) gingeropolous: i can't put my finger on why exactly
(11:23:04 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(11:23:21 PM) gingeropolous: well, one reason is that it may not deter asics that much. we've seen that even with a 3 month timespan for profit, thats good enough
(11:23:49 PM) gingeropolous: so if they could get 1 year out of a run, that could be all they need
(11:25:57 PM) gingeropolous: gah dataset. i mean dataset. the 4 gb one
(11:26:25 PM) gingeropolous: im still interested in seeing how an adaptive dataset would work
(11:26:38 PM) gingeropolous: it would be dependent on hashrate velocity
(11:27:39 PM) gingeropolous: but then again, if you increase the dataset in response to a significant change in the rate of change of the hashrate, you could end up kicking off low end miners
(11:27:52 PM) gingeropolous: along with whatever fixed hardware was developed. 
(11:28:07 PM) gingeropolous: But also, couldn't they just make an ASIC with n DIMM slots?
(11:51:45 PM) investanto left the room (quit: Quit: Changing servers).
(11:51:56 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:08:11 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:43:15 AM) tevador: gingeropolous RandomX ASIC would take a lot longer than 3 months to break even
(01:43:43 AM) tevador: it's a completely new algorithm, so R&D costs would be higher
(01:44:01 AM) tevador: and the ASIC will not be 15x more efficient like now, more like 2.5x
(01:44:42 AM) tevador: so it could be around 18 months to break even
(02:09:58 AM) investanto left the room (quit: Quit: Changing servers).
(02:10:09 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(02:20:08 AM) spaced0ut left the room (quit: Ping timeout: 255 seconds).
(02:57:48 AM) sech1 left the room (quit: Quit: Leaving).
(03:07:23 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:29:56 AM) hyc: fpga programming https://docs.racket-lang.org/fairylog/index.html
(03:52:01 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bnnawdhnjycbulkf] entered the room.
(04:13:58 AM) el00ruobuob_[m] left the room (quit: Read error: Connection reset by peer).
(05:37:34 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(05:40:33 AM) gethh [uid264798@gateway/web/irccloud.com/x-qxxmpcyciqurkyqp] entered the room.
(06:17:28 AM) oneiric_ left the room (quit: Remote host closed the connection).
(06:17:59 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(07:41:28 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(07:52:36 AM) gingeropolous: well tevador that depends on additional factors - the network hashrate at time of asic development, and real world value of monero. if monero is worth $50,000 usd and the network hashrate is 400 mh/s..... 
(07:57:29 AM) sech1: If monero is worth $50,000 I'll retire and won't care anymore :D
(07:57:53 AM) gingeropolous: nononoo, you'll retire and spend your free time on monero
(07:58:13 AM) sech1: yeah, it's not that I like sitting and doing nothing
(07:58:40 AM) gingeropolous: :)
(08:11:24 AM) midipoet [uid316937@gateway/web/irccloud.com/x-plhhsibvkzdnsmjs] entered the room.
(08:21:29 AM) tevador left the room (quit: Ping timeout: 255 seconds).
(08:22:11 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(08:37:08 AM) tevador left the room (quit: Ping timeout: 245 seconds).
(08:38:03 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(08:48:21 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(09:30:31 AM) sech1: tevador what about CFROUND instruction? https://github.com/tevador/RandomX/blob/master/src/program.inc[1] doesn't have it
(09:30:47 AM) sech1: Have you measured performance when you force this instruction in every program? It might be very slow
(09:43:58 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(11:04:53 AM) sech1 left the room (quit: Quit: Leaving).
(11:24:31 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:28:17 PM) tevador: gingeropolous if monero is $50k per coin, the network hashrate will be much higher than 400 MH/s
(12:28:24 PM) tevador: you have to assume hashrate will reach near-equilibrium in the long term
(12:29:16 PM) tevador: sech1: CFROUND has frequency 1/256, so there is ~37% chance there will be no CFROUND in the program
(12:30:07 PM) tevador: but this should be okay since we are chaining 8 programs and the chance 8 programs are without CFROUND is ~1E-4
(12:30:28 PM) sech1: I checked Agner's tables and it can have up to 14 cycles latency
(12:30:46 PM) tevador: yes it's slow on some architectures
(12:31:17 PM) tevador: especially on AMD
(12:31:48 PM) tevador: ASIC can do it in 1 cycle...
(12:32:08 PM) tevador: so the current setup is a good compromise IMO
(12:46:00 PM) gingeropolous: i guess i just don't know how we can put any confidence in these assumptions is all. 
(12:46:31 PM) tevador: sech1 this is CFROUND in x86: https://pastebin.com/05z9dkNi
(12:46:40 PM) tevador: could be up to 23 cycles on Ryzen
(12:47:36 PM) tevador: gingeropolous why not? it's pure economics
(12:48:34 PM) gingeropolous: well that assumption has baked into it that there is enough commodity hardware to permit difficulty to reach that equilibrium
(12:49:11 PM) tevador: true, that's the only limitation I guess
(12:49:12 PM) gingeropolous: i know its a rabbit hole of assumptions. i'll bail out now. disregard my ramblings ;)
(12:50:41 PM) gingeropolous: i guess the scenario would be the following: monero price/value continuously increases, but difficulty starts plateauing
(12:51:07 PM) gingeropolous: and then *boom* difficulty starts climbing like it did the past 3 months
(12:51:23 PM) tevador: if all the CPUs in the world are mining XMR with profit, then I will admit we have a problem
(12:52:11 PM) tevador: but what is the chance of this scenario happening in the next 2 years?
(12:53:01 PM) gingeropolous: i try to work on decade timescales when possible. I regard every fork as potentially the last fork we can ever make. 
(12:55:56 PM) tevador: you can always fork
(12:56:59 PM) tevador: if you can't, you have other things to worry about than crypto
(01:10:28 PM) gingeropolous: but those might be the times when we need crypto the most. dun dun dunnnnnnn dramatichampster.gif
(02:40:34 PM) needmoney90: Do you guys mind if I get a rep from Linzhi ASICs in here?
(02:40:38 PM) needmoney90: Or is this more of a private channel
(02:43:20 PM) gingeropolous: afaik this is public channel
(02:43:21 PM) tevador: it's not private, the log is publicly available, so...
(02:43:35 PM) gingeropolous: yes, moar asic folks pls
(02:44:40 PM) midipoet: Monero makes bed with ASIC manufacturers! 
(02:44:50 PM) gingeropolous: STOP THE PRESSES!
(02:45:11 PM) midipoet: They stopped yesterday for the bugs
(02:46:00 PM) tevador: I'm interested in their opinion about RandomX
(02:46:10 PM) tevador: although they have their own agenda
(02:46:19 PM) midipoet: Would they be honest? 
(02:46:25 PM) needmoney90: I believe so.
(02:46:29 PM) midipoet: Game theory might say no
(02:46:41 PM) needmoney90: They are explicitly looking to sell the shovels
(02:47:00 PM) midipoet: Monero is dead and digging graves!
(02:47:07 PM) needmoney90: though if they scale up, who knows if they'll turn to the dark side
(02:47:08 PM) tevador: anyways RandomX is not forever
(02:47:58 PM) tevador: also I have one ASIC friendly algo: https://github.com/tevador/nppow[1]
(02:48:22 PM) needmoney90: From my experience in their telegram channel, they're very open about how asics work, and willing to go through reasoning and process, or where you may have missed something.
(02:48:23 PM) midipoet: I haven't a notion. I would like open hardware and an Monero owned ASIC factory for economies of scale. 
(02:49:03 PM) needmoney90: I get the feeling that they want to be transparent, and enjoy the academic aspect of it. Though they might butt heads with hyc :)
(02:49:22 PM) needmoney90: They also think very highly of their own expertise
(02:53:57 PM) oneiric_: humility can be a hard-to-acquire commodity
(02:54:09 PM) ***oneiric_ speaking from personal experience
(02:56:59 PM) tevador: btw already 2 mining software developers will not support cn/r
(02:57:56 PM) sech1: They got flooded by constant stream of coin forks, couldn't keep up
(02:58:43 PM) sech1: On the bright side, we have brand new miner (VulkanXMR) that supports it
(02:59:00 PM) tevador: 1 year ago there was just cn and cn-lite
(02:59:03 PM) tevador: those were the times
(02:59:04 PM) Inge-: which two gave up?
(02:59:09 PM) sech1: CastXMR and JCE
(02:59:10 PM) Inge-: in addition to coinhive I presume
(02:59:29 PM) Inge-: cryptonote coins have seen a proliferation of pows.
(03:00:20 PM) sech1: yeah, xmrig has 17 different algorithms now
(03:01:07 PM) tevador: those forks are mostly to escape nicehash, not because of ASICs
(03:01:52 PM) sech1: No, 21 algorithms actually, omg
(03:03:02 PM) tevador: someone in supportXMR chat said he was 1/3 of the hashrate of some algo
(03:03:07 PM) tevador: that speaks for itself
(03:03:23 PM) tevador: 1/3 of the network hashrate
(03:07:34 PM) gethh left the room (quit: Quit: Connection closed for inactivity).
(03:10:28 PM) gethh [uid264798@gateway/web/irccloud.com/x-zfkdddtxncptkgek] entered the room.
(05:14:24 PM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(05:15:29 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(05:39:48 PM) tevador: "iamsmooth" on github is in this channel?
(05:43:00 PM) jwinterm: tevador: no
(05:43:06 PM) jwinterm: at least not with normal irc nick
(05:43:36 PM) jwinterm: [Whois] smooth is smooth!~ubuntu@ec2-54-201-223-245.us-west-2.compute.amazonaws.com (Ubuntu)
(05:43:36 PM) jwinterm: [Whois] smooth is a user on channels: #monero-research-lab
(05:43:36 PM) jwinterm: [Whois] smooth is an operator on channels: #monero #aeon #monero-dev
(05:47:30 PM) tevador: ok, he mentioned "having doubts about RandomX [ASIC resistance]", I'd be interested to hear details
(05:51:06 PM) jwinterm: maybe just ping him on the aeon github thread re: pow and ask for comment on randomx repo
(06:37:02 PM) sech1 left the room (quit: Quit: Leaving).
(07:02:41 PM) antanst left the room (quit: Quit: ZNC 1.7.1 - https://znc.in).
(07:03:10 PM) antanst19 [~antanst@62.169.219.213] entered the room.
(07:03:12 PM) antanst [~antanst@62.169.219.213] entered the room.
(07:04:36 PM) antanst1 left the room (quit: Read error: Connection reset by peer).
(08:21:06 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(08:29:46 PM) hyc: smooth is an eternal skeptic. I think he's an important voice of sanity when others are over-enthsiastic
(08:30:16 PM) hyc: linzhi - sure why not. and yes, of course this is a public space
(08:31:01 PM) hyc: and remember, nobody says you can't build a randomX ASIC. Only that the reward needs to be extremely high to make it worth your while
(08:47:27 PM) rottensox left the room (quit: Ping timeout: 252 seconds).
(09:07:04 PM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(09:08:39 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(09:11:08 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:46:12 PM) spaced0ut left the room (quit: Ping timeout: 252 seconds).
(12:05:07 AM) kinghat left the room (quit: Quit: The Lounge - https://thelounge.chat).
(12:05:50 AM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(01:07:46 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:46:43 AM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(01:46:47 AM) [-mugatu-] left the room (quit: Ping timeout: 240 seconds).
(01:51:28 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:22:23 AM) tevador left the room (quit: Ping timeout: 255 seconds).
(02:23:03 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(02:30:53 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(02:54:06 AM) sech1 left the room (quit: Quit: Leaving).
(03:04:59 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:05:47 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(03:12:38 AM) antanst left the room (quit: Remote host closed the connection).
(03:12:49 AM) antanst19 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(03:13:17 AM) antanst19 [~antanst@62.169.219.213] entered the room.
(03:13:54 AM) antanst19 left the room (quit: Client Quit).
(03:14:13 AM) antanst [~antanst@62.169.219.213] entered the room.
(03:26:12 AM) rottensox left the room (quit: Ping timeout: 252 seconds).
(03:52:06 AM) midipoet [uid316937@gateway/web/irccloud.com/x-tlqgupkcihsyapwb] entered the room.
(04:14:08 AM) lithiumpt left the room (quit: Ping timeout: 250 seconds).
(05:03:12 AM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(06:40:23 AM) kico left the room (quit: Remote host closed the connection).
(06:41:23 AM) kico [~kico@unaffiliated/kico] entered the room.
(07:54:51 AM) parasew[m] left the room ("Kicked by @appservice-irc:matrix.org  : OFTC spam preventative kick").
(08:11:43 AM) IRS left the room (quit: Ping timeout: 245 seconds).
(08:15:14 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(09:00:05 AM) sech1: Interesting discussion in FPGA discord today: https://pastebin.com/YyVqdHNM
(09:00:43 AM) sech1: GPUHoarder thinks that ASICs for cn/r will require huge R&D cost and external HBM or GDDR memory
(09:03:42 AM) sech1: So ASICs with HBM will do 4 kh/s @ 50 W on CryptonightR
(09:05:22 AM) sech1: The thing is, HBM ASICs don't exist yet, even for ETHash. Very huge R&D cost.
(09:17:55 AM) sech1: and he also thinks that ASICs with SRAM don't make sense anymore because they'll require "flagship CPU level R&D"
(09:18:40 AM) sech1: either this or they'll be too slow without enough R&D
(09:26:00 AM) sech1: Second part of discussion: https://pastebin.com/QXzpb5gB
(09:28:27 AM) tevador left the room (quit: Ping timeout: 240 seconds).
(09:29:43 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(09:48:27 AM) tevador left the room (quit: Ping timeout: 252 seconds).
(09:49:03 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(09:52:54 AM) midipoet: ^^ does that imply we win?
(10:01:57 AM) sech1: Not yet
(10:08:16 AM) sech1: But we might hold well until October and then switch to RandomX hopefully
(11:05:27 AM) sech1 left the room (quit: Quit: Leaving).
(11:15:32 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:26:51 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(11:51:07 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 240 seconds).
(12:05:03 PM) tevador left the room (quit: Ping timeout: 245 seconds).
(12:05:55 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(01:21:52 PM) lithiumpt left the room (quit: Ping timeout: 246 seconds).
(02:06:24 PM) tevador left the room (quit: Ping timeout: 252 seconds).
(02:06:51 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(02:13:46 PM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(03:16:58 PM) hyc: nice stuff
(03:18:31 PM) cjd left the room (quit: Ping timeout: 252 seconds).
(03:18:40 PM) cjd [~user@2a01:e0a:149:fcb0:70c2:daff:feda:1be2] entered the room.
(03:21:19 PM) hyc: it is basically an admission that the approach has worked - forcing ASIC designers to compete with CPUs on CPU's turf
(03:32:37 PM) xmrdc [sid218083@gateway/web/irccloud.com/x-wyxdjjpzgvzzwqtl] entered the room.
(03:38:07 PM) nioc [sid298274@gateway/web/irccloud.com/x-slvsgowawbpzklvk] entered the room.
(04:52:09 PM) tevador: sech1 can he do similar review for RandomX?
(04:55:41 PM) tevador: lukminer dev complaining about CN/R naming https://lukminer.org/2019/03/06/upcoming-monero-xmr-v4r/[1]
(05:05:13 PM) sech1: Maybe he will do review if we ask politely
(05:05:46 PM) tevador: first I have to finish the full documentation
(05:05:55 PM) tevador: it's taking longer than I expected...
(05:47:11 PM) sech1: Speaking of RandomX and botnets, I think I know a way to stop them entirely
(05:48:32 PM) sech1: What if we add "HDD" dataset, 64 or 128 GB in size that is updated every 65536 blocks? And random parts of this big HDD dataset are used when updateing RAM dataset
(05:48:56 PM) sech1: Miners would just add dedicated SSD for this
(05:49:38 PM) hyc: is this HDD dataset historical blockchain data? or just randomly generated
(05:49:46 PM) sech1: Randomly generated
(05:49:59 PM) sech1: We don't want to stress Internet connections
(05:50:20 PM) sech1: Users will 100% notice big fat 64 GB file on their PCs
(05:50:26 PM) hyc: heh
(05:52:17 PM) sech1: Need to think of it a bit more. We need to make sure it has to be stored and not generated on the fly when updating RAM dataset
(05:53:26 PM) hyc: would take quite a long time to iteratively regenerate 64GB of random data on the fly
(05:55:08 PM) sech1: How fast a modern SSD can read random blocks of data?
(05:55:08 PM) moneromooo: Botnets seem good to me. (1) they seem to typically be a substantial part of the hash rate as a whole, (2) a single one is nowhere near 50%, and (3) if they're mining monero they're not doing DDoS or child porn or whatever other thing they do.
(05:55:49 PM) moneromooo: I see it as turning a bad thing into a good thing.
(05:56:00 PM) sech1: If it's 5-10k IOPS, we can basically use the SSD data for every nonce on regular PC
(05:56:30 PM) hyc: SSD IOPS are now in the hundreds of K
(05:56:43 PM) hyc: 4KB random reads
(05:56:57 PM) moneromooo: And the more we require high end stuff (ie, only SSD), the more we stray away from the "everyone can mine" system, which admittedly some people don't really care about.
(05:56:58 PM) sech1: So we can just add a random 4 KB block to initialize the scratchpad for each nonce
(05:57:27 PM) hyc: at this point I find it hard to classify SSD as high end
(05:57:57 PM) moneromooo: Maybe. General statement, rather than particularly about SSDs.
(05:58:02 PM) sech1: yeah, cheap SSDs are even cheaper than HDDs now
(05:58:49 PM) sech1: 120 GB SSD is 35 euro
(06:00:50 PM) sech1: moneromooo botnets kill profitability. If they're 10% now of all non-ASIC miners, they will be > 50% of CPU-only network
(06:01:46 PM) moneromooo: Do we care ?
(06:02:06 PM) sech1: If we want more adoption from small single PC miners then yes
(06:02:16 PM) sech1: This is how I got into this btw
(06:02:58 PM) moneromooo: We want getting 50% of the hash rate to be as hard as we can.
(06:03:13 PM) moneromooo: Getting everyone to mine is one way to get at this.
(06:03:52 PM) moneromooo: Getting miners to profit is one eway to attract them to mine, but that's only a means to an end.
(06:04:20 PM) moneromooo: If it gets unprofitable, but in a way that getting 50% is made harder, then it's a win.
(06:05:08 PM) sech1: On the other hand, botnets have limited capacity too
(06:05:23 PM) sech1: they won't squeeze out all other miners
(06:05:37 PM) sech1: so maybe they'll never have 50% of the network
(06:06:12 PM) moneromooo: If they get 50% as a whole, it's not that bad, unless they're all under the same "management".
(06:06:19 PM) sech1: and they're unstable, antivirus updates can kill them in a day for example
(06:06:30 PM) moneromooo: Granted, it might be they're easier to hire than alot of small miners.
(06:06:40 PM) sech1: I think people overestimate the "botnet threat"
(06:07:47 PM) sech1: And if CPU mining gets a common thing, a lot of people will start their own mining and will be on high alert for all "unwanted guests" on their PC
(06:16:46 PM) tevador: sech1 using hdd is probably not possible unless you can come up with a light verification option that doesn't require it
(06:17:20 PM) tevador: and then it becomes pointless I guess
(06:18:22 PM) tevador: botnets will get a substantial hit due to the RAM requirement and that is enough IMO
(06:20:18 PM) tevador: another option would be to read random blockchain data to force closer coupling between miners and full nodes
(06:21:00 PM) tevador: this would not increase storage requirement to run a full node
(06:25:35 PM) sech1 left the room (quit: Quit: Leaving).
(08:28:14 PM) tevador left the room (quit: Ping timeout: 255 seconds).
(08:28:52 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(08:41:18 PM) tevador left the room (quit: Ping timeout: 252 seconds).
(08:41:49 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(08:51:44 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:32:16 PM) investanto left the room (quit: Quit: Changing servers).
(09:32:27 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(10:24:23 PM) gingeropolous: botnets would just get the data from some coordinator
(10:25:20 PM) gingeropolous: i think the botnet threat is overstated as well. However, I do think having *something* programmed to change over time is a good idea, both for botnets and asics
(10:25:36 PM) gingeropolous: e.g., the dataset size
(11:26:31 PM) lithiumpt left the room (quit: *.net *.split).
(11:26:32 PM) patap0n left the room (quit: *.net *.split).
(11:53:39 PM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(11:53:39 PM) patap0n [~jsmith@unaffiliated/patap0n] entered the room.
(01:49:28 AM) Inge- left the room (quit: Quit: Quantum wave collapsed.).
(01:53:58 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:07:30 AM) Inge- [~inge@ti0051a400-2085.bb.online.no] entered the room.
(02:32:02 AM) sech1 left the room (quit: Quit: Leaving).
(02:42:19 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:14:10 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(03:15:25 AM) wowario left the room (quit: Read error: Connection reset by peer).
(03:15:49 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(03:42:19 AM) midipoet [uid316937@gateway/web/irccloud.com/x-urlodlimygpmietc] entered the room.
(04:24:11 AM) sech1: tevador regarding RandomX in Wownero: I plan to do reference CUDA miner (not high performance though, just reference)
(04:24:38 AM) sech1: CUDA conveniently has all needed intrinsics: https://docs.nvidia.com/cuda/cuda-math-api/group__CUDA__MATH__INTRINSIC__DOUBLE.html#group__CUDA__MATH__INTRINSIC__DOUBLE[1]
(04:54:53 AM) wowario: tevador: we are open to forking to RandomX
(07:09:11 AM) investanto left the room (quit: Quit: Changing servers).
(07:09:23 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:22:07 AM) sech1 left the room (quit: Remote host closed the connection).
(09:22:32 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(10:04:38 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(10:07:27 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 240 seconds).
(10:08:32 AM) wolfspraul [~wolfsprau@bobbin.q-ag.de] entered the room.
(10:08:51 AM) [-mugatu-] is now known as soiology
(11:05:15 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(11:05:36 AM) sech1 left the room (quit: Quit: Leaving).
(11:07:22 AM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(11:07:34 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(11:14:25 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:20:27 AM) gingeropolous: so does anyone know what happened to vertcoin?
(12:17:14 PM) gethh [uid264798@gateway/web/irccloud.com/x-eihegrbqplcmdyls] entered the room.
(12:46:01 PM) gethh: hmm fuck ssd data set , smart ppl wil share it anyway , i bet it is better to enlarge RAM requirements
(12:46:44 PM) gethh: RAM is fast you can easly set it that no sharing is thechnicaly possibile 
(12:47:11 PM) gethh: if you want to hurt botnets go with RAM , 
(12:57:32 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(01:00:48 PM) gingeropolous: huh, someone else must be running a testnet pool
(01:01:48 PM) gingeropolous: oh no, nevermind. someone hit the pool this morning with 70 kh/s
(01:02:00 PM) gingeropolous: diff must be adjusting for that still
(01:02:34 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(01:07:14 PM) midipoet: After pulling latest build I get a fail on 'make'. 
(01:07:27 PM) midipoet: lto-wrapper failed
(01:07:34 PM) midipoet: Any ideas?
(01:10:17 PM) midipoet: **never mind. 'make clean' before 'make' seems to solve it. 
(02:13:19 PM) rottensox left the room (quit: Read error: Connection reset by peer).
(02:17:24 PM) tevador: sech1: perfect!
(02:17:40 PM) tevador: btw OpenCL doesn't support directed rounding?
(02:19:31 PM) sech1: No, OpenCL is very limited
(02:19:42 PM) sech1: I'll have to write in GCN assembly for AMD cards
(02:19:50 PM) sech1: GCN asm has rounding modes
(03:06:02 PM) wolfspraul left the room (quit: Quit: leaving).
(03:53:51 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(03:55:35 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(03:58:13 PM) el00ruobuob left the room (quit: Remote host closed the connection).
(03:58:59 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(03:59:12 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(04:10:18 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(04:13:05 PM) el00ruobuob left the room (quit: Ping timeout: 255 seconds).
(04:15:04 PM) jwinterm left the room (quit: Quit: No Ping reply in 180 seconds.).
(04:15:09 PM) spaced0ut left the room (quit: Quit: Leaving).
(04:27:09 PM) tevador: I hope daemon integration will not bee too painful, we have to pass some blockchain data around
(05:04:27 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(05:13:01 PM) linzhi-sonia [~linzhi-so@bobbin.q-ag.de] entered the room.
(05:15:16 PM) linzhi-sonia left the room (quit: Client Quit).
(05:15:48 PM) linzhi-sonia [~linzhi-so@bobbin.q-ag.de] entered the room.
(05:16:28 PM) linzhi-sonia left the room (quit: Client Quit).
(05:16:47 PM) linzhi-sonia [~linzhi-so@bobbin.q-ag.de] entered the room.
(05:16:52 PM) linzhi-sonia left the room (quit: Client Quit).
(05:17:10 PM) linzhi-sonia [~linzhi-so@bobbin.q-ag.de] entered the room.
(05:40:02 PM) victorSN left the room (quit: Remote host closed the connection).
(06:22:06 PM) sech1 left the room (quit: Quit: Leaving).
(06:34:19 PM) hyc: How portable is GCN asm across AMD revisions?
(06:48:15 PM) philkode is now known as shillkode
(06:53:08 PM) el00ruobuob_[m] left the room (quit: Read error: Connection reset by peer).
(06:57:53 PM) shillkode is now known as philkode
(06:59:41 PM) rottensox left the room (quit: Quit: Leaving).
(07:33:20 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(09:06:23 PM) patap0n left the room (quit: Ping timeout: 268 seconds).
(10:11:58 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:14:26 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:29:50 PM) investanto left the room (quit: Quit: Changing servers).
(11:30:01 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(12:38:57 AM) investanto left the room (quit: Quit: Changing servers).
(12:39:09 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:08:05 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:13:29 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:57:22 AM) rottensox left the room (quit: Quit: Leaving).
(02:15:39 AM) victorSN [~victorSN@unaffiliated/victorsn] entered the room.
(03:02:06 AM) sech1 left the room (quit: Quit: Leaving).
(03:11:44 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:01:19 AM) midipoet [uid316937@gateway/web/irccloud.com/x-msznnvfwhebehemu] entered the room.
(04:08:27 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(04:12:37 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(04:24:48 AM) tevador: I'd like to see how Xeon Phi performs in RandomX
(04:26:06 AM) sech1: I'd also like to see how NVIDIA Titan V performs. It has 7.5 TFLOPs of FP64. Massively parallel interpreter could rock there.
(04:28:05 AM) tevador: GPUs will be severly limited by instruction decode
(04:28:33 AM) tevador: they have tons of compute, but it's not possible to use it
(04:29:09 AM) sech1: There is no instruction decode needed
(04:29:25 AM) sech1: I have some awesome ideas on how to implement it for CUDA and especially Titan V
(04:29:38 AM) tevador: ok, we will see
(04:30:35 AM) tevador: Titan V has HBM?
(04:30:41 AM) sech1: Yes
(04:32:18 AM) sech1: Basically, all different FP instructions in RandomX can be merged into single formula dst = dst * A * (flag1 ? src : 1) / (flag2 ? src : 2) + src * B + flag3 ? sqrt(dst) : 0
(04:32:35 AM) sech1: it can all be computed without branches, enabling massive parallel computation
(04:32:51 AM) tevador: what about the rounding mode?
(04:33:04 AM) sech1: yes, the only branch will be between rounding modes
(04:33:19 AM) sech1: so it kind of divides available computing power by 4
(04:33:54 AM) tevador: interesting
(04:34:11 AM) tevador: but still you will have to branch on integer instructions
(04:34:54 AM) sech1: it's possible to do the same for integer instructions
(04:35:11 AM) sech1: you can just calculate all of them and then use ?: operator to select what you need
(04:35:53 AM) sech1: the amount of calculations increases proportionally, but you can then optimize the formula for integer instructions
(04:36:16 AM) sech1: for example, ADD/SUB/NEG can be joined together into 1 simple formula
(04:36:29 AM) tevador: so you basically calculate everything and throw away most of it, not sure about the power consumption implications
(04:37:02 AM) sech1: I expect it will be around 80% throw away calculations, but branch-free code advantages outweight it
(04:37:15 AM) sech1: and power consumption through the roof of course
(04:37:19 AM) tevador: yes, it might still run pretty fast
(04:38:31 AM) tevador: high integer multiplication is probably many instructions on a GPU
(04:39:41 AM) sech1: yes, for regular GPUs
(04:40:03 AM) sech1: but Titan V has a lot of 64-bit data paths for it, so if CUDA compiler is smart it'll use them
(04:40:40 AM) sech1: and there is also 64 KB shared memory per SM, so it's enough to run 4 programs per SM and use it for first 16 KB of scratchpad
(04:40:47 AM) sech1: This will reduce global memory accesses a lot
(04:41:47 AM) tevador: so how many parallel threads can you run in total?
(04:42:37 AM) sech1: 4 per SM at least
(04:42:53 AM) tevador: it seems to have only 80 SMs
(04:42:54 AM) sech1: but if I don't use local memory, I can run as many as there are FP64 cores per SM
(04:42:57 AM) tevador: so 320 threads
(04:43:50 AM) sech1: One SM in Volta has 32 FP64 cores
(04:43:57 AM) sech1: 32*80 = 2560
(04:44:12 AM) tevador: and integer cores?
(04:44:17 AM) tevador: also 32?
(04:44:20 AM) sech1: so it all comes if using local memory for L1 speeds up things or not
(04:44:29 AM) sech1: 64 integer cores
(04:44:40 AM) sech1: but they are 32 bit
(04:45:10 AM) tevador: multiplication will be a bottleneck on the integer side
(04:45:45 AM) sech1: yes, but I still expect Titan V to be as fast as 16-core Threadripper
(04:46:09 AM) sech1: Just because of raw computing power
(04:46:14 AM) tevador: using L1 cache will reduce memory accesses to 1/4, but the other option can run 8x as many threads, so it might be faster
(04:46:47 AM) tevador: depends on latency
(04:47:07 AM) sech1: Yes, it'll probably be faster. HBM has more than enough bandwidth.
(04:47:49 AM) tevador: so that would be 5 GB for scratchpads and 4 GB for dataset
(04:47:54 AM) tevador: should still fit
(04:49:04 AM) sech1: btw Volta can have multiple program pointer per SM, right? So 4 rounding modes probably won't slow down things
(04:49:20 AM) tevador: I think so, Volta and Turing
(04:51:05 AM) tevador: just AMD cards will not be able to use their compute power
(04:52:27 AM) sech1: They can use GCN asm to generate programs on the fly and run 2 programs per SP
(04:52:46 AM) sech1: They have 4 FP64 cores per SP, 2 cores are needed per program. Perfect fit
(04:53:15 AM) tevador: Titan V costs $3500
(04:53:37 AM) tevador: you can probably build 2 threadripper boxes for the same price
(04:55:14 AM) sech1: I'm just saying it's premature to cry "CPU-only" everywhere
(04:55:32 AM) tevador: yes I agree
(04:56:19 AM) sech1: Performance ratio for $ will shift from 4:1 (GPU:CPU) to more like 1:2 I think
(04:56:51 AM) sech1: But CPUs need motherboard and RAM on the other hand
(04:57:42 AM) tevador: for current miners, performance per W will be more important since they already have the hardware
(04:58:42 AM) tevador: power on vega doesn't have to be too bad if you only run 4 FP64 cores and 4 integer cores per CU
(06:25:02 AM) oneiric_ left the room (quit: Remote host closed the connection).
(06:25:30 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(06:44:03 AM) hyc: Do they actually have conditional instruction combos? otherwise ?: is still an if/branch
(07:48:15 AM) sech1: they have predicates
(07:48:33 AM) sech1: every instruction can be executed depending on the flag set by some previous instruction
(07:57:13 AM) hyc: ok. yes, predicates, that's what I mean. same as in ARMv7
(08:03:20 AM) linzhi-sonia: needmoney90: here I am, sorry it was a little slow, but will stay here. if anyone has serious questions it may need a little research time to answer. thanks!
(08:03:55 AM) needmoney90: Welcome to the discussion linzhi-sonia 
(08:07:38 AM) gingeropolous: heya, thanks for coming to hang out
(08:11:20 AM) needmoney90: linzhi-sonia is a representative from Linzhi ASICs. I thought adding another asic dev to the chat would be beneficial  
(08:11:30 AM) needmoney90: Play nice together, everyone 
(08:14:56 AM) gingeropolous: well i guess i'll start: linzhi-sonia , what do you think of CNv4 (the pow we're switching to in ... a day?) https://github.com/SChernykh/CryptonightR[1] , and RandomX (https://github.com/tevador/RandomX[2]), the PoW we hope will make ASICs on par with general purpose hardware?
(08:20:56 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(08:35:31 AM) soiology left the room (quit: Ping timeout: 244 seconds).
(08:40:53 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(08:42:12 AM) sech1: linzhi-sonia are you a PR representative or an engineer? We're more interested in technical analysis.
(09:18:40 AM) needmoney90: An engineer. 
(09:19:41 AM) needmoney90: They are the main person people interact with on their telegram, and from experience, appear to be able to talk at a high level 
(09:19:56 AM) needmoney90: Though I'll let you guys come to your own conclusions 
(09:20:38 AM) needmoney90: (I assume engineer, correct me if I'm wrong) 
(10:20:01 AM) [-mugatu-] is now known as Soiology
(10:30:49 AM) sech1 left the room (quit: Read error: Connection reset by peer).
(10:56:20 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:18:06 AM) tevador: sech1: the growing dataset has one small problem: it encourages mining with the memory-time tradeoff
(11:20:10 AM) tevador: since you can use just 256 MB with 16x higher number of accesses, so for some value >4 GiB this becomes the optimal strategy
(11:53:52 AM) sech1: But 256 MB should grow proportionally
(12:13:02 PM) linzhi-sonia: gingeropolous: I think it's best if I focus on RandomX, the CNv4 is too close to rollout, and let's just watch! We are not working on any Monero asics... I would worry that ASICs (or other accelerators) reappear faster than people think, but who knows.
(12:13:29 PM) linzhi-sonia: for RandomX, I need to talk with the team a bit, I don't think anyone ever looked at that
(12:14:06 PM) linzhi-sonia: maybe I use this chance to explain how we typically go through a chip design process, in 5 steps:
(12:14:18 PM) linzhi-sonia: 1. math description
(12:16:25 PM) linzhi-sonia: If we have an algo'd math description, we start from that. If we only have source code, we first convert it to math. That's because hardware may use a fundamentally different way to compute the same algorithm.
(12:16:39 PM) linzhi-sonia: 2. clarify optimization goal
(12:17:44 PM) linzhi-sonia: Optimize for high throughput? low latency? low power? low energy? low cost? fast time-to-market? security? high reliability? After that we have constraints, such as budget, target performance, maximum power, target delivery time, etc.
(12:17:55 PM) linzhi-sonia: 3. define boundary between hw and sw
(12:19:07 PM) linzhi-sonia: A given algo may not worth to be fully implemented in hw. Decide which parts to run in sw and which part to run in hw after careful algo study. Normally hardware can handle the major data flow for high-performance. Software can handle complex protocol. But after analysis if the protocol is the performance bottleneck, it can also move to hardware.
(12:19:18 PM) linzhi-sonia: 4. choose building blocks
(12:22:14 PM) linzhi-sonia: Every building block has many vendors. For example something as simple as an adder: For smallest area we choose Ripple-carry adder, for lowest latency we choose Kogge-Stone adder. There are many others (carry-skip, carry-lookahead, Brent-Kung, Han-Carlson, Conditional sum, Sklansky, Ling, Jackson, ...) Each have different PPA (power-performance-area). Same for memory, SRAM, eDRAM, eFlash, MRAM, RRAM, Regfile, off-chip: many more
(12:22:50 PM) linzhi-sonia: 5. physical implementation
(12:23:40 PM) linzhi-sonia: many details: foundry, process, floor plan, simulation, clocking, power distribution, timing, signal integrity, temperature range, aging, pinout, packaging, ...
(12:24:47 PM) linzhi-sonia: so that's basically the process. When you want feedback about RandomX, we need to think through this process, at least to some degree, so that the feedback is valuable
(12:25:43 PM) linzhi-sonia: I'm very curious about the CNv4 rollout tomorrow, and I hope it works out well! and I hope it gives the stability (asic deterrance) everyone expects
(12:25:56 PM) linzhi-sonia: we expect hashrate to go down to 350 MH?
(12:26:01 PM) tevador: linzhi-sonia: perfect, btw I will publish full documentation soon, so reading the source code is not necessary
(12:26:53 PM) tevador: sech1 it cannot grow proportionally, we need a power of 2 (or modulo)
(12:26:54 PM) gethh left the room (quit: Quit: Connection closed for inactivity).
(12:27:26 PM) linzhi-sonia: tevador: for RandomX?
(12:27:35 PM) tevador: yes, RandomX
(12:28:37 PM) linzhi-sonia: that's great
(12:32:50 PM) sech1: tevador why power of 2?
(12:33:16 PM) tevador: to avoid expensive division
(12:33:41 PM) sech1: it can be replaced with multiplication by reciprocal
(12:34:26 PM) sech1: this multiplication can fit in 32 bits even
(12:35:58 PM) tevador: well, Argon2 has 1024 byte blocks, so that's another limitation
(12:36:11 PM) tevador: but that should be ok for 2 MB
(12:36:46 PM) tevador: btw Etherem has fixed 16 MB buffer which doesn't grow
(12:37:04 PM) sech1: Maybe we don't need to grow small 256 MB dataset either
(12:37:05 PM) tevador: so they will be affected by this tradeoff once DAG size > 4 GB
(12:37:46 PM) sech1: Anyway, we can grow it in 128 KiB steps too
(12:38:24 PM) tevador: 32 MB per year
(12:38:37 PM) tevador: I guess that is acceptable?
(12:40:38 PM) sech1: yes
(12:41:10 PM) sech1: It'll take 20+ years until RPi with 1 GB can't run it
(01:07:47 PM) hyc: Rpi has no hardware AES, just not worth considering
(01:08:29 PM) tevador: still, it might have performance implications for verification, so I'm not so sure about it
(01:52:14 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(03:34:41 PM) sech1 left the room (quit: Quit: Leaving).
(03:35:02 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:48:02 PM) rottensox left the room (quit: Quit: Leaving).
(04:07:04 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(04:08:58 PM) Soiology left the room (quit: Ping timeout: 246 seconds).
(04:18:47 PM) hyc: btw, the lukMiner guy ranting about version naming https://lukminer.org/2019/03/06/upcoming-monero-xmr-v4r/comment-page-1/?unapproved=7980&moderation-hash=b1147ec98377c6e3b79c6797aa50c413#comment-7980
(04:18:54 PM) hyc: still hasn't approved this comment
(05:24:21 PM) tevador: hyc: well written, let's give him a chance to approve it, maybe he missed it
(05:26:20 PM) tevador: CN/R is already on Nicehash
(06:12:51 PM) gethh [uid264798@gateway/web/irccloud.com/x-rmwvtdlcrkrejomv] entered the room.
(06:45:35 PM) patap0n [~jsmith@unaffiliated/patap0n] entered the room.
(07:03:10 PM) patap0n left the room (quit: Ping timeout: 255 seconds).
(07:20:14 PM) sech1 left the room (quit: Quit: Leaving).
(07:21:59 PM) needmoney90: Why was the version number incremented when the PoW is identical? 
(07:22:34 PM) moneromooo: Because it's fork version - 6. This means this formula had to be added to the pools/miners/etc only once.
(07:22:53 PM) moneromooo: Then they'll auto select the right PoW version, and only PoW needs to change afterwards.
(07:23:28 PM) moneromooo: A bit change-y for CNv4 since it needs the height passed, but hey, unforeseen, special case.
(08:35:28 PM) lithiumpt left the room (quit: Ping timeout: 268 seconds).
(08:55:45 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:14:10 PM) patap0n [~jsmith@unaffiliated/patap0n] entered the room.
(11:44:13 PM) investanto left the room (quit: Quit: Changing servers).
(12:00:26 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(12:47:53 AM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(01:56:16 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(05:59:41 AM) lithiumpt left the room (quit: Read error: Connection reset by peer).
(07:41:49 AM) tevador: 17% of blocks are voting for v11, so we are expecting ~170 MH/s post-fork
(07:43:37 AM) hyc: that's pretty pathetic. all those GPU miners abandoned ship
(07:44:10 AM) moneromooo: Hmm. How are you getting that result ? I'm seeing ~40%.
(07:44:46 AM) moneromooo: Which is a bit odd in itself, seems a bit high.
(07:45:02 AM) moneromooo: I use bc_dyn_stats 100 (or 1000).
(07:47:43 AM) tevador: aha, I checked only last 12 blocks, 2 were v11
(07:48:34 AM) moneromooo: I should probably change this "voting" wording. People might think they have a vote.
(07:48:51 AM) tevador: monerod shows 44
(07:49:52 AM) tevador: that seems wrong
(07:50:09 AM) tevador: how is it calculated?
(07:51:24 AM) tevador: blocks 1787837-1787847, only one has minor 11
(07:52:00 AM) tevador: that is like 0.1% chance if 44% of hashrate has v11
(07:53:55 AM) tevador: so it was just unlucky sample I guess
(07:54:47 AM) tevador: I think pools have updated, but it doesn't mean the miners are actually capable of CNv4
(07:55:20 AM) moneromooo: Hmm. That is a good point...
(07:57:26 AM) hyc: my 112H/s miner on linode will be offline, haven't patched my miner code yet
(07:57:54 AM) hyc: mebbe I should just build xmrig now instead
(07:59:37 AM) tevador: every hash counts!
(08:07:56 AM) hyc: gross. it links both OpenSSL and GnuTLS
(08:08:29 AM) hyc: and it's using both libgcrypt and libnettle. wth. should only need one of any of these.
(08:09:12 AM) kico: try xmr-stak instead ? maybe it uses the same libs tho :P
(08:11:08 AM) hyc: turned off TLS in cmake. much cleaner now
(08:11:32 AM) tevador: stak uses openssl only I think
(08:21:25 AM) hyc: I think this is just a side-effect of debian policy to use gnutls wherever possible. so it's picked up in dependency libraries
(08:21:35 AM) hyc: anyway, turning off all th ebells and whistles is better
(08:52:45 AM) tevador: for example this block: https://xmrchain.net/block/1787877[1] was mined by an ASIC (based on the nonce value), but it's from nanopool, so it has v11
(09:05:28 AM) sech1: This is not necessarily ASIC, xmrig/xmr-stak can also produce such nonce (2^30+982)
(09:06:02 AM) sech1: On 4-GPU rigs or quad-core CPUs
(09:06:56 AM) hyc: and if those ASIC folks have any brains, they're going to switch to less obvious nonce patterns next time
(09:18:13 AM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(09:25:25 AM) tevador: it will be difficult to hide because normal mining rigs never run hundreds of parallel threads
(09:28:38 AM) hyc: maybe not hundreds. but a 6 GPU rig runs quite a lot
(09:29:54 AM) kico: I've seen some 8gpu vega rigs
(09:30:08 AM) kico: there can be 12 gpu vega rigs out there
(09:34:45 AM) sech1: 12-GPU rig usually splits nonce space into 24 parts (2 threads per GPU)
(09:34:54 AM) sech1: It's visible on nonce graph
(09:35:19 AM) kico: oh I was not aware ... m bad
(09:35:25 AM) kico: my*
(09:40:15 AM) tevador: I think they could get plausible deniability by using 2**24 nonces per thread like Nicehash or some proxies, but it would be still detectable
(09:40:54 AM) tevador: they would need exactly 256 threads per ASIC
(10:05:52 AM) sech1: "yeah, those 500 MH/s totally come from Nicehash sure"
(10:06:01 AM) sech1: while Nicehash has 10 MH/s for example
(10:08:05 AM) tevador: yes, plus you will see that all workers have exactly the same hashrate
(10:08:16 AM) tevador: totally not ASIC chips
(10:11:57 AM) hyc: heh
(10:18:14 AM) tevador: so this time, 44% of blocks are voting v11, last year only 20% voted v7
(10:26:37 AM) gingeropolous: most ive gotten is about 14 gpus. they aint vegas though
(12:22:44 PM) tevador: 51% now signaling fork support
(12:44:02 PM) tevador: can't see any ASIC nonces in the last few blocks, what's up?
(12:45:06 PM) hyc: stepping out leaves the network stranded with high difficulty
(12:45:17 PM) hyc: they could just be f#cking with us now
(12:45:43 PM) gingeropolous: yeah, so the fork won't happen in 27 minutes... it'll take much longer
(12:46:16 PM) gingeropolous: and meantime they can work on their own chain and try some re-orgs. i dunno
(12:47:23 PM) sech1: last 100 blocks took 240 minutes to mine, only 20% slower than usual
(12:47:28 PM) sech1: doesn't look like 51%
(12:48:34 PM) tevador: last 10 blocks 35 minutes
(12:49:17 PM) sech1: well, it makes difficulty drop faster after the fork
(12:49:34 PM) sech1: Slower blocks will kick in diffictulty calculation earlier
(12:50:00 PM) tevador: also it's too close to the fork to pull off a 51% attack I think
(12:50:19 PM) sech1: yeah, what's the number of confirmations on exchanges?
(12:50:29 PM) sech1: They probably halted all XMR deposits now
(12:50:44 PM) tevador: should be at least 60 confirmations
(12:50:48 PM) sech1: 14 blocks left
(12:51:09 PM) hyc: 13 now
(12:51:14 PM) hyc: 6 minutes forthe last block
(12:55:07 PM) hyc: 12 now ;)
(12:59:59 PM) tevador: looks like ASICs are gone and network is around 500 MH/s, which is higher than expected
(01:00:17 PM) sech1: Not all ASICs are gone
(01:00:59 PM) jwinterm: tevador: I wanna say bittrex usually requires 10 confirms or so
(01:01:05 PM) moneromooo: What'd be funny is that after the fork they all come back.
(01:01:34 PM) tevador: I guess now they are uploading CN/R bitstreams :D
(01:02:37 PM) hyc: funny, ha ha
(01:02:51 PM) jwinterm: 15 confirmations are required before the funds are available for trading.
(01:02:53 PM) jwinterm: from kraken
(01:02:59 PM) jwinterm: can't find polo or bittrex quickly
(01:03:19 PM) jwinterm: so probably too late
(01:03:25 PM) jwinterm: would have been fun...
(01:03:38 PM) tevador: 11 blocks to go
(01:04:52 PM) tevador: 7 blocks
(01:04:53 PM) hyc: 7! 4 in a row
(01:04:59 PM) tevador: that was fast 
(01:05:07 PM) sech1: So they've updated bitstreams already, lol
(01:08:32 PM) hyc: 6
(01:10:05 PM) hyc: 4, 2 reorgs
(01:10:33 PM) tevador: only depth 2
(01:10:51 PM) tevador: 4 blocks
(01:11:00 PM) sech1: https://xmrchain.net/block/1787995[1] this is ASIC nonce 100%
(01:11:43 PM) hyc: 3
(01:11:43 PM) tevador: yes, also not signaling 11
(01:12:05 PM) tevador: why so many transactions now?
(01:12:06 PM) hyc: cool, so are they solo mining or private pool?
(01:13:36 PM) tevador: I think private pool makes more sense
(01:14:13 PM) tevador: 2 blocks to go
(01:14:36 PM) kinghat: yay!
(01:14:42 PM) tevador: v10
(01:14:57 PM) hyc: woohoo!
(01:15:23 PM) tevador: ok, no rejected shares, looking good
(01:16:41 PM) hyc: no new block yet....
(01:17:19 PM) sech1: Patience
(01:17:27 PM) sech1: 20-30 minutes until next block at least
(01:17:41 PM) tevador: should be less than 20 minutes I think
(01:18:01 PM) sech1: There was 150 MH/s non-ASIC miners
(01:18:07 PM) sech1: half of them not updated
(01:18:21 PM) sech1: so 20-30 minutes
(01:18:35 PM) tevador: a lot of miners came online today
(01:19:49 PM) sech1: supportxmr gets 4 times less valid shares now
(01:20:12 PM) sech1: or should I say fewer, lol
(01:20:14 PM) sech1: damn grammar
(01:20:28 PM) hyc: hm, i'm mining on xmrpool.net and it says height 1,787,999 still
(01:20:31 PM) tevador: doesn't mean much, it could be low diff shares
(01:21:07 PM) tevador: hyc maybe they are showing the last block
(01:21:42 PM) jwinterm: pools usually show one block less I think than explorer/daemon
(01:21:57 PM) hyc: ok
(01:22:20 PM) tevador: I have connected 3 KH/s for heroic mining
(01:23:18 PM) tevador: that's 7-8 ASIC chips
(01:23:40 PM) hyc: my pool hashrate just dropped lie 75%
(01:23:50 PM) hyc: as in total pool rate, not my personal hashrate
(01:23:54 PM) sech1: just as expected, supportxmr lost half of hashrate and still dropping
(01:24:30 PM) tevador: botnets are people who didn't update, classic
(01:24:43 PM) hyc: lol
(01:26:49 PM) sech1: webminers are also gone now
(01:27:05 PM) sech1: or at least crippled - 2-3 times slower
(01:27:22 PM) hyc: my pool dropped from 203 miners to 40 connected
(01:27:29 PM) tevador: invalid shares on supportxmr https://i.imgur.com/sBBkUH1.png[1]
(01:30:29 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(01:31:57 PM) tevador: the first ~60 blocks will be painful before difficulty starts decreasing
(01:32:44 PM) tevador: soon monerod will start complaining about lack of blocks
(01:33:07 PM) hyc: yeha, looks like it's been 18 minutes already
(01:33:22 PM) sech1: first 75 blocks
(01:33:40 PM) sech1: but since a few blocks pre-fork were slow, we might get lower difficulty earlier
(01:40:10 PM) sech1: RIP https://www.nicehash.com/algorithm/cryptonightv8[1]
(01:40:44 PM) moneromooo: I can't wait to hit CNv8 and confuse the hell out of those people.
(01:40:59 PM) hyc: lol 
(01:41:21 PM) hyc: 97 active orders still on nicehash - people not paying attention
(01:41:36 PM) moneromooo: Though in retrospect, I should have made it the same as block version.
(01:41:45 PM) tevador: paying for invalid shares - priceless
(01:41:51 PM) hyc: lol
(01:42:09 PM) hyc: moneromooo: why bump the version# when the algo doesn't change?
(01:42:31 PM) moneromooo: For the other consensus changes.
(01:42:55 PM) moneromooo: Like we have a change to ringct signatures, and one to allow unmixable outputs.
(01:43:01 PM) tevador: so let's make the next one CNv12
(01:43:12 PM) sech1: let's just do 3 forks in a row next time and we'll be on CNv8
(01:43:17 PM) hyc: lol
(01:43:38 PM) moneromooo: Hmm, bad example, since we do have a PoW change here. So, next one (in a day) forbids old ringct sigs.
(01:43:57 PM) sech1: Yes, we'll be on CNv5 after 720 blocks
(01:44:11 PM) sech1: and on CNv8 after 3 more version bumps
(01:44:56 PM) tevador: or RandomXv0?
(01:45:50 PM) moneromooo: Yes, that might come before we reach CNv8...
(01:46:14 PM) hyc: yeah it may just be time to retire CN name
(01:47:31 PM) gingeropolous: RXv0
(01:48:33 PM) tevador: still no block
(01:50:01 PM) tevador: electroneum botched their fork last year and had to buy hashpower on nicehash to produce a few blocks per day at least
(01:50:22 PM) hyc: lol uh oh. does nicehash have CN/R for sale?
(01:50:29 PM) tevador: yes
(01:50:56 PM) tevador: it has 3-4 MH/s
(01:51:21 PM) tevador: should be enough for 3 blocks per day :D
(01:52:15 PM) hyc: woohoo
(01:52:37 PM) tevador: does anyone have the old monerod? did the old chain die?
(01:52:57 PM) hyc: hmmm. I don't have one handy right now
(01:53:00 PM) gingeropolous: i thought dwarfpool published a blovck
(01:53:16 PM) gingeropolous: according to reddits
(01:54:18 PM) tevador: it still days 1788000
(01:54:22 PM) tevador: says*
(01:54:43 PM) sech1: my monerod says 1788000
(01:55:01 PM) sech1: http://dwarfpool.com/xmr says 1788000 19-03-09, 19:52:00 (1 minute ago) 0.0000 searching...
(01:55:17 PM) sech1: oh, they're searching
(01:55:24 PM) tevador: so pool hashrate is around 110 MH/s at the moment
(01:55:49 PM) tevador: according to https://miningpoolstats.stream/monero[1]
(01:56:16 PM) tevador: the two chinese pools died
(01:56:22 PM) hyc: lol
(01:57:01 PM) tevador: waterhole.io, where do they get these names?
(02:00:24 PM) hyc: 88.5% of hashrate gone huh
(02:01:00 PM) ArticMine: Not unlike what happened last year
(02:01:21 PM) sech1: this is exactly what happened a year ago with CNv1 fork
(02:01:29 PM) sech1: and 85% ASICs
(02:01:40 PM) hyc: yep
(02:01:56 PM) tevador: the first block was faster last year, though
(02:02:03 PM) tevador: bad luck
(02:02:19 PM) hyc: we need to diversify our nonce selection algos :P
(02:03:34 PM) tevador: https://www.reddit.com/r/Monero/comments/az5on0/scheduled_protocol_upgrade_live_discussion_thread/ei5nsbk/[1]
(02:03:36 PM) tevador: that's the spirit
(02:03:59 PM) gethh: lool
(02:05:33 PM) gingeropolous: i don't think ethos updated
(02:05:45 PM) sech1: https://xmr.nanopool.org/account/46HyBCKt8WHSrEBPSPn2cpWqDhrACMTJRF8QP4G8Kwf4GLyYVMvYi8XNSYwNa8FAL6bSmxu3udE7QGnoS6pbh4YNNR8MRhZ[1]
(02:05:48 PM) gingeropolous: xmrstak was so slow to get out
(02:05:53 PM) sech1: Botnets learned how to update
(02:10:16 PM) tevador: no block for 1 hour, that must be a record
(02:12:30 PM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-xgxmylqgwnrmujtn] entered the room.
(02:12:39 PM) sech1: Should be a block every 20 minutes on average if it's really 100 MH/s on pools
(02:12:43 PM) sech1: bad luck
(02:13:18 PM) needmoney90: so does that mean we broke monero
(02:13:47 PM) tevador: I hope it's not one of those 1000% effort blocks :P
(02:13:48 PM) sech1: No
(02:14:23 PM) sech1: Wownero and Lethean forked to cn/r before and they mined blocks successfully
(02:15:37 PM) tevador: technically, they had a different algorithm
(02:17:01 PM) sech1: Only Wownero
(02:17:06 PM) sech1: Lethean is the same cn/r
(02:17:18 PM) tevador: well, they had a different block height I assume
(02:17:36 PM) sech1: But what if some pools are on the old chain and network has less than 100 MH/s?
(02:19:00 PM) tevador: it's true that some pool suspiciously didn't drop any hashrate
(02:19:04 PM) tevador: pools*
(02:19:10 PM) ArticMine: The other fact to consider is a lowering o the hash rate for CPU / GPU
(02:19:13 PM) ArticMine: factor
(02:19:26 PM) tevador: that's negligible
(02:21:55 PM) tevador: aha, c3pool.com has 8 MH/s, but it's not mining XMR
(02:22:12 PM) tevador: not sure why it's listed under xmr
(02:22:39 PM) sech1: MoneroOcean is not mining XMR now too
(02:23:18 PM) tevador: supportxmr, nanopool and minexmr are together ~55 MH/s
(02:23:42 PM) tevador: so real hashrate is at least this
(02:23:50 PM) ArticMine: That is ~5%
(02:24:32 PM) tevador: that would make this fork worse than the last one
(02:25:21 PM) ArticMine: you mean the fork in the spring of last year
(02:25:56 PM) tevador: I mean v7 fork yes
(02:32:22 PM) sech1: it looks like MoneroOcean forced all their miners to XMR now
(02:32:41 PM) tevador: heroes!
(02:38:08 PM) sech1: Nope. They switched back to shitcoins
(02:39:03 PM) tevador: would it make sense to reset the difficulty calculation during the next fork?
(02:39:50 PM) tevador: it could be less damage to have a few faster blocks than paralyzed currency for 2 days
(02:40:31 PM) sech1: supportxmr has some issues
(02:40:46 PM) sech1: it was probably mining for nothing all this time
(02:40:53 PM) tevador: lol
(02:41:07 PM) tevador: I'm mining there
(02:41:50 PM) sech1: Some miners got job for 1788001 and then got banned
(02:43:49 PM) tevador: anyways that should not happen even before this fork, because the block would be invalid
(02:44:04 PM) tevador: except shares could be counted as valid before, not now
(02:45:19 PM) tevador: no blocks in the last 90 minutes
(02:45:28 PM) sech1: supportxmr is borked now
(02:45:47 PM) sech1: sends wrong block height to miners
(02:46:47 PM) tevador: that's like 1/3 of the hashrate gone
(02:47:04 PM) sech1: you 1/3 of what remains
(02:47:07 PM) sech1: *you mean
(02:47:10 PM) tevador: yes
(02:47:15 PM) sech1: bad
(02:47:45 PM) tevador: if I could just point xmr-stak at my monerod and mine, I would do it
(02:47:54 PM) tevador: but it's not supported afaik
(02:48:23 PM) tevador: not sure about other miners
(02:51:37 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:51:38 PM) sech1: Found v9 chain explorer: https://monero.exan.tech/
(02:51:40 PM) JohnTheCryptoBap [b5d76ecb@gateway/web/freenode/ip.181.215.110.203] entered the room.
(02:54:50 PM) sech1: supportxmr is fixed. Not sure about other pools now, so we can assume only 25 MH/s.
(02:55:11 PM) tevador: yeah, so I was mining cn/2 the whole time on supportxmr...
(02:55:17 PM) jwinterm_ [~quassel@unaffiliated/jwinterm] entered the room.
(02:56:21 PM) sech1: No, you were mining cn/r which then went to cn/2 daemon node or whatever
(02:56:42 PM) jwinterm left the room (quit: Ping timeout: 252 seconds).
(02:57:06 PM) jwinterm_ is now known as jwinterm
(02:57:14 PM) tevador: well, my CPU hashrate dropped from 65 per core to 14 per core
(02:57:49 PM) tevador: I thought xmr stak already had jit compiler
(02:57:57 PM) ArticMine: That was m point before. This is not negligible
(02:57:58 PM) sech1: xmr-stak 2.10 has
(03:00:15 PM) moneromooo: 25 MH/s... that's starting to sound dangerous...
(03:00:59 PM) tevador: I think there is a bug in xmr-stak
(03:01:17 PM) tevador: it switched from jit compiler to interpreter for some reason
(03:01:41 PM) hyc: a bug? in the computing god fireice's code??
(03:01:55 PM) hyc: must be an intentional "feature", surely not a bug
(03:02:00 PM) tevador: 510 H/s -> 115 H/d
(03:02:05 PM) sech1: they're a team of professionals who work fast, don't forget
(03:02:07 PM) tevador: H/s*
(03:02:08 PM) sgp_: if there indeed is, he will probably claim it's purposeful, and that no one was smart enough to check
(03:02:21 PM) tevador: maybe it's a feature if you are not mining ryo
(03:02:51 PM) tevador: anyways, fireice barely writes anything in xmr-stak anymore
(03:02:55 PM) sgp_: what are the consequences of the bug?
(03:02:58 PM) tevador: besides Ryo ASCII arts
(03:03:01 PM) hyc: my pool is nearly recovered. 195 miners (203 pre-fork)
(03:03:15 PM) hyc: 301KH/s. about same as pre-fork I think
(03:03:50 PM) hyc: oh shit no
(03:04:03 PM) hyc: my pool is now sending out CNv2 jobs again
(03:04:13 PM) sech1: supportxmr dropped to 13 MH/s
(03:04:15 PM) hyc: and reporting block height 1,788,001
(03:05:02 PM) hyc: 30 minutes ago it switched from CN/R back to CNv2
(03:05:20 PM) hyc: that's why it's at pre-fork hashrate - it's on the old chain
(03:05:21 PM) selsta left the room (quit: Ping timeout: 252 seconds).
(03:05:44 PM) hyc: how the heck did a mining pool get onto new chain and then switch back?
(03:07:25 PM) tevador: so all pools are broken now?
(03:08:03 PM) tevador: time to solo mine, I guess
(03:08:11 PM) hyc: sounds like it
(03:08:14 PM) tevador: with 30 H/s
(03:08:29 PM) selsta [sid124829@gateway/web/irccloud.com/x-emrysuxcjduzzzem] entered the room.
(03:08:53 PM) sgp_: what's wrong with the pools?
(03:09:13 PM) sgp_: I can update the MoneroMining thread with updated info telling people what to do
(03:09:27 PM) tevador: 2 pools now are having issues
(03:09:31 PM) tevador: details unknown
(03:09:38 PM) sech1: supportxmr seems to be working now
(03:09:41 PM) sgp_: are there any we know are all right?
(03:09:49 PM) sech1: send job for block 1788000
(03:09:51 PM) sech1: *sends
(03:10:12 PM) sech1: all switch to supportxmr until other pools get their shit together
(03:10:26 PM) sgp_: what pools do you know are having trouble?
(03:11:41 PM) sech1: xmrpool.net
(03:12:34 PM) sech1: 1788001 !!!
(03:12:37 PM) sech1: in my monerod
(03:12:44 PM) tevador: yes
(03:12:57 PM) gingeropolous: yee haw!
(03:12:59 PM) gingeropolous: who got it?
(03:13:02 PM) kinghat: who found it?
(03:13:04 PM) sgp_: woo-hoo!
(03:13:27 PM) sech1: not supportxmr, not nanopool
(03:13:29 PM) sech1: someone else
(03:14:05 PM) ArticMine: Confirmed on my three nodes 1788001 V10
(03:14:13 PM) kinghat: sech1: are you xmrig?
(03:14:27 PM) sech1: I'm not xmrig
(03:14:37 PM) sech1: I'm sech1 obviously
(03:14:45 PM) kinghat: but ofc.
(03:14:59 PM) sech1: But I implemented cn/r in xmrig
(03:15:23 PM) ArticMine: xmrchain.net saw it
(03:15:35 PM) moneromooo: Damn not my block :D
(03:15:41 PM) kinghat: maybe thats why i made the connection. who is the auth for xmrig?
(03:15:49 PM) hyc: mining in daemon is 2/3 speed of xmrig
(03:15:57 PM) hyc: wth JIT on
(03:16:30 PM) tevador: 100 transactions, full block
(03:16:33 PM) ArticMine: Minergate is also showing it
(03:17:26 PM) sech1: Network diff went down a bit
(03:17:39 PM) JohnTheCryptoBap left the room (quit: Ping timeout: 256 seconds).
(03:18:03 PM) sgp_: Do I need to tell people not to use XMR-STAK?
(03:18:46 PM) tevador: sgp_: stak is working, but I had to restart to get back my CPU hashrate
(03:19:07 PM) hyc: pool.support.xmr.com:5555 connection refused
(03:19:13 PM) tevador: [pool-at.supportxmr.com:7777] Duplicate equal job detected! Please contact your pool admin.
(03:19:13 PM) gingeropolous: i read somewhere that some miner implementation switched to xmrig because stack is unstable
(03:19:16 PM) tevador: sxmr broken
(03:21:18 PM) tevador: so next block in 1 hour or so at best
(03:21:45 PM) sech1: supportxmr is down again
(03:22:18 PM) hyc: pool-at.supportxmr.com:5555 worked, thanks
(03:23:09 PM) tevador: I think pool-at now redirects to pool-de, so Germany
(03:23:14 PM) tevador: your ping might be a bit high
(03:23:24 PM) hyc: Ireland, should be tolerable
(03:24:46 PM) tevador: supportxmr:  pool problems. working on it
(03:25:07 PM) sech1: what a mess
(03:30:05 PM) sech1: Height: 1788002/1788002 
(03:30:42 PM) hyc: yay
(03:30:44 PM) sech1: minexmr found it
(03:30:54 PM) hyc: heh daemon's network HR estimate went *up*
(03:31:10 PM) sech1: so at least minerxmr is working fine
(03:31:16 PM) gingeropolous: can;t decide if its worth it to set up a working pool
(03:31:19 PM) gingeropolous: my testnet pool worked fine
(03:32:55 PM) tevador: gingeropolous yes, I tested on your pool
(03:33:42 PM) sech1: 1788003 !!!
(03:34:05 PM) tevador: so pools started working maybe
(03:34:11 PM) TomTheDeepot [cfbd106a@gateway/web/freenode/ip.207.189.16.106] entered the room.
(03:34:12 PM) hyc: network HR increasing again
(03:34:16 PM) sgp_: I would say so
(03:34:20 PM) sgp_: NEW ASICS!
(03:34:23 PM) hyc: ^^^
(03:34:25 PM) sgp_: We lasted 2 hours
(03:34:29 PM) gingeropolous: burn the whole thing down
(03:34:42 PM) hyc: takes a long time to reprogram an FPGA :P
(03:35:01 PM) sech1: 2 hours ASIC-proof, that's an achievement to remember
(03:36:12 PM) ArticMine: It seems like some of the pools were not working
(03:36:21 PM) hyc: yeah
(03:36:42 PM) stoffu left the room (quit: Ping timeout: 252 seconds).
(03:36:50 PM) stoffu [sid260213@gateway/web/irccloud.com/x-woinfokoejloiwcj] entered the room.
(03:37:23 PM) ArticMine: The hash rate drop may not e as high this time around.
(03:37:24 PM) hyc: xmrpool.net seems to be back on the right chain and algo again
(03:37:44 PM) tevador: lol
(03:38:37 PM) TomTheDeepot left the room (quit: Ping timeout: 256 seconds).
(03:38:40 PM) sech1: 1788002 was nanopool
(03:38:46 PM) sech1: so nanopool works too
(03:45:06 PM) rottensox left the room (quit: Ping timeout: 252 seconds).
(03:46:02 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:00:16 PM) tevador: looks like poolin.com found the first block 1788000
(04:01:38 PM) tevador: new block
(04:02:34 PM) sech1: current height 1788005
(04:02:46 PM) sech1: it seems to be moving forward faster than a year ago
(04:02:51 PM) sech1: after everyone fixed their shit
(04:03:41 PM) hyc: not really seeing the difficulty move in the right direction
(04:04:08 PM) nioc: that takes like 12hrs
(04:04:11 PM) sech1: because DAA works in mysterious ways
(04:04:24 PM) tevador: it will not move until block ~1788070
(04:04:39 PM) sech1: first 75 blocks will be pre-fork difficulty
(04:04:47 PM) sech1: then it will start dropping
(04:05:21 PM) tevador: height: 1788007
(04:05:34 PM) sech1: gaining speed
(04:07:12 PM) tevador: hmmm, all my cards stopped mining after 2 hours
(04:08:07 PM) sech1: why?
(04:08:11 PM) tevador: looks like xmr-stak is utterly broken
(04:08:21 PM) sech1: don't use it
(04:08:21 PM) tevador: 6 cards showing n/a hashrate
(04:08:31 PM) sech1: "professionals"
(04:08:41 PM) sech1: they can't even copy-paste my xmrig code properly
(04:08:47 PM) hyc: lol
(04:09:42 PM) tevador: what is the repo for xmrig?
(04:10:28 PM) hyc: github.com/xmrig/xmrig
(04:10:28 PM) sech1: github.com/xmrig/xmrig for CPU
(04:10:31 PM) hyc: that's the CPU
(04:10:32 PM) sech1: github.com/xmrig/xmrig-amd for AMD
(04:11:06 PM) hyc: is that AMD using openCL or vulkan or ... ?
(04:11:41 PM) wowario: lol
(04:11:56 PM) tevador: I have unkillable xmr-stak process, great
(04:12:36 PM) sech1: hyc OpenCL
(04:18:55 PM) hyc: I just fired up a new node here and it got stuck at 1788001
(04:19:29 PM) hyc: so apparently there's a few nodes out there on v10 but the wrong chain
(04:20:07 PM) sech1: But if you connect to a node that's not stuck, you should reorg
(04:20:15 PM) sech1: *your node
(04:20:23 PM) hyc: yeah, hasn't happened yet
(04:20:34 PM) hyc: I've rm'd p2pstate.bin and restarted twice
(04:22:13 PM) wowario: try --add-exclusive-node nodes on correct chain
(04:23:17 PM) hyc: yeah that worked
(04:23:48 PM) sech1: what was the command to turn on JIT in monerod?
(04:24:19 PM) hyc: you need an env var
(04:24:57 PM) hyc: MONERO_USE_CNV4_JIT=1
(04:25:45 PM) sech1: "export MONERO_USE_CNV4_JIT=1" in starting script?
(04:25:49 PM) hyc: so we got lucky for a few blocks, now 007 is taking time 
(04:25:53 PM) hyc: sech1 yes
(04:26:59 PM) sech1: popped 20 blocks, started monerod with JIT
(04:27:03 PM) sech1: let's see how it works
(04:27:20 PM) hyc: was about 3x faster here
(04:27:20 PM) sech1: synced fine
(04:27:39 PM) hyc: daemon miner hashrate that is
(04:53:38 PM) tevador: I wanted to work on RandomX today, instead I will be configuring xmrig...
(04:54:29 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:13:17 PM) tevador: so I guess RX 550 have some issues with cn/r
(05:19:22 PM) kico: mine are doing fine
(05:19:27 PM) kico: same HR as before
(05:19:34 PM) kico: rx 550s
(05:20:31 PM) kico: on stak v2.10.0
(05:20:43 PM) tevador: which kind of 550s?
(05:20:47 PM) kico: v2.9 wasn't picking them up
(05:21:03 PM) kico: I have radeon ones
(05:21:26 PM) kico: aero ones
(05:21:27 PM) tevador: all 550 are radeon I guess
(05:21:44 PM) kico: not the good pulse ones
(05:22:20 PM) tevador: I have sapphire pulse
(05:22:29 PM) kico: those are good
(05:22:40 PM) tevador: on stak 2.10, 2 identical rigs die after ~2 hours
(05:22:41 PM) kico: not working with cn/r ?
(05:22:56 PM) tevador: xmrig-amd - died after 2 minutes
(05:23:11 PM) kico: damn ... for the first time I'm glad I got the wrong ones then eheh
(05:23:35 PM) tevador: might be too much overclock for cn/r
(05:23:41 PM) kico: my mate has a rig with 13 of pulse but 4gb model and it's mining also
(05:24:07 PM) kico: they increased a little in HR even
(05:24:16 PM) kico: yeah maybe too much OC eheheh
(05:25:06 PM) tevador: so it looks like OC is pointless anyways since it's compute bound
(05:25:51 PM) tevador: 1500 MHz same as 1800 MHz
(05:26:21 PM) kico: really ? maybe I can underclock then :P
(05:26:33 PM) kico: haven't checked powerdraw
(05:26:45 PM) kico: it should decrease right ?
(05:27:09 PM) kico: that would be great last pow was a bit more hungry than before
(05:30:43 PM) tevador: about 460 H/s per card
(05:30:55 PM) tevador: without overclock
(05:31:40 PM) kico: not bad
(05:31:55 PM) kico: mine only do about 380
(05:32:02 PM) kico: but have stupid mems
(05:33:03 PM) tevador: the rig dies in a strange way
(05:33:18 PM) tevador: all GPU fans stop, CPU fan still spinning
(05:34:35 PM) kico: hmm 
(05:34:46 PM) kico: is it using too much power ?
(05:36:21 PM) tevador: nope, idle
(05:36:43 PM) kico: that's weird
(05:39:59 PM) Inge-: tevador: checked power draw?
(05:43:25 PM) linzhi-sonia left the room (quit: Quit: leaving).
(05:43:33 PM) linzhi-sonia [~linzhi-so@bobbin.q-ag.de] entered the room.
(05:48:42 PM) midipoet [uid316937@gateway/web/irccloud.com/x-mxoeuxofopzcyvpn] entered the room.
(05:49:07 PM) tevador: power draw is around 380 W for this rig
(06:06:54 PM) tevador: ok, seems to be working at the moment, xmrig+xmrig-amd
(06:10:01 PM) tevador: 2 blocks in the last 90 minutes
(06:13:32 PM) tevador: supportxmr has found a block
(06:13:42 PM) tevador: finally
(06:21:02 PM) sech1 left the room (quit: Quit: Leaving).
(07:04:33 PM) hyc: so xmrpool says I've contribued 1.2 billion hashes, and it ows me .026 XMR
(07:04:47 PM) hyc: that's like $1 for months of mining
(07:06:46 PM) hyc: I guess this whole micrpoayment scheme needs some more thought. if hours of background hashin isn't even worth 1 cent, can't really see this replacing web ads
(07:12:11 PM) jwinterm: 1B hashes is ~ 1% of current diff, and 0.03 XMR is ~1% of current block reward
(07:21:32 PM) moneromooo: Checks out. It wouldn't even help if monero went up in price since that'd just attract more miners. Hrm.
(07:23:14 PM) needmoney90: I seem to recall a thing where donating gpu time to researchers was more profitable than mining? 
(07:24:24 PM) needmoney90: Was like a year ago, idk if it's still around 
(07:24:51 PM) needmoney90: Also Hyc, do you think sites get more than $1/user as is for ads? 
(07:25:05 PM) needmoney90: Or is this on par with existing revenue-per-viewer
(07:40:07 PM) jwinterm: "donating" is more profitable than mining?
(07:40:19 PM) jwinterm: by writing off electricity from taxes?
(07:57:05 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:01:51 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(12:18:44 AM) jwinterm left the room (quit: Remote host closed the connection).
(12:19:00 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:21:55 AM) jwinterm left the room (quit: Remote host closed the connection).
(12:22:11 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(01:00:59 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(03:04:14 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(06:06:33 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(06:17:18 AM) midipoet [uid316937@gateway/web/irccloud.com/x-clsvlamteqbymxej] entered the room.
(07:53:05 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(08:47:36 AM) rottensox left the room (quit: Ping timeout: 252 seconds).
(08:48:11 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(09:46:57 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:44:45 AM) p0nziph0ne left the room (quit: Quit: Leaving).
(11:07:01 AM) tevador: lukminer contains precompiled cn/r math sequences for some blocks: https://lukminer.org/2019/03/09/oh-kay-v4r-here-we-come/[1]
(11:07:11 AM) tevador: try that with RandomX :P
(11:09:00 AM) linzhi-sonia: tevador: are you ready for some RandomX feedback? it looks like the CNv4 is slowly stabilizing, hashrate comes down...
(11:09:06 AM) sech1: how does it even make sense to precompile it?
(11:09:14 AM) sech1: mine 1% faster for 2 minutes?
(11:09:35 AM) linzhi-sonia: naturally we think the entire asic-resistance strategy is doomed to fail :) but that's a high-level thing, who knows. people may think it's great.
(11:09:49 AM) linzhi-sonia: about RandomX: looks like the cache size was chosen to make it GPU-hard
(11:09:56 AM) linzhi-sonia: looking forward to more docs
(11:11:38 AM) linzhi-sonia: after initial skimming, I would think it's possible to make a 10x asic for RandomX. But at least for us, we will only make an ASIC if there is not a total ASIC hostility there in the first place. That's better for the secret miners then.
(11:13:12 AM) linzhi-sonia: What I propose is this: we are working on an Ethash ASIC right now, and once we have that working, we would invite tevador or whoever wants to come to HK/Shenzhen and we walk you guys through how we would make a RandomX ASIC. You can then process this input in any way you like. Something like that.
(11:13:52 AM) linzhi-sonia: unless asics (or other accelerators) re-emerge on XMR faster than expected, it looks like there is a little bit of time before RandomX rollout
(11:14:22 AM) sech1: 10x in what measure? $/hash or watt/hash?
(11:14:46 AM) linzhi-sonia: watt/hash
(11:15:19 AM) sech1: so you can make 10 times more efficient double precisio FPU?
(11:16:02 AM) linzhi-sonia: like I said let's try to be productive. You are having me here, let's work together!
(11:16:15 AM) linzhi-sonia: continue with RandomX, publish more docs. that's always helpful.
(11:16:36 AM) sech1: I'm trying to understand how it's possible at all. Why AMD/Intel are so inefficient at running FP calculations?
(11:18:05 AM) midipoet [uid316937@gateway/web/irccloud.com/x-vszshqqxwybvtsjm] entered the room.
(11:18:17 AM) linzhi-sonia: hardware development works the other way round. We start with 1) math then 2) optimization priority 3) hw/sw boundary 4) IP selection 5) physical implementation
(11:22:32 AM) sech1: This still doesn't explain at which point you get 10x
(11:23:07 AM) sech1: Weren't you the ones claiming "We can accelerate ProgPoW by a factor of 3x to 8x." ? I find it hard to believe too.
(11:30:19 AM) linzhi-sonia: sure
(11:30:26 AM) linzhi-sonia: so my idea: first we finish our current chip
(11:30:35 AM) linzhi-sonia: from simulation to silicon :)
(11:30:40 AM) linzhi-sonia: we love this stuff... we do it anyway
(11:30:59 AM) linzhi-sonia: now we have a communication channel, and we don't call each other names immediately anymore: big progress!
(11:31:06 AM) sech1: you know, we russians have a saying "it was smooth on paper, but they forgot about ravines"
(11:31:12 AM) sech1: So I need a bit more details
(11:31:16 AM) linzhi-sonia: ha ha. good!
(11:31:31 AM) linzhi-sonia: that's why I want to avoid to just make claims
(11:31:34 AM) linzhi-sonia: let's work
(11:31:40 AM) linzhi-sonia: RandomX comes in Sep/Oct, right?
(11:31:45 AM) sech1: Maybe
(11:32:20 AM) sech1: We need to audit it first
(11:32:31 AM) linzhi-sonia: ok
(11:32:59 AM) linzhi-sonia: we don't make chips to prove sw devs that their assumptions about hardware are wrong. especially not if these guys then promptly hardfork and move to the next wrong assumption :)
(11:33:10 AM) linzhi-sonia: from the outside, this only means that hw & sw are devaluing each other
(11:33:23 AM) linzhi-sonia: neither of us should do this
(11:33:47 AM) linzhi-sonia: we are making chips that can hopefully accelerate more crypto ops in the future
(11:33:51 AM) linzhi-sonia: signing, verifying, proving, etc.
(11:34:02 AM) linzhi-sonia: PoW is just a feature like others
(11:34:17 AM) linzhi-sonia: sech1: is it easy for you to come to Hong Kong? (visa-wise)
(11:34:29 AM) linzhi-sonia: or difficult?
(11:34:33 AM) linzhi-sonia: or are you there sometimes?
(11:34:40 AM) sech1: It's kind of far away
(11:35:13 AM) linzhi-sonia: we are looking forward to more RandomX docs. that's the first step.
(11:35:31 AM) linzhi-sonia: I want to avoid that we have some meme "Linzhi says they can accelerate XYZ by factor x" .... "ha ha ha"
(11:35:37 AM) linzhi-sonia: right? we don't want that :)
(11:35:39 AM) tevador: doc is almost finished
(11:35:40 AM) sech1: What docs do you need? It's described pretty good
(11:35:41 AM) linzhi-sonia: so I better say nothing now
(11:35:50 AM) linzhi-sonia: we focus on our Ethash chip
(11:36:05 AM) linzhi-sonia: then based on that, we are happy to walk interested people through the design and what else it can do
(11:36:22 AM) linzhi-sonia: that's a better approach from my view than making claims that are laughed away (rightfully so, because no silicon...)
(11:36:37 AM) tevador: ethash ASIC is basically a glorified memory controller 
(11:36:39 AM) linzhi-sonia: sech1: tevador said something more is coming (he just did it again)
(11:37:03 AM) sech1: yes, some parts of RandomX are not described well
(11:37:09 AM) sech1: like dataset access logic
(11:37:37 AM) linzhi-sonia: RandomX looks like progpow for CPU
(11:37:54 AM) sech1: yes
(11:38:03 AM) sech1: it is designed to reflect CPU
(11:38:34 AM) sech1: so any ASIC for it = CPU in essence
(11:39:04 AM) sech1: of course there are still some things in regular CPU that can be thrown away for RandomX
(11:40:20 AM) tevador: uncore parts are not used, but those will use very little power
(11:40:37 AM) tevador: except for memory controller
(11:41:09 AM) linzhi-sonia: I'm just surprised sometimes, ok? let me ask: have you designed or taped out an asic before? isn't it risky to make assumptions about things that are largely unknown?
(11:41:23 AM) linzhi-sonia: I would worry
(11:41:31 AM) linzhi-sonia: that I get something wrong...
(11:41:44 AM) linzhi-sonia: but I also worry like crazy that CNv4 will blow up, where you guys seem to be relaxed
(11:42:06 AM) linzhi-sonia: I didn't want to bring up anything RandomX because CNv4 is such a nailbiter... :)
(11:42:15 AM) linzhi-sonia: how do you guys know you don't have asics in a week or two?
(11:42:37 AM) tevador: we don't have experience with ASIC design, but RandomX is simply designed to exactly fit CPU capabilities, which is the best you can do anyways
(11:43:09 AM) tevador: similar as ProgPoW did with GPUs
(11:43:14 AM) linzhi-sonia: some people say they want to do asic-resistance only until the vast majority of coins has been issued
(11:43:20 AM) linzhi-sonia: that's at least reasonable
(11:43:43 AM) linzhi-sonia: yeah but progpow totally will not work as advertised :)
(11:44:07 AM) hyc: yeah, I've seen that comment about progpow a few times already
(11:44:10 AM) linzhi-sonia: which is no surprise if you know it's just a random sales story to sell a few more GPUs
(11:44:13 AM) tevador: RandomX is not permanent, we are expecting to switch to ASIC friendly in a few years if possible
(11:44:18 AM) linzhi-sonia: yes
(11:44:21 AM) linzhi-sonia: that makes sense
(11:44:40 AM) Inge-: linzhi-sonia: how so? will it break or will it be asic-able with decent performance gains?
(11:44:41 AM) linzhi-sonia: are you happy with CNv4 so far?
(11:45:10 AM) linzhi-sonia: ah, long story. progpow is a masterpiece of deception, let's not get into it here.
(11:45:21 AM) linzhi-sonia: if you know chip marketing it makes more sense
(11:45:24 AM) Inge-: linzhi-sonia: So far? lol! a bit early to tell, don't you think?
(11:45:35 AM) linzhi-sonia: the diff is coming down
(11:45:40 AM) hyc: I remain skeptical: I only see ASICs being reasonable if they are already as ubiquitous as smartphones
(11:45:43 AM) linzhi-sonia: first few hours looked scary
(11:45:46 AM) Inge-: yes, so far so good
(11:46:01 AM) Inge-: we kbew the diff would not come down ubtil affter block 75
(11:46:10 AM) linzhi-sonia: yes
(11:46:21 AM) linzhi-sonia: but first few hours it looks like only 5% hashrate left
(11:46:35 AM) linzhi-sonia: looked
(11:46:35 AM) linzhi-sonia: now it's better
(11:46:50 AM) linzhi-sonia: the next worry is: when will "unexplainable" hashrate come back?
(11:47:00 AM) linzhi-sonia: you hope 2-3 months? more?
(11:47:05 AM) Inge-: so give it another couple of days.  will probably overshoot to the downside,  and then rise a bit as miners get updated and return
(11:47:21 AM) hyc: 3 months minimum turnaround, yes
(11:47:28 AM) linzhi-sonia: nah
(11:47:36 AM) linzhi-sonia: don't underestimate asicmakers :)
(11:47:53 AM) hyc: you guys don't get #1 priority on chip fabs
(11:47:56 AM) linzhi-sonia: 3 months = 90 days. do you know what is happening in those 90 days exactly? I'm pretty sure you don't. same thing as before.
(11:48:13 AM) linzhi-sonia: we don't do any secret chips btw
(11:48:21 AM) hyc: 3 months assumes they had a complete design ready to go, and added the last minute change in 1 day
(11:48:24 AM) linzhi-sonia: do you know who is behind the hashrate that is now bricked?
(11:48:27 AM) linzhi-sonia: innosilicon?
(11:48:34 AM) linzhi-sonia: hyc: no no, and no. :)
(11:48:44 AM) linzhi-sonia: hyc: have you designed or taped out a chip before?
(11:48:51 AM) hyc: yes, many years ago
(11:49:10 AM) linzhi-sonia: then you should know that 90 days is not a fixed number
(11:49:35 AM) hyc: sure, but like I said, other makers have greater demand
(11:49:35 AM) linzhi-sonia: especially not if you can prepare, if you just have to modify something, or you have more programmability in the chip than some people assume
(11:50:07 AM) linzhi-sonia: we are chipmakers, we would never dare to do what you guys are doing with CNv4 :) but maybe that just means you are cooler!
(11:50:07 AM) hyc: and yes, programmability makes some aspect of turnaround easier
(11:50:10 AM) linzhi-sonia: all fine
(11:50:10 AM) linzhi-sonia: I hope it works!
(11:50:28 AM) linzhi-sonia: do you know who is behind the hashrate that is now bricked?
(11:50:29 AM) linzhi-sonia: inno?
(11:50:41 AM) hyc: we suspect so, but have no evidence
(11:50:44 AM) linzhi-sonia: maybe we can try to find them, but we cannot spend too much time on this
(11:50:53 AM) linzhi-sonia: it's probably not so much of a secret
(11:51:01 AM) linzhi-sonia: why should it be, right?
(11:51:10 AM) linzhi-sonia: devs want this cat-and-mouse game? devs get it...
(11:51:35 AM) tevador: there was one leak saying it's innosilicon
(11:51:36 AM) linzhi-sonia: so you think 3 months, ok
(11:51:43 AM) linzhi-sonia: inno is cool
(11:51:46 AM) linzhi-sonia: good team
(11:51:49 AM) linzhi-sonia: IP design house
(11:51:54 AM) linzhi-sonia: in Wuhan
(11:52:06 AM) linzhi-sonia: they send their people to conferences with fake biz cards :)
(11:52:19 AM) hyc: pretending to be other companies?
(11:52:26 AM) linzhi-sonia: sure
(11:52:28 AM) linzhi-sonia: ha ha
(11:52:39 AM) linzhi-sonia: so when we see them, we look at whatever card they carry and laugh :)
(11:52:52 AM) linzhi-sonia: they are perfectly suited for secret mining games
(11:53:02 AM) tevador: they made at most $6 million in 2 months of mining, so I wonder if it was worth it
(11:53:10 AM) linzhi-sonia: yeah. no way to know
(11:53:15 AM) linzhi-sonia: but it's good that you calculate!
(11:53:24 AM) hyc: this is all about cost/benefit
(11:53:25 AM) linzhi-sonia: then you also understand - imagine the value of XMR goes up 5x, 10x
(11:53:34 AM) linzhi-sonia: that whole "asic resistance" thing will come down like a house of cards
(11:53:40 AM) tevador: I would imagine they sell immediately
(11:53:53 AM) linzhi-sonia: the investor may fully understand the risk
(11:53:56 AM) linzhi-sonia: the buyer
(11:54:13 AM) linzhi-sonia: it's not healthy, but that's another discussion
(11:54:23 AM) linzhi-sonia: so mid-June
(11:54:33 AM) linzhi-sonia: let's see
(11:54:48 AM) tevador: I would be susprised if CNv4 ASICs show up at all
(11:54:56 AM) tevador: surprised*
(11:54:56 AM) linzhi-sonia: why?
(11:55:02 AM) hyc: yeah should be interesting. FPGAs will be near their limits as well
(11:55:05 AM) linzhi-sonia: is only an economic question
(11:55:16 AM) tevador: unless XMR goes up a lot
(11:55:18 AM) hyc: no, not *only*. it's also a technology question
(11:55:44 AM) linzhi-sonia: you believe CNv4 is "asic resistant"? which feature?
(11:55:53 AM) sech1: it's not
(11:55:59 AM) Inge-: cnv4 = Rabdomx ?
(11:56:03 AM) hyc: no
(11:56:07 AM) hyc: cnv4=cryptinight/r
(11:56:11 AM) Inge-: ah
(11:56:27 AM) linzhi-sonia: CNv4 is the one we have now, I think
(11:56:27 AM) linzhi-sonia: since yesterday
(11:56:30 AM) tevador: it's plenty enough resistant for current XMR price
(11:56:45 AM) linzhi-sonia: that may be, yes!
(11:56:55 AM) linzhi-sonia: I look at daily payouts. XMR = ca. 100k USD / day
(11:57:02 AM) sech1: it can hold until October, but it's not asic resistant
(11:57:23 AM) linzhi-sonia: well, last 24h only 22,442 USD :)
(11:57:32 AM) sech1: I think 80 h/s per watt ASICs are possible for CNv4
(11:57:37 AM) tevador: linzhi-sonia where do you produce your chips? TSMC?
(11:57:43 AM) hyc: I'm cruious how you would expect to build a randomX ASIC that outperforms ARM cores for efficiency, or Intel cores for raw speed
(11:57:47 AM) hyc: curious
(11:58:01 AM) linzhi-sonia: yes, tsmc
(11:58:21 AM) linzhi-sonia: Our team did the world's first bitcoin asic, Avalon
(11:58:25 AM) sech1: and upcoming 2nd gen Ryzens (64-core EPYC) will be a blast at RandomX
(11:58:28 AM) linzhi-sonia: designed and manufactured
(11:58:52 AM) hyc: still being marketed?
(11:59:03 AM) Inge-: linzhi-sonia: do you understand what xmr wants to achieve, community-wise?
(11:59:14 AM) linzhi-sonia: Avalon? as part of Canaan Creative, yes I think so.
(11:59:25 AM) hyc: there's not much interesting oing on in SHA256
(11:59:29 AM) linzhi-sonia: Inge-: I would think so, but please speak
(11:59:32 AM) linzhi-sonia: hyc: yes
(12:00:28 PM) Inge-: linzhi-sonia: i am curious to hear your thoughts. I am fairly new to this space myself...
(12:00:51 PM) linzhi-sonia: oh
(12:00:56 PM) linzhi-sonia: we are grandpas, and grandmas
(12:01:35 PM) Inge-: yet I have no problem understanding why ASICS are currently reviled.
(12:01:47 PM) linzhi-sonia: xmr's main differentiators to, let's say btc, are anonymity and fungibility
(12:01:58 PM) linzhi-sonia: I find the client terribly slow btw
(12:02:21 PM) linzhi-sonia: and I think the asic-forking since last may is wrong, doesn't create value and doesn't help with the project objectives
(12:02:25 PM) hyc: which "the client" ?
(12:02:52 PM) sech1: Monero GUI client maybe
(12:03:12 PM) linzhi-sonia: MacOS, yes
(12:03:28 PM) selsta: What exactly is slow?
(12:03:30 PM) Inge-: linzhi-sonia: I run my own node, and use the CLI and Monerujo. Have not had issues.
(12:03:49 PM) linzhi-sonia: staying in sync
(12:03:49 PM) hyc: linzhi-sonia: decentralization is also a key principle
(12:03:55 PM) hyc: one that Bitcoin has failed to maintain
(12:04:39 PM) linzhi-sonia: hmm
(12:05:00 PM) linzhi-sonia: looks fairly decentralized to me. decentralization is the result of 3 goals imo: resilient, trustless, permissionless
(12:05:28 PM) linzhi-sonia: don't ask a hardware maker about physical decentralization. that's too ideological. we focus on logical decentralization.
(12:06:10 PM) hyc: physical decentralization is important. with bulk of bitnoin mining centered on Chinese hydroelectric dams
(12:06:19 PM) linzhi-sonia: have you thought about including block data in the PoW?
(12:06:40 PM) hyc: yes, of course.
(12:07:39 PM) linzhi-sonia: is that already in an algo?
(12:08:10 PM) linzhi-sonia: hyc: about "centered on chinese hydro" - what is your source? the best paper I know is this: https://coinshares.co.uk/wp-content/uploads/2018/11/Mining-Whitepaper-Final.pdf[1]
(12:09:01 PM) tevador: linzhi-sonia: do you mine on your ASICs before you sell them?
(12:09:12 PM) tevador: besides testing of course
(12:09:45 PM) linzhi-sonia: that paper puts Chinese btc miners at 60% max
(12:10:05 PM) linzhi-sonia: tevador: I think everybody learned that that is not healthy long-term!
(12:10:16 PM) linzhi-sonia: because it gives the chipmaker a cost advantage over its own customers
(12:10:33 PM) linzhi-sonia: and cost advantage leads to centralization (physical and logical)
(12:10:51 PM) linzhi-sonia: you guys should know who finances progpow and why :)
(12:11:05 PM) linzhi-sonia: but let's not get into this, ha ha. want to keep the channel civilized. right OhGodAGirl ? :)
(12:11:40 PM) linzhi-sonia: tevador: so the answer is no! 100% and definitely no
(12:11:54 PM) linzhi-sonia: that "self-mining" disease was one of the problems we have now with asics, and their bad reputation (rightfully so)
(12:13:08 PM) linzhi-sonia: I plan to write a nice short 2-page paper or so on our chip design process. maybe it's interesting to some people here.
(12:13:15 PM) linzhi-sonia: basically the 5 steps I mentioned before, from math to physical
(12:13:32 PM) hyc: linzhi-sonia: the paper you linked puts 48% of bitcoin mining in Sichuan. the total in China is much more than 60%
(12:13:38 PM) linzhi-sonia: need to run it by a few people to fix bugs, will post it here when published
(12:14:15 PM) linzhi-sonia: hyc: ok! I am just sharing the "best" document I know today. it definitely may be wrong and there may be a better one now.
(12:14:18 PM) linzhi-sonia: hyc: if you see some reports, please share
(12:14:51 PM) linzhi-sonia: hey I am really curious about this: where is a PoW algo that puts block data into the PoW?
(12:14:51 PM) hyc: the previous paper I read is from here http://hackingdistributed.com/2018/01/15/decentralization-bitcoin-ethereum/
(12:15:37 PM) linzhi-sonia: hyc: you said that already exists? (block data in PoW)
(12:15:46 PM) hyc: we discussed the possibility about a year ago https://www.reddit.com/r/Monero/comments/8bshrx/what_we_need_to_know_about_proof_of_work_pow/
(12:15:51 PM) linzhi-sonia: it would make verification harder
(12:15:51 PM) jwinterm: linzhi-sonia: https://the-eye.eu/public/Books/campdivision.com/PDF/Computers%20General/Privacy/bitcoin/meh/hashimoto.pdf[1]
(12:15:51 PM) linzhi-sonia: but for chips it would be interesting
(12:16:05 PM) linzhi-sonia: oh good links! thanks! need to read...
(12:16:06 PM) jwinterm: I think that paper by dryja was original
(12:17:52 PM) linzhi-sonia: since we have a nice flow - second question I'm very curious about: has anyone thought about in-protocol rewards for other functions?
(12:18:54 PM) hyc: we've discussed micropayments for wallets to use remote nodes
(12:18:55 PM) linzhi-sonia: you know there is a lot of work in other coins about STARK provers, zero-knowledge, etc. many of those things very compute intense, or need to be outsourced to a service (zether). For chipmakers, in-protocol rewards create an economic incentive to accelerate those things.
(12:19:50 PM) linzhi-sonia: whenever there is an in-protocol reward, you may get the power of ASICs doing something you actually want to happen
(12:19:52 PM) hyc: it would be nice if there was some economic reward for running a fullnode, but no one has come up with much more than that afaik
(12:19:54 PM) linzhi-sonia: instead of fighting them off
(12:20:29 PM) linzhi-sonia: you need to use asics, not fight them. that's an obvious thing to say for an asicmaker...
(12:20:40 PM) linzhi-sonia: in-protocol rewards can be very powerful
(12:20:50 PM) hyc: like I said before - unless the ASICs are so useful they're embedded in every smartphone, I dont see them being a positive for decentralization
(12:21:17 PM) hyc: if they're a separate product, the average consumer is not going to buy them
(12:21:19 PM) linzhi-sonia: now I was talking about speedup of verifying, signing, proving, etc.
(12:21:23 PM) hyc: they won't even know what they are
(12:23:00 PM) linzhi-sonia: if anybody wants to talk about or design in-protocol rewards, please come talk to us
(12:23:00 PM) jwinterm: the average consumer also doesn't use general purpose hardware to secure blockchains either
(12:23:00 PM) linzhi-sonia: not just for PoW, in fact *NOT* for PoW
(12:23:00 PM) linzhi-sonia: it requires sw/hw co-design
(12:23:10 PM) linzhi-sonia: we are in long-term discussions/collaboration over this with Ethereum, Bitcoin Cash. just talk right now.
(12:23:17 PM) jwinterm: this was recently published though suggesting more uptake though I guess https://btcmanager.com/college-students-are-the-second-biggest-miners-of-cryptocurrency/[1]
(12:23:29 PM) jwinterm: I find it pretty hard to believe their numbers
(12:24:02 PM) linzhi-sonia: well
(12:24:09 PM) jwinterm: sorry, original article: https://www.pcmag.com/news/366952/college-kids-are-using-campus-electricity-to-mine-crypto[1]
(12:24:11 PM) linzhi-sonia: just talk, no? rumors
(12:24:18 PM) hyc: college students are already more educated than the average consumer
(12:24:28 PM) linzhi-sonia: we are not seeing many such customers anymore
(12:24:30 PM) hyc: and they're always looking for free money
(12:24:33 PM) jwinterm: it's data from cisco monitoring network traffic
(12:24:48 PM) linzhi-sonia: of course anyone with "free" electricity is inclined to do it
(12:24:57 PM) linzhi-sonia: but look at the rates, cannot make much money
(12:26:05 PM) hyc: Ethereum is a bloated collection of bugs wrapped in a UI. I suppose they need all the help they can get
(12:26:29 PM) hyc: Bitcoin Cash ... just another get rich quick scheme
(12:26:38 PM) linzhi-sonia: hmm :)
(12:26:51 PM) linzhi-sonia: I'll give it back to you, ok? ha ha. arrogance comes before the fall...
(12:27:13 PM) hyc: ;)
(12:27:17 PM) linzhi-sonia: maye we should have a little fun with CNv4 mining :)
(12:27:38 PM) hyc: come on. anyone who has watched their track record... $75M lost in ETH at DAO hack
(12:27:49 PM) hyc: every smart contract that comes along is just waiting for another hack
(12:27:57 PM) linzhi-sonia: I just wanted to throw out the "in-protocol reward" thing, maybe someone sees the idea and wants to cowork. maybe not. maybe it's a stupid idea.
(12:29:18 PM) Inge-: linzhi-sonia: any thoughts on CN-GPU?
(12:29:55 PM) hyc: CN-GPU has one positive aspect - it wastes chip area to implement all 18 hash algorithms
(12:30:19 PM) linzhi-sonia: you will always hear roughly the same feedback from me:
(12:30:51 PM) linzhi-sonia: "This algorithm very different, it heavy use floating point operations to hurt FPGAs and general purpose CPUs"
(12:30:57 PM) tevador: the problem is, if it's profitable for people to buy ASIC miners and mine, it's always more profitable for the manufacturer to not sell and mine themselves
(12:31:01 PM) linzhi-sonia: "hurt"
(12:31:07 PM) linzhi-sonia: what is the point of this?
(12:31:15 PM) linzhi-sonia: it totally doesn't work
(12:31:24 PM) linzhi-sonia: you are hurting noone, just demonstrating lack of ability to think
(12:31:40 PM) linzhi-sonia: what is better: algo designed for chip, or chip designed for algo?
(12:31:43 PM) sech1: fireice does it on daily basis, CN-GPU is a joke
(12:31:53 PM) jwinterm: tevador: that's not really true, especially in a market with such large price fluctuations as cryptocurrency
(12:32:12 PM) jwinterm: it's far less risky to sell miners than mine with them and pray that price doesn't crash for next six months
(12:32:14 PM) linzhi-sonia: I think it's great that crypto has a nice group of asicmakers now, hw & sw will cowork well
(12:32:35 PM) tevador: jwinterm yes, that's why they premine them and sell after
(12:32:41 PM) linzhi-sonia: PoW is about being thermodynamically and cryptographically provable
(12:32:45 PM) jwinterm: premining with them is taking on that risk
(12:32:49 PM) linzhi-sonia: not "fork when we think there are asics"
(12:32:52 PM) jwinterm: business is about risk minimization
(12:32:54 PM) linzhi-sonia: that's just fear-driven
(12:33:05 PM) linzhi-sonia: Inge-: that's roughly the feedback
(12:33:24 PM) jwinterm: I'm not saying it hasn't happened, but I think it's not so simple as saying "it always happens"
(12:33:59 PM) hyc: jwinterm: it has certainly happened on BTC. and also on XMR.
(12:34:19 PM) linzhi-sonia: ironically, please think about it: these kinds of algos indeed prove the limits of the chips they were designed for. but they don't prove that you cannot implement the same algo differently! cannot!
(12:34:26 PM) moneromooo: Risk minimization is not starting a business at all.
(12:34:34 PM) linzhi-sonia: proof-of-gpu-limit. proof-of-cpu-limit.
(12:34:37 PM) tevador: imagine you have a money printing machine, would you sell it?
(12:34:47 PM) linzhi-sonia: proves nothing for an ASIC :)
(12:35:05 PM) Inge-: linzhi-sonia: thanks. I dont think anyone believes you can't make a more efficient cn-gpu asic than a gpu - but that it would not be orders of magnitude faster...
(12:35:24 PM) linzhi-sonia: ok
(12:35:44 PM) linzhi-sonia: like I say. these algos are, that's really ironic, designed to prove the limitatios of a particular chip in mind of the designer
(12:35:50 PM) linzhi-sonia: exactly the wrong way round :)
(12:36:16 PM) linzhi-sonia: like the cache size in RandomX :)
(12:36:18 PM) linzhi-sonia: beautiful
(12:36:29 PM) linzhi-sonia: someone looked at GPU designs
(12:37:30 PM) tevador: linzhi-sonia can you elaborate? Cache size in RandomX was selected to fit CPU cache
(12:38:29 PM) linzhi-sonia: yes
(12:38:29 PM) linzhi-sonia: too large for GPU
(12:38:29 PM) tevador: as I said, we are designing the algorithm to exactly fit CPU capabilities, I do not claim an ASIC cannot be more efficient
(12:38:29 PM) linzhi-sonia: ok!
(12:38:29 PM) linzhi-sonia: when will you do the audit?
(12:38:35 PM) linzhi-sonia: will the results be published in a document or so?
(12:38:37 PM) tevador: I claim that single-chip ASIC is not viable, though
(12:39:06 PM) linzhi-sonia: you guys are brave, noone disputes that. 3 anti-asic hardforks now!
(12:39:18 PM) linzhi-sonia: 4th one coming
(12:39:31 PM) sech1: 3 forks were done not only for this
(12:39:38 PM) sech1: they had scheduled updates in the first place
(12:48:10 PM) linzhi-sonia: Monero is the #1 anti-asic fighter
(12:48:25 PM) hyc: Monero is #1 for a lot of reasons ;)
(12:48:40 PM) moneromooo: It's the coin with the most hycs.
(12:48:55 PM) hyc: mooooo
(12:59:06 PM) tevador: sneaky integer overflow, bug squished
(01:38:00 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:10:53 PM) midipoet: The convo here is wild
(02:12:29 PM) midipoet: it's like geo-politics at the intersection of software and hardware manufacturing for thermoeconomic value. 
(02:13:05 PM) midipoet: ..and on a Sunday.
(02:15:43 PM) linzhi-sonia: midipoet: hw and sw should work together and stop silly games to devalue each other. to outsiders this is totally not attractive.
(02:16:07 PM) linzhi-sonia: I appreciate the positive energy here to try to listen, learn, understand.
(02:16:10 PM) linzhi-sonia: that's a start
(02:16:48 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(02:16:54 PM) linzhi-sonia: we won't do silly mining against xmr "community" wishes, but not because we couldn'd do it, but because it's the wrong direction in the long run, for both sides
(02:18:57 PM) midipoet: linzhi-sonia: I agree to some extent. Though, in reality, there will always be divergence between social worlds. Not every body has the same vision of the future. Reaching societal consensus on reality tomorrow is not always easy
(02:20:25 PM) linzhi-sonia: absolutely. especially at a time when there is so much profit to be made from divisiveness.
(02:20:37 PM) linzhi-sonia: someone will want to make that profit, for sure
(02:24:32 PM) midipoet: Yes. Money distorts. 
(02:24:47 PM) midipoet: Or wealth...one of the two
(02:26:35 PM) moneromooo: Too much physical money will distort rays of light passing close to it indeed.
(02:40:25 PM) needmoney90: Technically it distorts the spacetime, the rays are moving perfectly straight
(02:40:34 PM) needmoney90: Just to be pedantic
(02:42:32 PM) midipoet: pucker up, we have a pedant in the house. ;-)
(02:51:42 PM) moneromooo: Well well well, I'll agree to that correction :)
(02:56:12 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(03:48:16 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(04:17:39 PM) hyc: all software engineers should be pedants. the computers executing their code always are.
(04:18:21 PM) moneromooo: Somehow this reminds me of LAIDBACK, the computer language.
(04:18:52 PM) moneromooo: Well, it IS pedantic in a way.
(04:40:43 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(04:50:50 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:52:29 PM) cryptodonkey [~cryptodon@yunohost-arm64-6c.11c8.cloud] entered the room.
(05:21:13 PM) linzhi-sonia: hyc: hey, ha ha. you have a chipmaker in the group now. Need to object. You are assuming the typical digital environments. But in hardware, there are approximate adders, they are fun. 5% error rate, but 20% performance gain.
(05:21:28 PM) linzhi-sonia: there is an entire computing area called "approximate computing" https://en.wikipedia.org/wiki/Approximate_computing[1]
(05:21:57 PM) linzhi-sonia: Google is using that in their very successful TPUs, and this approach certainly has a bright future, for many data loads. It's not "pedantic" at all.
(05:22:00 PM) moneromooo: Yeah, Intel went into it at some point.
(05:22:03 PM) ***moneromooo flees
(05:22:37 PM) linzhi-sonia: I'm giving you guys serious feedback. Overlooking these things is the typical reason why noone can imagine a 5x, 8x, 10x for algo a, b, c.
(05:23:11 PM) linzhi-sonia: if you have an approximate adder, a normal programming language won't work, unless you vertically integrate it all the way through compiler etc. approx int a;
(05:23:22 PM) linzhi-sonia: but 5% error rate for 20% performance gain is sweet
(05:24:22 PM) linzhi-sonia: when you have a video, you first have complicated math to compress it, then you send it digitally (no-loss), then decompress it again. Kinda makes no sense.
(05:24:46 PM) linzhi-sonia: everything could be lossy, the human eye is also not pedantic
(05:26:00 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963::c] entered the room.
(05:26:40 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:27:18 PM) tevador: PoW algorithm must be approximation-free, so this must be considered when designing one
(05:28:31 PM) tevador: but an adder with a 5% error rate would not work in RandomX because this error rate would compound to something like 99.9999999...%
(05:29:06 PM) moneromooo: It does not have to be used for *all* additions.
(05:32:04 PM) tevador: if you use it just for ONE addition, you will get 5% incorrect hashes, but the speed-up will be ~0 since there are ~4 million operations per hash
(05:32:11 PM) tromp [~tromp@ip-217-103-3-94.ip.prioritytelecom.net] entered the room.
(05:32:34 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:33:03 PM) moneromooo: Alright then ^_^
(05:34:38 PM) tevador: but we had to solve something similar which we called the 'easy nonce problem'
(05:35:00 PM) tevador: when an ASIC skips nonces that produce 'hard' programs for some definition of hard
(05:35:22 PM) tevador: this can give an advantage in some cases
(06:16:25 PM) tevador: configurable parameters of RandomX: https://github.com/tevador/RandomX/blob/dev/src/configuration.h[1]
(07:23:56 PM) vp11 [curumim@gateway/shell/elitebnc/x-zmogwvothdjlsgtj] entered the room.
(07:45:14 PM) sech1 left the room (quit: Quit: Leaving).
(08:00:36 PM) tromp left the room (quit: Remote host closed the connection).
(08:18:23 PM) rottensox_ [~rottensox@unaffiliated/rottensox] entered the room.
(08:21:09 PM) rottensox left the room (quit: Ping timeout: 252 seconds).
(09:02:35 PM) xnbya [~quassel@159.69.201.208] entered the room.
(09:16:58 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:56:23 PM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(09:57:42 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(11:18:24 PM) rottensox_ is now known as rottensox
(11:44:52 PM) gingeropolous: man, it'd be interesting to experiment with a difficulty adjustment that changes the frequencies of the instructions. So the algorithm could go through an evolutionary process on its own and balance out any optimizations that may have occurred in the real world
(11:49:30 PM) Axam [~textual@om126237116000.9.openmobile.ne.jp] entered the room.
(11:49:57 PM) gingeropolous: e.g., a (possibly wrong) interpretation of the instruction frequency list in configuration.h would suggest that if you made an asic that optimized RANDOMX_FREQ_FADD_R, RANDOMX_FREQ_FSUB_R , RANDOMX_FREQ_FMUL_R , RANDOMX_FREQ_IADD_RC, RANDOMX_FREQ_IMUL_R , RANDOMX_FREQ_IXOR_R , RANDOMX_FREQ_ISTORE , you've got 48% of the PoW optimized
(11:50:45 PM) gingeropolous: and this is just the blue sky of yes, an asic could do this efficiently, and couple it with a cheap ARM chip to do the rest or whatever and it would still somehow be cheap
(11:52:31 PM) gingeropolous: so, instead of simply adjusting difficulty with changes in the leading 0s or whatever of the digest, the algo could also start changing the frequencies.....
(11:53:18 PM) gingeropolous: ... another idea dead in the water would be to allow blockheaders to signal new functions , but the asics would just vote for their functions, so...
(11:54:02 PM) Axam left the room (quit: ).
(11:54:23 PM) Axam [~Axam@om126237116000.9.openmobile.ne.jp] entered the room.
(11:54:41 PM) gingeropolous: going back to the first one, all of the general purpose HW on the network would be more-or-less equal in their processing of the shift in functinos
(11:54:44 PM) gingeropolous: but the asics wouldn't
(11:56:26 PM) Axam left the room (quit: Client Quit).
(12:09:19 AM) lafudoci [~lafudoci@122-116-59-198.HINET-IP.hinet.net] entered the room.
(12:09:22 AM) Axam [~Axam@om126237116000.9.openmobile.ne.jp] entered the room.
(12:12:29 AM) dossier [49e955be@gateway/web/cgi-irc/kiwiirc.com/ip.73.233.85.190] entered the room.
(12:17:53 AM) Axam left the room.
(12:18:12 AM) Axam [~Axam@om126237116000.9.openmobile.ne.jp] entered the room.
(12:18:22 AM) Axam left the room.
(12:22:27 AM) dossier is now known as newnick
(12:22:37 AM) newnick is now known as dossier
(12:30:59 AM) Axam [~Axam@unaffiliated/axam] entered the room.
(12:32:56 AM) Axam left the room (quit: Client Quit).
(12:34:56 AM) Axam [~Axam@unaffiliated/axam] entered the room.
(12:53:03 AM) ferretinjapan [~ferretinj@unaffiliated/ferretinjapan] entered the room.
(01:11:25 AM) Axam left the room (quit: Ping timeout: 255 seconds).
(01:55:00 AM) rottensox left the room (quit: Quit: Leaving).
(02:05:08 AM) infinitejest_ [sid203393@gateway/web/irccloud.com/x-ebgzsdisxsgfdpgx] entered the room.
(02:29:08 AM) tevador: gingeropolous those instructions you listed are already optimized single-instruction operations on a CPU
(02:29:27 AM) gk_ [7aae6dd4@gateway/web/freenode/ip.122.174.109.212] entered the room.
(02:30:34 AM) gk_ left the room.
(02:47:43 AM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(02:49:15 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:23:39 AM) sech1 left the room (quit: Quit: Leaving).
(03:33:36 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:47:41 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(03:54:40 AM) scoobybejesus left the room (quit: Ping timeout: 264 seconds).
(03:54:46 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(03:54:59 AM) scoobybejesus [sid271506@gateway/web/irccloud.com/x-mabzcsclyszocmft] entered the room.
(04:01:31 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:18:22 AM) midipoet [uid316937@gateway/web/irccloud.com/x-lexceuobsbafaggn] entered the room.
(04:26:47 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(04:28:23 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:55:16 AM) linzhi-sonia: in the context of PoW, your job as software engineer is a bit different from normal. It's not to squeeze out the most performance from a chip, by understanding the chip design and then programming it for maximum results.
(06:55:44 AM) linzhi-sonia: it's to anticipate whether there is some OTHER way the machine (chip) can be built. other = unknown
(06:56:48 AM) linzhi-sonia: the chip that is "executing" your instructions is itself a machine that was designed with certain design criteria in the minds of its designers
(06:57:08 AM) linzhi-sonia: we put together a nice short article here, maybe it helps: https://medium.com/@Linzhi/studying-the-feasibility-of-an-asic-82634ac77d61[1]
(07:26:03 AM) Paddy [a7622342@gateway/web/freenode/ip.167.98.35.66] entered the room.
(07:26:48 AM) crCr62U0: Have you started as a software or hardware engineer?
(07:26:51 AM) thrmo [~thrmo@unaffiliated/thrmo] entered the room.
(07:31:01 AM) crCr62U0: I'm interested in amount of time I(or someone else) should spend in order to balance my(or his) exprience in hardware and software to the same level.
(07:37:32 AM) Paddy left the room (quit: Quit: Page closed).
(07:39:35 AM) crCr62U0: I'm reading that article now.
(07:50:26 AM) gingeropolous: tevador, right. But right now a certain number of them have paramters indicating that they run 20/256 slots in a randomx program, whereas others run 1/256 slots. 
(09:51:37 AM) spaced0ut left the room (quit: Ping timeout: 255 seconds).
(10:57:07 AM) camthegeek [~ctg@community.of.aeonminingpool.com] entered the room.
(11:23:14 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(11:24:37 AM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(11:48:45 AM) parasew[m] left the room (quit: Quit: User has been idle for 30+ days.).
(12:03:46 PM) sech1 left the room (quit: Quit: Leaving).
(12:10:13 PM) gingeropolous: so M5M400 made an interesting observation
(12:10:18 PM) gingeropolous: this miner, https://xmr.waterhole.io/miner/44USZoqYWurRGHXsXAKvvgeuxp2qKxLRr4TYdjdwAhYJU1KQvgcc3SdG8nNMdygkyx87Zawu6Ki7SQ7oV2jZaNkbSdU6GZJ[1]
(12:11:10 PM) gingeropolous: has a boatload of works that look to be GPU rigs. But m5m400 claims that when he checked out this website yesterday (sunday), the history of each work showed that the hashrate was 50 kh/s before the fork
(12:11:23 PM) gingeropolous: unfortunately those charts aren't available anymore afaict
(12:11:36 PM) gingeropolous: but is that the expected dropoff for an FPGA if it was mining CNv2 and then CNv4?
(12:13:16 PM) gingeropolous: 50 kh/s to ~10 kh/s ?
(12:13:45 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:17:04 PM) sech1: I saw it too
(12:17:12 PM) sech1: they were 50 kh/s, now 10-12 kh/s
(12:17:42 PM) sech1: But it doesn't mean it's the same devices
(12:17:52 PM) sech1: Might have been 10-12 kh/s GPU + 40 kh/s FPGA
(12:17:56 PM) sech1: and 40 kh/s dropped
(12:19:16 PM) sech1: or even 50 kh/s FPGA whic was then replaced with regular GPU rigs
(12:20:45 PM) sech1: and I doubt FPGA could've done 50 kh/s on CNv2 at all
(12:20:54 PM) sech1: It might have been some ASICs
(12:25:14 PM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-kdthjkuwfcdlmlsj] entered the room.
(12:31:24 PM) gingeropolous: on the same worker?
(12:32:42 PM) gingeropolous: a worker ID is usually given to a particular rig. I find it hard to believe they would deal with the hassle of connecting 4-13 GPUs (depending on type) to a single mobo and either an ASIC or FPGA
(12:33:21 PM) gingeropolous: that address has 667 workers
(12:34:04 PM) sech1: wokrer ID comes from JSON sent to the pool
(12:34:10 PM) sech1: they could just reuse existing IDs
(12:35:28 PM) sech1: maybe these are FPGA rigs indeed
(12:35:34 PM) gingeropolous: right. im just saying, modding hardware of 667 workers is gonna take some time. 
(12:35:42 PM) sech1: but not single FPGA, probably 12 FPGA rigs
(12:35:49 PM) gingeropolous: timeframe of just swapping a bitstream seems more feasible
(12:35:53 PM) sech1: they became 5 times slower then
(12:41:34 PM) sech1: waterhole.io went down from 77 MH/s to 14 MH/s
(12:41:36 PM) sech1: 5.5 times even
(12:41:46 PM) sech1: assuming the whole pool runs these FPGAs
(12:45:34 PM) sech1: or maybe not even FPGAs but some programmable ASICs
(01:29:50 PM) xnbya: I'm pretty sure those are the same workers
(01:30:01 PM) xnbya: they were gradually switched on after the fork
(01:30:34 PM) xnbya: some fpga / asic hybrid or pure fpga perhaps
(01:32:11 PM) sech1: maybe it was those "Achronix Speedcore Embedded
(01:32:11 PM) sech1: FPGAs"
(01:33:11 PM) sech1: https://www.achronix.com/wp-content/uploads/2019/01/Mine_Cryptocurrencies_Sooner_Faster_and_Cheaper_with_Achronix_Speedcore_Embedded_FPGAs_WP014.pdf[1]
(01:35:27 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(01:37:43 PM) gingeropolous: jesus monekybut the proliferation of the incorrect PoW variant names is astounding
(01:59:37 PM) fort3hlulz left the room (quit: Quit: Leaving).
(02:14:48 PM) thrmo left the room (quit: Quit: Leaving).
(02:37:52 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:59:51 PM) crCr62U0: sech1: The final aim of the next PoW is to have the fastest hardware to compute PoW equals to Intel, AMD and ARM CPUs?
(03:00:10 PM) crCr62U0: *is to have the following: the fastest ...
(03:01:33 PM) xnbya: 10kh fpga turned up on nanopool now too 
(03:01:36 PM) xnbya: https://xmr.nanopool.org/account/41dTCvw1zUWXUBoABXT7PjiZVEufPnHnQgcByJaoeCTEMaiorjKcFq9Z4wXqw3YERbRA1KitopxEhL9gc4U5JoAPUM7rQXY[1]
(03:01:45 PM) sech1: yes, but ASICs can still be 2x faster even on RandomX, but R&D costs for such ASICs would be huge
(03:02:05 PM) sech1: xnbya it's GPU farm
(03:02:43 PM) sech1: 1000 rigs, 12xRX580 each
(03:02:48 PM) sech1: or 6xVega
(03:04:01 PM) xnbya: possibly
(03:04:22 PM) moneromooo: It's hyc's phone.
(03:05:22 PM) crCr62U0: xnbya: Can you write data collector to save info from public pools api in order to have this dataset before the next hardfork?
(03:06:30 PM) xnbya: yeah will do when i get the time, only a few pools publish them, would still be usefull i guess
(03:07:17 PM) crCr62U0: One pool have all api calls here: https://xmr.waterhole.io/js/xmr_pool.js[1]
(03:14:15 PM) crCr62U0: The only realtime stat I have is this image: https://minexmr.com/big.png
(03:14:29 PM) crCr62U0: Do you any other source of realtime stats among public pools?
(03:14:34 PM) crCr62U0: *Do you have
(03:15:34 PM) xnbya: thats the only one that i currenlt publish
(03:15:51 PM) xnbya: https://miningpoolstats.stream/monero[1] has more pools usually
(03:18:32 PM) gingeropolous: sech1, how do u know FPGA? did its history indicate was 50 kh before?
(03:19:42 PM) gingeropolous: oh sorry, xnbya posted that
(03:21:03 PM) hyc: my phone has only 8 cores. but my AMlogic S912 cluster would be 80 cores ;)
(03:21:28 PM) gingeropolous: thats prolly an eth miner switching over
(03:22:45 PM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(03:22:47 PM) xnbya: gingeropolous, i don't know the history on that address. could well be a gpu.
(03:35:39 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(03:37:56 PM) tevador: gingeropolous: I meant that the high frequency instructions are already optimally implemented by CPUs, not much to gain by ASIC optimization
(04:09:04 PM) ArticMine: linzhi-sonia What are our thoughts on GPLv3 code and ASICS. There is some very interesting discussion on the legal issues including links to ORCONF 2015 in this thread  https://opencores.org/forum/Other/0/3533[1] 
(04:10:38 PM) ArticMine: One interesting aspect is the interaction of proprietary HDL code used in the manufacture of the ASIC with the GPLv3 code.
(04:11:07 PM) ArticMine: your thoughts?
(04:12:07 PM) ArticMine: By the way I actually bought two Bitcoin ASICS from Avalon in 2013
(04:23:54 PM) linzhi-sonia: ArticMine: happy to hear that! We earned a good reputation because we actually shipped to the people who ordered in the right order, didn't play many games that others were playing. Pretty much all of our customers from 2013 were very happy :) Hope you too!
(04:24:15 PM) linzhi-sonia: the question about GPL and ASICs is a very good one, give me a little time to look into this and talk to a few people
(04:24:23 PM) linzhi-sonia: thanks for the link!
(04:34:44 PM) ArticMine: I was actually very pleased with the service from Avalon. 
(05:00:51 PM) rottensox left the room (quit: Ping timeout: 252 seconds).
(05:18:01 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(05:27:53 PM) tevador: fireice is again pushing cn-gpu...
(05:28:10 PM) tevador: https://github.com/monero-project/meta/issues/315#issuecomment-471725939[1]
(05:29:11 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1004::9e] entered the room.
(05:32:43 PM) sech1: CN-GPU is crap
(05:32:48 PM) sech1: you can tell it to fireice
(05:33:02 PM) sech1: or better I'll tell it to him if he shows up there
(06:04:07 PM) crCr62U0 left the room (quit: Quit: leaving).
(06:08:10 PM) tevador: btw someone should keep an eye on the nonce distribution
(06:31:20 PM) tevador: so apparently, RandomX will require significant pool code changes
(06:31:23 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:37:27 PM) crCr62U0: linzhi-sonia: Are you still here?
(06:37:32 PM) crCr62U0: I've spent some time to read details about approximate adders.
(06:37:33 PM) crCr62U0: Do you remember at least one algorithm that can be implemented with both precise and imprecise adders without any changes?
(06:39:07 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(06:42:33 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1004::9e] entered the room.
(07:01:16 PM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(07:04:38 PM) sech1 left the room (quit: Ping timeout: 245 seconds).
(07:09:20 PM) vp11: tevador: let he push it, if there are actual technical arguments against the use of cn-gpu then people can state those in a polite way
(07:17:47 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(07:25:16 PM) camthegeek:  m  
(07:31:53 PM) needmoney90: o
(07:33:07 PM) crCr62U0: nero?
(07:33:29 PM) needmoney90: :(
(08:08:06 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(08:21:31 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963::a] entered the room.
(08:28:01 PM) camthegeek: headset landed on my laptop. nice cover for me though guys ;) 
(08:37:34 PM) sech11 left the room (quit: Quit: Leaving).
(09:17:54 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:01:41 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1004::9e] entered the room.
(10:06:55 PM) fort3hlulz_ [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(10:06:55 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(10:33:51 PM) hyc: vp11 it's been covered to death already. cn-gpu is uttter trash. pure ignorance.
(10:50:39 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(10:51:24 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(10:56:49 PM) fort3hlulz_ left the room (quit: Quit: Leaving).
(11:29:35 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:32:56 PM) hyc: lot of fun reading on this site if you want to get an idea of ASIC design https://anysilicon.com/what-is-an-asic-and-how-it-is-being-made/
(01:46:59 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:00:59 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:03:20 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(02:03:46 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(02:03:47 AM) moneromooo left the room (quit: Ping timeout: 240 seconds).
(02:04:27 AM) wowario left the room (quit: Ping timeout: 256 seconds).
(02:06:18 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(02:07:21 AM) ArticMine left the room (quit: Ping timeout: 246 seconds).
(02:08:44 AM) Guest35498 [fluffypony@primary.spagni.net] entered the room.
(02:14:35 AM) ArticMine [~ArticMine@S0106ac202ecaeb73.vn.shawcable.net] entered the room.
(02:39:57 AM) tevador: vp11: it has been discussed on github already; main issues: compute bound algorithm (= ASIC friendly), very slow verification (100+ ms)
(03:20:21 AM) spaced0ut left the room (quit: Ping timeout: 246 seconds).
(03:23:48 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(03:51:52 AM) midipoet [uid316937@gateway/web/irccloud.com/x-vqovdgczdhnjeuxz] entered the room.
(04:02:33 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:04:08 AM) sech1 left the room (quit: Quit: Leaving).
(04:16:31 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(06:08:20 AM) Guest35498 left the room (quit: Changing host).
(06:08:20 AM) Guest35498 [fluffypony@unaffiliated/moneromooo] entered the room.
(06:08:26 AM) Guest35498 is now known as moneromooo
(08:03:08 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(08:42:30 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(09:06:21 AM) spaced0ut_ [~spaced0ut@198.211.112.88] entered the room.
(09:09:20 AM) spaced0ut_ left the room (quit: Client Quit).
(09:15:55 AM) linzhi-sonia: crCr62U0: apologies, was too late. yes I'm here but there are a lot of channels recently and a bit overloaded.
(09:16:36 AM) linzhi-sonia: I use the 'approximate computing' as a first reference analogy, in general. one could also point to analog, optical, or even the much talked about quantum computing.
(09:17:08 AM) linzhi-sonia: we can say there are two ways to start with 'approximation', one is over the safety margin, one logically
(09:17:54 AM) linzhi-sonia: for safety margin, normal circuits are designed with >6 sigma margin. high-reliability devices need extra error correction or redundancy.
(09:18:19 AM) linzhi-sonia: for miner, we can design with 3 sigma
(09:18:42 AM) linzhi-sonia: that will provide a significant power/performance/cost advantage, more than 10%
(09:20:47 AM) linzhi-sonia: for the logic way, let's take a 32-bit adder. slowest part is the carry chain. if you spread the carry bit from 0 to 31, it will be very slow, and limit peak performance. but maybe we can give up the long carry chain. it may generate some wrong results in some input combinations, but if the ratio is well controlled, for example 1e-10 or 1e-8, depending on algo, it may not have much impact on the hashrate, but it can make a circuit much smaller a
(09:21:23 AM) linzhi-sonia: it's not an exact answer to your question, but an example of how approximation can be introduced physically
(09:22:06 AM) linzhi-sonia: the TPU is a really good example of a recent exciting new chip design and architecture. from all that is known, they use a lot of approximation, and they use well known but rarely used designs like systolic arrays.
(09:23:07 AM) linzhi-sonia: and Google set this up really well with Tensorflow, a toolchain that allows for the ongoing competition between different chips. that's the way to go. We can mimick that in crypto if we are smart with the software stack. competition between different chip architectures is what drives everybody forward.
(09:36:39 AM) hyc: the TPU is an example of a niche case where fuzzy logic is being used
(09:36:52 AM) hyc: nobody is doing fuzzy logic in cryptography
(09:38:09 AM) sech1: Each RandomX hash runs 2^22 instructions, one bit error in any of them results in invalid hash. So I guess > 6 sigma will still be required
(09:39:00 AM) moneromooo: What scope is there to reduce these iterations for a faster hash ? Is it too close to the threshold where one could find preimages or other ?
(09:48:46 AM) hyc: the hash is already faster than any CN variant. what are you aiming for?
(09:49:10 AM) sgp_: vp11: fireice_uk created an issue for it that received some good criticisms, I recommend starting there
(09:50:00 AM) moneromooo: Something that's faster even without gobs of RAM.
(09:51:46 AM) sech1: It's not possible to reduce iterations because even now only 67% (or so?) of 2 MB scratchpad is touched on average
(09:53:50 AM) vp11: thanks sgp_, i read about the algorithm and a few comments from some mining software developers. my previous message was more in the direction of allowing an open space in which he can communicate what he wants, even if it is quickly refuted.
(09:55:46 AM) sgp_: I think we're mostly past that stage, but let us know if there's something else you're expecting
(09:58:40 AM) hyc: anyone who knows how hardware works is way past the stage of listening to fireice 
(10:09:46 AM) vp11: can we not pre-commit to embrace ASICs in 2 years before actual testing of RandomX? is this a reasonable demand?
(10:13:20 AM) fort3hlulz: For a move to ASIC-support to EVER work and be mildly decentralized, it has to be announced WELL in advance to give every ASIC manufacturer time to prepare
(10:13:41 AM) sech1: Like 4 months in advance? :D
(10:13:48 AM) sech1: They proved that 4 months is enough
(10:13:52 AM) fort3hlulz: It can't be a "we tried ASIC resistance and it didn't work, so now we're ASIC-friendly"
(10:14:14 AM) fort3hlulz: It needs to be enough time for any mft to tape out and build ASICs, as well as ship them
(10:14:26 AM) fort3hlulz: 4mo is too short IMO
(10:14:44 AM) fort3hlulz: That would let one or two who are secretly mining to get to market MAYBE
(10:14:48 AM) fort3hlulz: But not the smaller/other mfr
(10:15:05 AM) fort3hlulz: The longer the better IMO
(10:15:26 AM) hyc: 4 months gets them running, but not shipped to consumers' hands
(10:15:26 AM) fort3hlulz: I'm one of the very few who think we should move to ASICs sooner rather than later
(10:15:32 AM) fort3hlulz: Yeah exactly
(10:15:38 AM) fort3hlulz: I would think 1yr+
(10:15:51 AM) hyc: but the evidence so far is that they don't care about getting into consumer's hands
(10:15:57 AM) fort3hlulz: 6mo for proper dev, 6mo for stock/ship/setup
(10:16:11 AM) fort3hlulz: Well they never will care as long as we commit to forking every 6mo
(10:16:15 AM) fort3hlulz: They would never be profitable
(10:16:22 AM) fort3hlulz: Its a cycle that feeds into itself
(10:16:35 AM) fort3hlulz: We fork, they rebuild, mine for a couple months, start over
(10:16:40 AM) moneromooo: I think the one thing that'll make them ship to customers if not having a better "next gen". Then adding more does not add to profits, but selling does.
(10:16:51 AM) fort3hlulz: The only way to incentivize them to sell is if it is going to be the supported algo well in advance
(10:16:53 AM) hyc: you just described a 1 year product cycle, when a company can obsolete their own product in only 4 momths
(10:17:01 AM) moneromooo: So in that view, stoffu's point about as simple as possible is valid.
(10:17:06 AM) hyc: who is going to want to buy these things that have been sitting on stock shelves for 6 months?
(10:17:19 AM) fort3hlulz: Idk the exact time frame
(10:17:20 AM) moneromooo: But assuming this is going to be hte case is reckless.
(10:17:23 AM) fort3hlulz: Maybe 6mo is good
(10:17:28 AM) fort3hlulz: Im no expert :)
(10:17:48 AM) fort3hlulz: But it needs to be enough time for multiple mfr to properly develop and deliver
(10:17:58 AM) fort3hlulz: So I can buy some ASICs and have them ready to mine at that HF
(10:18:02 AM) moneromooo: (without actual evidence of course, if you do have such evidence it becomes much more palatable)
(10:18:49 AM) fort3hlulz: moneromooo: So in that view, stoffu's point about as simple as possible is valid. <-- what point? must have missed it, can't find in scrollback
(10:18:56 AM) hyc: I don't believe this is a case where the software project should lead the hardware project.
(10:19:17 AM) hyc: IMO the hardware side should develop a useful chip that everyone wants to buy. and then we adopt it.
(10:19:43 AM) fort3hlulz: But as long as we commit to fucking their hw every ~6mo, no company in their right mind will build a consumer product
(10:19:51 AM) moneromooo: The point that using as simple a PoW as possible will cause everyone to hit "final" physical barriers faster, so people with an advantage can't keep it.
(10:19:53 AM) fort3hlulz: They would never be profitable
(10:20:12 AM) hyc: that's not true fort3hlulz: they are building ASICs for other coins in the meantime
(10:20:14 AM) fort3hlulz: moneromooo, yeah, I agree, matches the current Bitcoin mining narrative
(10:20:20 AM) fort3hlulz: They're already hitting efficiency walls
(10:20:36 AM) hyc: IMO the burden is on existing ASIC companies to prove they can create a fair and open marketplace
(10:20:40 AM) fort3hlulz: hyc, Yeah but why build one for Monero if we make them paperweights by design?
(10:20:57 AM) hyc: expecting that to just appear out of nowhere when we declare monero is ASIC-friendly is ridiculously naive
(10:21:15 AM) hyc: fort3hlulz: they don't have to build one jst for monero, at the outset. re-read what I wrote.
(10:21:15 AM) fort3hlulz: I just don't see a company moving the playing field when we are committed to ruining their business model
(10:21:34 AM) fort3hlulz: If we make it clear we will change at a given point, then there will be a race to build Monero ASICs from all the major players
(10:21:48 AM) hyc: there is already a race. that's not helpful.
(10:21:55 AM) fort3hlulz: I know they will have ASICs for BTC etc.
(10:22:08 AM) fort3hlulz: But why would they diversify into Monero without a clear roadmap to ASIC support?
(10:22:16 AM) hyc: (10:19:17) hyc: IMO the hardware side should develop a useful chip that everyone wants to buy. and then we adopt it.
(10:22:19 AM) fort3hlulz: Seems WAY too high of risk/reward to me
(10:22:28 AM) fort3hlulz: But why would they do that, hyc ?
(10:22:33 AM) fort3hlulz: Given Monero
(10:22:41 AM) hyc: because that is what we expect a fair open market to look like.
(10:22:45 AM) fort3hlulz: 's commitment to change algos frequently?
(10:23:04 AM) hyc: you're still missing the point.
(10:23:18 AM) fort3hlulz: I agree with you in a perfect world
(10:23:19 AM) hyc: they build a chip - it is not a monero-specific chip. but it is useful, and we like it, so we adopt it.
(10:23:32 AM) fort3hlulz: Like what?
(10:23:44 AM) hyc: if this does not happen on its own, then no, we should never be ASIC-friendly, because there is no fair open market.
(10:24:02 AM) fort3hlulz: We can never adopt BTCs algo (or any other large chain for risk of 51% immediately)
(10:24:16 AM) hyc: if, with all of the ASIC-friendly coins that already exist out there, this market hasn't materialized already, it also isn't going to materialize for us.
(10:24:22 AM) hyc: to think otherwise is denying reality.
(10:24:29 AM) fort3hlulz: It is materializing, but slowly
(10:24:35 AM) hyc: then we wait.
(10:24:39 AM) fort3hlulz: The fall of Bitmain is the first big step towards it spreading
(10:24:46 AM) fort3hlulz: Oh yeah I totally agree the time is not yet here
(10:24:56 AM) fort3hlulz: But I think we need to have a clear plan to move that way well in advance
(10:24:59 AM) hyc: it is IMO way too premature to talk about being ASIC-friendly, without the existence of that market
(10:25:15 AM) fort3hlulz: We just can't wait till its the ONLY option to talk about it.
(10:25:22 AM) moneromooo: Bitmain failed because they decided to bet on a scamcoin, not because it was preordained due to something competition fairness something.
(10:26:02 AM) fort3hlulz: No but it was a key domino that needed to fall for more mfr to start spreading
(10:26:37 AM) fort3hlulz: My concern is that we will force ASIC-resistance too long
(10:26:47 AM) fort3hlulz: But I am still pretty sure it's the right step in the present market
(10:27:09 AM) fort3hlulz: Just want to keep having open discussion in the meantime :)
(10:27:12 AM) hyc: monero is small potatoes. tiny market cap. tiny potential rewards going forward as we get closer to tail emission.
(10:27:22 AM) fort3hlulz: For sure
(10:27:28 AM) hyc: no decision we make is going to change the hardware side's attitudes or mode of operation
(10:27:35 AM) fort3hlulz: Which is why ASIC-resistance is so important right now
(10:28:34 AM) hyc: either they evolve in the right direction on their own, or we keep up the fight indefinitely.
(10:28:49 AM) fort3hlulz: I agree with that sentiment generally
(10:29:03 AM) hyc: if we were a larger market force, we could do like IBM did with the PC, and mandate a 2nd source for their processor chips
(10:29:08 AM) fort3hlulz: As long as we keep having this discussion regularly and evaluating the market!
(10:57:48 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:58:38 AM) vp11: is it unimportant to consider availability of the hardware throughout the world?
(10:58:46 AM) vp11: does this have any weight at all?
(11:22:11 AM) ferretinjapan left the room (quit: Ping timeout: 252 seconds).
(11:31:27 AM) gingeropolous: well i just dumped a wall of text on the github
(11:32:29 AM) gingeropolous: but one of the things that I think we need to consider is that a RandomX ASIC may be developed and that might be OK, because the market dynamics are different for something that is 1-2x efficient and is in direct competition with the leading CPU developers. hyc has said the same thing
(11:32:58 AM) fort3hlulz: Yeah if its not 10-15x efficiency thats honestly probably a good thing to have ASICs
(11:33:16 AM) fort3hlulz: If you gain in efficiency slightly but are bound to Monero's algorithm exclusively, that seems AMAZING
(11:33:35 AM) gingeropolous: and ironically , having a strong ASIC resistant PoW may lead to commoditization faster
(11:33:41 AM) fort3hlulz: You can mine on general HW and move around as you want with slightly worse efficiency, or funnel CapEx into Monero mining via ASICs that are slightly more efficient
(11:33:45 AM) fort3hlulz: I would fucking love that :D
(11:34:12 AM) gingeropolous: because intel and AMD and others already make RandomX ASICs. they just have bloat on them
(11:34:46 AM) hyc: yep
(11:34:56 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:35:20 AM) fort3hlulz: Yeah lol
(11:35:21 AM) gingeropolous: yeah, so randomx asics may actually be fine.
(11:35:44 AM) fort3hlulz: *Assuming there's not a 6-15x gain in efficiency
(11:35:50 AM) fort3hlulz: But that doesn't seem possible from what I've heard/read
(11:40:28 AM) moneromooo: Assuming this is feasible: if the RandomX memory shrinks from 4 GB to 1 GB, and iterations by 50%, what would be the consequences for estimated ASIC resistance ?
(11:43:15 AM) moneromooo: Also, are the powers of 2 between 256 MB to 4 GB usable, with pro-rate (maybe not linearly) verification performance ? I think I asked about this before, but can't recall the answer.
(11:49:45 AM) sech1: you can generate 4 GB dataset partially and use it to speed up verification
(11:50:07 AM) sech1: if you have 2 GB data generated, it'll be ~2 times faster than 256 MB verification
(11:51:52 AM) moneromooo: OK, so possible, but harsh curve.
(12:11:15 PM) spaced0ut left the room (quit: Quit: Leaving).
(12:13:49 PM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(12:16:58 PM) sech1 left the room (quit: Quit: Leaving).
(12:26:49 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:39:25 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(01:17:31 PM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(02:03:54 PM) lithiumpt left the room (quit: Ping timeout: 250 seconds).
(02:06:18 PM) vp11: can someone point me to some resources against merge mining with Bitcoin? might as well be a valid PoW option I guess. I'm ignorant in the subject.
(02:14:25 PM) sgp_: suraeNoether has some resources I think ^^^
(02:33:31 PM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(03:55:03 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(03:55:58 PM) tevador: moneromooo: shrinking memory to 1 GB = reduced CapEx for ASIC manufacturing, not much benefit for PCs except the light verification could be sped up a bit if we keep the 256 MB option (tradeoff is only 4x instead of 16x)
(03:56:40 PM) tevador: 50% of iterations is worse because it would increase the overhead from ~10% to ~20%
(03:57:13 PM) tevador: the overhead are fixed parts of the algorithm which are more susceptible to ASIC optimizations
(03:57:58 PM) tevador: already the number of iterations is the lowest I was comfortable to go
(03:58:53 PM) tevador: additionally, the scratchpad would probably need to ne reduced to 1 MB because there would not be enough output 
(03:59:01 PM) tevador: be*
(04:06:55 PM) ArticMine: I suggest that 4GB RAM is not an unreasonable burden on PCs and may in fact be even low. For example checking the local Bestbuy for low end consumer laptops I find the 4GB RAM is very much the very low end. There was only one Chromebook that was below 4GB. Most are at least 8GB
(04:07:58 PM) ArticMine: If we add a year to the process the impact will e even greater. 
(04:09:51 PM) tevador: If there is a lot of opposition to 4 GB, I would be comfortable with setting it to 2 GB + growing over time as we have discussed with sech1
(04:10:47 PM) sech1: 4 GB is nothing these days
(04:10:53 PM) sech1: I'm for 4 GB + growing dataset
(04:11:14 PM) sech1: you can't even buy new memory stick smaller than 4 GB
(04:11:36 PM) ArticMine: One interesting aspect of RandomX is that in the future it will be necessary to grow the memory footprint  over time to accommodate the increase in memory footprint of laptops etc
(04:12:40 PM) tevador: preliminary plan is growing ~512 MB per year
(04:14:12 PM) ArticMine: The more I look at RandomX the more it looks like an "ASIC" may in fact be possible but the "ASIC" may end up being nothing more than a more efficient CPU
(04:14:27 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(04:15:39 PM) tevador: which would require an enormous R&D investment
(04:16:06 PM) tevador: more likely "ASIC" is some custom ARM core, but still it will not be much more efficient
(04:16:36 PM) ArticMine: Eliminating needless bloat such as for example the Intel management engine whose sole purpose is DRM and is a major security issue
(04:17:06 PM) sech1: It'll only save silicon area but not the power
(04:18:04 PM) ArticMine: Have you looked at the IBM  Power 9 for example?
(04:19:00 PM) tevador: I have seen the specs
(04:19:09 PM) tevador: I did research about the Summit supercomputer
(04:19:53 PM) tevador: I don't see anything groundbreaking there, AMD Ryzen level of performance at best
(04:20:16 PM) hyc: ArticMine: yes, an ASIC would be a CPU, that was the entire point
(04:21:38 PM) sech1: New AMD EPYC CPUs (64 cores, 256 MB cache) will be THE RandomX ASICs
(04:22:53 PM) gethh: literally
(04:23:30 PM) tevador: yes, those could do 30-40 KH/s per CPU
(04:24:01 PM) crCr62U0: The final aim is perfect. How much time do we need to achieve it?
(04:24:03 PM) sech1: No matter what linzhi say, 7 nm CPUs optimized for power efficiency will be faster than whatever they come up on 28 nm
(04:24:12 PM) gethh: at minimum , the larger L3 may let another improvment
(04:24:17 PM) gethh: so 100KH for dual socket box
(04:24:47 PM) gethh: I will find out preaty soon :)
(04:24:55 PM) tevador: gethh when is it coming?
(04:25:08 PM) gethh: comercialy July
(04:25:19 PM) sech1: eng. samples are out already
(04:25:22 PM) tevador: I have seen reports about May to July
(04:25:49 PM) gethh: samples are out for tier one vendors atm
(04:25:53 PM) gethh: HPE , etc
(04:26:13 PM) tevador: they could spare one sample for the RandomX team :D
(04:26:32 PM) ArticMine: My take is that RandomX is very much on the right track here
(04:27:34 PM) tevador: personally my only issue with RandomX is the slower light verification, but I haven't found a way around it
(04:27:35 PM) gethh: yea the algo is like someone got kickbacks from AMD :D
(04:28:07 PM) sech1: No, it's just AMD kicking Intel's ass
(04:28:18 PM) gethh: sech1 true
(04:28:20 PM) tevador: it runs better on AMD because the latest AMD arch is just better
(04:28:34 PM) sech1: yep
(04:28:40 PM) sech1: I knew it long ago
(04:28:52 PM) tevador: also Intel has been holding out and now it bit them
(04:28:54 PM) sech1: properly optimized code runs faster on Ryzen at the same clock speed
(04:28:59 PM) gethh: sech1 and you were probably one of not many 
(04:29:03 PM) sech1: it was the case even with the first Ryzen
(04:29:13 PM) gethh: the market inertia towards intel was huge
(04:29:41 PM) tevador: 7700K flagship CPU was a quad core, wtf?
(04:30:07 PM) gethh: AMD did that to Intel before 2005-2006 
(04:30:12 PM) hyc: lol. people were saying we got kickbacks from Intel because Xeon Phi would romp on RandomJS.
(04:30:20 PM) hyc: conspiracy theorists everywhere
(04:30:37 PM) gethh: hyc i was just sarcastic no conspiracy :)
(04:31:14 PM) tevador: btw Xeon Phi might not be bad at RandomX
(04:31:15 PM) ArticMine: Yes but light verification is on what 256 MB RAM?
(04:31:43 PM) tevador: ArticMine yes, but the IBD will be essentially locked to the light verification
(04:31:48 PM) rottensox left the room (quit: Read error: Connection reset by peer).
(04:32:15 PM) moneromooo: Eh ? Why ?
(04:32:22 PM) tevador: because to verify 1024 blocks, it's not worth initializing the 4 GB dataset
(04:32:32 PM) tevador: unless you have some serious compute
(04:32:47 PM) moneromooo: That's pretty not nice. I did not realize that.
(04:32:58 PM) tevador: we could increase the number of blocks, though
(04:34:05 PM) tevador: moneromooo is it a bit issue, though? 80 blocks per second on a quad core is probably more than you can physically download
(04:34:10 PM) tevador: big*
(04:35:14 PM) sech1: does light verification use interpreter right now?
(04:35:19 PM) tevador: yes
(04:35:23 PM) sech1: maybe it can be made faster with code generation
(04:35:31 PM) tevador: so it could be sped up by around 30%
(04:36:03 PM) tevador: actually it's up to 60% on slow CPUs
(04:36:54 PM) tevador: example: Intel Core i5-3230M ~24 ms for memory accesses, ~50 ms for interpreter
(04:37:19 PM) tevador: Ryzen is more like 25/25 ms
(04:38:34 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(04:39:13 PM) ArticMine: Can this be tuned by increasing the 256 MB limit to say 512  MB or even 1 GB?
(04:39:57 PM) tevador: yes, then you can decrease the number of memory accesses for light clients
(04:40:15 PM) tevador: you have to keep a constant time * area product
(04:40:27 PM) tevador: so 256 MB * 16 accesses = 4 GB * 1 access
(04:41:12 PM) ArticMine: so 512 MB * 8 or 1 GB * 4
(04:41:17 PM) tevador: yes
(04:41:40 PM) tevador: but I set it to 256 MB to support low end devices
(04:42:08 PM) tevador: not sure it it's even feasible to run Monero on something with just 512 MB of RAM
(04:42:15 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(04:42:34 PM) ArticMine: My instinct is this is way low
(04:43:25 PM) sech1: But can it be "unfolded" from 256 MB to 512 MB in some implementation with current dataset generation algorithm?
(04:43:35 PM) sech1: So light clients could choose their memory size
(04:44:25 PM) tevador: not possible with current implementation
(04:45:05 PM) el00ruobuob left the room (quit: Remote host closed the connection).
(04:45:07 PM) tevador: you do Argon2d fill of 256 MB and create the dataset from this
(04:45:23 PM) tevador: if you select 512 MB for Argon, you will get completely different data
(04:45:29 PM) sech1: maybe make it iterative process where 256 MB create 512 MB, then 1 GB is created out of 512 MB and so on
(04:45:35 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 252 seconds).
(04:45:55 PM) tevador: wouldn't that be too slow?
(04:46:20 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(04:46:52 PM) sech1: that was just random thought
(04:47:31 PM) tevador: I was inspired by Ethash, which uses 16 MB -> 1+ GB expansion
(04:47:42 PM) tevador: except they use SHA3 to fill memory
(04:48:07 PM) tevador: Arong2 uses Blake2b
(04:48:11 PM) tevador: Argon*
(04:49:45 PM) ArticMine: Maybe consider  512 MB or even 1 GB
(04:51:44 PM) ArticMine: Windows 10 64it has 2 GB minimum requirements so Monero would run fine on 4 GB RAM
(04:53:31 PM) tevador: any of the configurable parameters are up for discussion and should be easy to change: https://github.com/tevador/RandomX/blob/dev/src/configuration.h[1]
(04:53:32 PM) hyc: no machine built today has only 2GB RAM :P
(04:54:26 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(04:54:40 PM) sech1: but but... Raspberry Pi
(04:54:47 PM) ArticMine: You may find the odd Chromebook with 2 GB RAM 
(04:55:06 PM) hyc: it's even hard to find a phone with only 2GB RAM
(04:55:29 PM) hyc: (but I was referring to Windows PCs in the previous statement)
(04:55:33 PM) tevador: I challenge someone to do a full Monero blockchain sync on 1st gen Rasperry Pi
(04:55:35 PM) moneromooo: I was under the impression that the need was for 4 GB *free* RAM.
(04:56:14 PM) ArticMine: No it more like under 2 GB
(04:56:20 PM) moneromooo: So saying this machine shpis with 4 GB is totally missing the point.
(04:57:02 PM) tevador: for mining
(04:57:37 PM) sech1: look at these guys: https://monerobox.store/
(04:57:41 PM) sech1: they already sold some
(04:57:45 PM) sech1: 1 GB versions too
(04:59:05 PM) tevador: I have tested RandomX on Raspberry Pi 3B (1 GB)
(04:59:52 PM) hyc: I've also tested on ARMv8 2GB RAM
(05:00:12 PM) hyc: not pleasant :P
(05:00:23 PM) tevador: 50000 hashes ~2 days
(05:00:37 PM) tevador: so full sync would be 1 month or so
(05:09:23 PM) tevador: btw my full RandomX documentation is over 16 pages, needs a lot of editing probably...
(05:11:53 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(05:13:42 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1007::9f] entered the room.
(05:15:26 PM) hyc: who should we get to review the doc?
(05:16:11 PM) sech1: tevador on another topic: COND_R, COND_M instructions can be implemented with mov/inc/cmp/cmovxx combo
(05:16:18 PM) sech1: much shorter than what you have now
(05:16:50 PM) fort3hlulz left the room (quit: Ping timeout: 246 seconds).
(05:17:23 PM) sech1: hmm, not shorter, but it should be faster on CPU
(05:17:40 PM) sech1: more independent instructions
(05:21:36 PM) tevador: hyc: yes, I will post it when I do some final corrections
(05:22:00 PM) tevador: sech1 do you think it makes a difference?
(05:25:24 PM) tevador: we can test it, it's a 1 instruction shorter dependency chain
(05:52:14 PM) sech1: shorter dependency chain should give better IPC
(06:00:55 PM) fort3hlulz_ left the room (quit: Remote host closed the connection).
(06:01:14 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1007::9f] entered the room.
(06:44:36 PM) sech1 left the room (quit: Quit: Leaving).
(07:20:27 PM) fort3hlulz_ left the room (quit: Ping timeout: 240 seconds).
(07:27:51 PM) kenshi84_ [~kenshi84@p525175-ipngn4501akatuka.ibaraki.ocn.ne.jp] entered the room.
(07:31:32 PM) kenshi84 left the room (quit: Ping timeout: 252 seconds).
(07:35:24 PM) [-mugatu-] left the room (quit: Ping timeout: 250 seconds).
(07:36:08 PM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(07:43:25 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(08:04:44 PM) IRS left the room (quit: Read error: Connection reset by peer).
(08:05:58 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(08:59:56 PM) hyc: So how about ArticMine's question - did we actually kill any ASICs, or did we just make everyone 3.6x slower?
(09:01:43 PM) gingeropolous: im hoping he ran with MONERO_USE_CNV4_JIT=1
(09:02:05 PM) moneromooo: Pool miners don't run the reference code, they're fast by default.
(09:02:35 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1007::9f] entered the room.
(09:04:05 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(09:04:51 PM) fort3hlulz_ left the room (quit: Read error: Connection reset by peer).
(09:05:02 PM) hyc: and I just noticed we got to v11 without any trouble. so how long did that take, overall?
(09:06:16 PM) hyc: anyway we clearly kicked off a lot of miners, whatever equipment they were using
(09:10:54 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:12:21 PM) Mafaka [~Mafaka@74-116-186-137.qc.dsl.ebox.net] entered the room.
(09:30:48 PM) jwinterm left the room (quit: Remote host closed the connection).
(10:32:49 PM) fort3hlulz left the room (quit: Ping timeout: 252 seconds).
(11:01:38 PM) ArticMine: MONERO_USE_CNV4_JIT=1 only improved the hashrate from 10 H/s to 24H/s so there was still a hit from 36 H/s
(11:04:23 PM) spaced0ut left the room (quit: Ping timeout: 246 seconds).
(11:17:17 PM) vp11: realistically speaking, how much of the hashrate was outside of the pools? one has to imagine that miners on pools were using updated software and running optimal or near-to-optimal settings.
(11:20:17 PM) vp11: I have 6 GPUs pool mining and I took a hit of ~2% on hash rate.
(11:27:17 PM) ArticMine: Actually right at the fork time the pools were having issues, This was part of the reason for a lat first post fork block
(11:35:57 PM) ArticMine: So it was clear to me that some of the pools were simply not ready. Still I would watch the overall hash rate to see where we will end up
(11:42:21 PM) Mafaka left the room (quit: ).
(12:26:47 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(01:19:58 AM) kopite7 left the room (quit: Ping timeout: 272 seconds).
(01:46:09 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(02:07:38 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:31:39 AM) patap0n left the room (quit: Ping timeout: 252 seconds).
(02:39:04 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:13:20 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 272 seconds).
(03:33:08 AM) Coupe420 left the room (quit: Read error: Connection reset by peer).
(03:45:31 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(03:53:39 AM) ferretinjapan left the room (quit: Ping timeout: 252 seconds).
(03:54:49 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:05:42 AM) sech1 left the room (quit: Quit: Leaving).
(04:08:50 AM) cjd: Anyone aware of the current status of Rex Computing ?
(04:10:47 AM) cjd: their chips seem like they would be fairly good at wide MIMD w/o latency demands
(04:18:21 AM) midipoet [uid316937@gateway/web/irccloud.com/x-ukbtbgfcwsiougjd] entered the room.
(04:20:26 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:25:28 AM) linzhi-sonia: what kind of profitability (cents/kH/day) do GPU miners expect or need?
(04:25:42 AM) linzhi-sonia: pre-fork it was about 11c, right now I see 40c
(04:27:22 AM) linzhi-sonia: I read over some amazing "anti-asic" reasoning and chatting yesterday, between tevador hyc, many others. there are so many misconceptions in that, from my side, I cannot even respond. slowly... will continue to read and learn. if you guys are happy, that's good.
(04:29:54 AM) moneromooo: If you can not respond to misconceptions due to the amount of them, maybe you can pick some of the most wrong ones and response to these only :)
(04:31:48 AM) linzhi-sonia: yes, slowly. There is no point in telling each other "all wrong". One by one. thinking
(04:32:08 AM) linzhi-sonia: most important is that XMR is stable and the devs are happy and motivated
(04:32:29 AM) linzhi-sonia: if we have that, not that much can be "wrong", right? :)
(04:32:56 AM) linzhi-sonia: what kind of profitability do GPU miners expect and want?
(04:33:25 AM) linzhi-sonia: I mean the cents/kH/day number (that's how I typically look at profitability)
(04:34:11 AM) linzhi-sonia: one way to estimate ASICs is to compare profitability between different GPU-minable coins
(04:34:48 AM) linzhi-sonia: of course this estimation still has many flaws, I understand, but it's one number to look at
(04:43:28 AM) sech1: GPU miners need to earn more than they spend on electricity
(04:43:39 AM) sech1: 40c/kH/day is good enough for most right now
(04:46:40 AM) sech1: it makes anything less than 15c/kwh profitable
(04:56:06 AM) Inge-: I rather enjoyed 7-8$/kH/day, can I have that back please :D
(04:58:17 AM) sech1: It was never this high, even in 2017
(04:59:00 AM) sech1: or are you talking about 2014 and crippled-miner era?
(05:00:10 AM) Inge-: I think I recorded ~$100/day some days in late 2017 on an 8-card Vega rig - although it might depend on what was mined one day and changes in the price on a later day. Definitely not the cripple-miner era which was far too early for me
(05:03:15 AM) sech1: Here's the chart to refresh your memory: https://bitinfocharts.com/comparison/monero-mining_profitability.html[1]
(05:03:22 AM) sech1: it shows $/kh
(05:05:57 AM) Inge-: I have been living a lie!
(05:09:40 AM) sech1: $12.5 per Vega requires $6.25 per kh, it was possible in 2017
(05:09:47 AM) sech1: There were more profitable coins than Monero
(05:10:05 AM) Inge-: I did ETN for a while due to that
(05:10:08 AM) moneromooo: ArticMine: does this drop show up when you run MONERO_USE_CNV4_JIT=1 ./build/release/tests/performance_tests/performance_tests --filter=\*slow\* ?
(05:24:26 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:31:10 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(05:34:17 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(06:01:06 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(06:06:33 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:30:15 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(07:50:28 AM) dEBRUYNE: tevador: You online?
(08:18:18 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(08:44:49 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(08:52:53 AM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(08:57:39 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(08:58:35 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(09:21:19 AM) hyc: welp. now everyone is in the PoW discussion, it probably *is* affecting all the devs
(09:23:44 AM) dEBRUYNE: Better to have it now then in a few years though :P
(09:24:52 AM) hyc: ;)
(09:28:48 AM) sech1: The problem is we don't have enough data to discuss it properly. The main question is how efficient RandomX ASIC could be.
(09:29:27 AM) vp11: yeah that's a bummer
(09:29:32 AM) vp11: where's wownero
(09:29:37 AM) vp11: let's implement it yesterday!
(09:31:18 AM) midipoet: hyc, how confident are you that RandomX will work? 
(10:18:46 AM) hyc: define "work" :P
(10:19:03 AM) hyc: personally I believe it is the right approach and the only approach that can succeed.
(10:19:32 AM) hyc: and I also believe that it will be good for many years.
(10:21:32 AM) midipoet: yeah, i was thinking of what 'work' would mean. i suppose in this context it means to be resistant to ASIC manufacturing (that have maximum degree of 2x advantage). does that make sense?
(10:22:11 AM) hyc: Something like that, yes. Really the question is, what efficiency gap is tolerable?
(10:22:31 AM) hyc: and we can answer that now, by asking - what efficiency gaps can we already measure between existing GPUs and CPUs
(10:22:47 AM) hyc: they are existence proofs of what miners will accomodate
(10:22:58 AM) vp11: that's an important point of discussion that needs to be very well defined, what is "failure" and what is "success" for RandomX.
(10:23:33 AM) dEBRUYNE: If ASICs obtain x2-x3 you can reasonably expect them to push virtually all other miners out
(10:23:46 AM) dEBRUYNE: Especially those that have invested in their equipment and have to pay electricity costs
(10:24:08 AM) midipoet: what about the questions of security? is one audit enough to establish if a POW algo is secure? also what are the implications of it not being secure? 
(10:24:51 AM) hyc: security really isn't at issue here. the input and output of RandomX are passed through a cryptographic hash
(10:25:53 AM) hyc: the chosen hashes are well studied. not a concern.
(10:26:47 AM) dEBRUYNE: midipoet: I think tevador somewhat addressed that -> https://github.com/monero-project/meta/issues/316#issuecomment-472076728[1]
(10:27:10 AM) Inge-: It could be other issues than the hashes as such? https://www.reddit.com/r/CryptoCurrency/comments/8a2b99/verge_xvg_mining_exploit_attack_megathread/[1]    (not saying anything like that could be a possibility, but new stuff sometimes fails in unexpected ways)
(10:28:20 AM) hyc: we're not doing dual-PoW :P   in fundamental aspects, RandomX is like any other single-PoW, in its cryptographic properties.
(10:28:34 AM) hyc: where it differs is in its work properties.
(10:31:15 AM) midipoet: thanks all for the context
(10:35:18 AM) sech1: "If ASICs obtain x2-x3 you can reasonably expect them to push virtually all other miners out" GPUs are 4 times faster than CPUs on Cryptonight yet CPUs are not pushed out
(10:35:37 AM) dEBRUYNE: <dEBRUYNE> Especially those that have invested in their equipment and have to pay electricity costs
(10:35:54 AM) dEBRUYNE: It will push out large mining farms that are solely mining for a profit
(10:36:01 AM) sech1: It is GPU vs CPU (4:1) now, CPUs still mine
(10:36:09 AM) sech1: if it will be ASIC vs CPU (2:1) guess what?
(10:36:21 AM) dEBRUYNE: CPUs are minority though
(10:36:42 AM) hyc: right now yes, but why would they remain minority?
(10:37:16 AM) dEBRUYNE: In RandomX they wouldn't, but they likely would end up as minority if ASIC vs CPU ends up 2:1
(10:37:35 AM) dEBRUYNE: That also assumes the x2 holds, which I am doubtful about
(10:37:48 AM) sech1: yeah, maybe it will be only 1.5x
(10:37:58 AM) sech1: because why so pessimistic?
(10:38:13 AM) dEBRUYNE: Optimism has little place in an adverserial environment
(10:38:16 AM) hyc: indeed, that's very iffy. ASICs may have the advantage of a shorter development cycle, CPU refreshes tend to be only once/year
(10:38:41 AM) hyc: but ASIC developers are also a lot less funded than CPU houses.
(10:38:47 AM) sech1: CPUs will always be a step ahead, they will be 7 nm vs 16-28 nm ASICs
(10:38:50 AM) sech1: and so on
(10:39:07 AM) hyc: sech1: someone posted a 7nm bitmain ASIC
(10:39:16 AM) hyc: the same process technology is available to all players
(10:39:23 AM) moneromooo: I think linzhi-sonia estimated x10 at zeroth approximation. No details though, so could be bluster, but could also be right.
(10:39:25 AM) hyc: which I think is the very definition of egalitarian
(10:39:31 AM) sech1: 7 nm is an order of magnitude more expensive
(10:39:44 AM) hyc: and yes. it is more expensive, so few ASIC builders will go for it
(10:39:48 AM) moneromooo: linzhi-sonia: any more info about where you think the bulk of that speedup can be attained ?
(10:39:53 AM) sech1: linzhi also estimated 3-8x on progpow
(10:40:00 AM) sech1: I wouldn't believe it straight away
(10:40:33 AM) hyc: indeed. without actual study those numbers are meaningless
(10:40:43 AM) dEBRUYNE: Any claims should be met with doubt
(10:40:51 AM) dEBRUYNE: Only practice will tell (eventually)
(10:40:59 AM) hyc: yes.
(10:41:00 AM) moneromooo: Really ? Any evidence for that statement, dEBRUYNE ?
(10:41:13 AM) hyc: which is why it's premature to make carved-in-stone decisions today.
(10:41:17 AM) dEBRUYNE: moneromooo: Which one?
(10:41:18 AM) Inge-: borderline nihilism there moneromooo :P
(10:41:21 AM) sech1: We don't want claims, we want technical details of how they would do 10x ASIC for RandomX
(10:41:24 AM) moneromooo: < dEBRUYNE> Any claims should be met with doubt
(10:41:32 AM) sech1: so far linzhi has been reluctant to provide it
(10:41:37 AM) dEBRUYNE: I was referring to the linzhi claim
(10:41:40 AM) hyc: even deciding "we will adopt SHA3 in 2 years time" is really unsupportable. there may be a better choice than SHA3 in 2 years time.
(10:41:55 AM) dEBRUYNE: But also to the claim that 2x is the maximum advantage an asic can achieve
(10:42:22 AM) hyc: dEBRUYNE: that claim is supportable within a certain context.
(10:42:23 AM) sech1: this claim was based on analysis of which parts can be removed from CPU
(10:42:34 AM) Inge-: Do many support the "ASIC resistance forever" stance, or is there general consensus on "ASIC at some point is inevitable" ?
(10:42:34 AM) sech1: and what can be optimized for power consumption
(10:43:06 AM) sech1: ASIC are inevitable, but with ASIC-resistant PoW they won't have big advantage
(10:43:10 AM) hyc: the underlying assumption is that RandomX forces the hardware to have an instruction fetcher and decoder, at which point the optimal approach is to build what looks like a CPU
(10:43:17 AM) dEBRUYNE: sech1: Regardless, it remains theoretical and thus should be met with doubt (at least that's my opinion and as far as I can see, smooth's too) 
(10:43:42 AM) hyc: if this underlyin assumption is wrong, and you can actually implement RandomX *without* an instruction fetch/decode stage, then our 2x estimate goes out the window
(10:44:02 AM) dEBRUYNE: Which is why I think we should at least have a backup plan in case that happens
(10:44:05 AM) sech1: The only way is to actually pay some design house make RandomX estimations and reference ASIC design
(10:44:25 AM) sech1: everything else is just theory, from both sides
(10:44:29 AM) dEBRUYNE: That wouldn't even be conclusive either
(10:44:32 AM) hyc: note - there's always other ways to approach a problem. but I think they all end up costing more chip area/speed/etc.
(10:45:37 AM) hyc: this has been my only concern with randomX - it is too simple. You can design a state machine that covers all of its instructions, in a fairly compact space.
(10:46:02 AM) hyc: (CN/R is even smaller/simpler)
(10:47:16 AM) hyc: The arguments about avoiding complexity to avoid room for unseen optimizations are fair
(10:47:25 AM) dEBRUYNE: <dEBRUYNE> That wouldn't even be conclusive either <= To add, that particular manufacturer may build an asic that achieves a certain speed, but that doesn't rule out another manufacturer building a more efficient one
(10:47:51 AM) sech1: same goes for SHA3
(10:48:05 AM) sech1: and anything else
(10:48:13 AM) hyc: ^ right
(10:48:31 AM) dEBRUYNE: True, but I don't see how that is related in the argument we were having
(10:48:43 AM) dEBRUYNE: discussion*
(10:48:51 AM) dEBRUYNE: Or were you referring to hyc?
(10:50:49 AM) sech1: btw what happened with our plans to have RandomX reviewed by Tim Olson?
(10:51:04 AM) hyc: ISTR Tim is busy
(10:51:08 AM) hyc: but not sure
(10:51:23 AM) dEBRUYNE: btw hyc, sech1: how far along is RandomX?
(10:51:35 AM) dEBRUYNE: I think I remember tevador stating it is almost ready, can any of you confirm that?
(10:51:40 AM) hyc: it is ready for monerod integration already
(10:51:44 AM) sech1: yes, it's ready
(10:51:50 AM) hyc: I think wownero will go ahead on it
(10:51:59 AM) sech1: but we also need to write miners for it
(10:52:06 AM) dEBRUYNE: So we basically have 6-7 months to audit, test, and write miners?
(10:52:14 AM) sech1: yes
(10:52:23 AM) dEBRUYNE: I'd rather have RandomX 'prematurely' implemented than another tweak
(10:52:29 AM) sech1: there might be some tweaks based on audit/review results
(10:52:31 AM) dEBRUYNE: Imo the latter has more risks attached
(10:53:00 AM) moneromooo: A tweak to a proven algorithm has more risks than a wholly new one ?
(10:53:08 AM) moneromooo: Or did you mean the opposite ? :)
(10:53:37 AM) hyc: at this point nothing can be gained from further tweaks to CN
(10:53:52 AM) dEBRUYNE: moneromooo: Not in isolation, but in the grand-scheme, yes
(10:53:54 AM) hyc: the bulk of the algorithm is already fully analyzed by ASIC builders
(10:54:28 AM) hyc: CN is now only "proven" in the sense of "proven defeated"
(10:54:43 AM) dEBRUYNE: Also doesn't CN-R use some similar stuff as RandomX (i.e. random code generation)?
(10:54:49 AM) hyc: yes
(10:54:52 AM) hyc: but on a small scope
(10:55:19 AM) ***moneromooo sees the bombastic stuff and retreats back to code
(10:56:03 AM) dEBRUYNE: moneromooo: With 'prematurely' I didn't mean unaudited fwiw
(10:56:23 AM) dEBRUYNE: Hence the ' ' 
(11:00:30 AM) midipoet: i think most here commit to a strategy that ensures it is difficult for an oligopolistic market to emerge. is that fair to say? 
(11:01:00 AM) hyc: definitely a goal
(11:07:04 AM) hyc: Strange, I just had a sense of deja-vu about this whole conversation, as if it happened 2 years ago.
(11:07:59 AM) midipoet: oh it did, we just drugged you in the meantime and had you come up with RandomX. don't worry about it
(11:08:08 AM) hyc: :P
(11:08:37 AM) gingeropolous: lol
(11:09:15 AM) sech1: 2 years ago there was a heated debate about Ethereum PoW
(11:09:20 AM) sech1: oh wait, 3 years ago
(11:09:30 AM) sech1: time flies
(11:11:48 AM) hyc: obtw, while simplicity is *usually* best, I still believe for our purposes complexity is necessary. E.g. I preferred using Mersenne Twister as PRNG instead of a simpler one. because implementing MT in hardware is more difficult.
(11:12:10 AM) hyc: and also, MT is quite popular in software; if an ASIC were developed to accelerate it, we all win, again.
(11:13:30 AM) hyc: though in this particular case, it's again, a well-trodden path https://hgpu.org/?p=3279
(11:13:40 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:16:21 AM) gingeropolous: am i crazy or dumb (or both) in this self-produced asic idea? Its kinda like a scorched earth policy. If we go through the effort (ala Siacoin) of producing our own RandomX asic, wouldn't we reduce any further gains from potentially nefarious asic manufactures?
(11:16:48 AM) hyc: I see nothing wrong with that idea
(11:16:53 AM) gingeropolous: the assumption that *has* to hold is that there is a max efficiency gain that can be squeezed out
(11:17:16 AM) hyc: having a hardware reference is always a good starting point. HAving an open design that others can freely iterate on would be good for us all too.
(11:17:23 AM) gingeropolous: we could reduce the profit margins so much that they decide its useless
(11:17:30 AM) dEBRUYNE: Siacoin is a bad example though :-P
(11:17:39 AM) dEBRUYNE: They forked off other manufacturers when they beat them to the punch
(11:17:45 AM) hyc: ArticMine makes a good point about using GPLv3 to ensure nobody privatizes our open design
(11:18:38 AM) hyc: dEBRUYNE: but wait - we should just announce "we're going to do what SiaCoin did" and all the 3rd parties will know in advance we're going to shaft them, so they won't bother! :P
(11:18:39 AM) gingeropolous: well, yeah... my point was a coin went through the effort to produce and distribute their own asic. how they handled it is a different story, and their overall strategy of asic dominance I obviously question :)_
(11:18:59 AM) gingeropolous: thats, uh, an emoticon of me smiling and smoking a cigarette. totally not a typo
(11:20:24 AM) gingeropolous: hyc, i don't fully understand licenses... should we also copyleft RandomX itself?
(11:20:35 AM) gingeropolous: i dunno what tevador has it as currently
(11:21:08 AM) hyc: IMO it would be a good idea, because GPLv3 also addresses patents, and when we talk about hardware patents become extremely relevant
(11:21:10 AM) gingeropolous: thats GPLv3's main thing right?
(11:21:32 AM) hyc: (tho obviously some freaks also like software patents, but that's not a concern here)
(11:22:06 AM) hyc: this way, if we ever discover a secret ASIC miner, we can sue them for license violation
(11:22:39 AM) dEBRUYNE: hyc: Might as well let a few devs determine the blocks then lol
(11:22:49 AM) hyc: not that I have any idea who would act as the plaintiff in such a lawsuit
(11:23:27 AM) oneiric_: hyc get the eff to do it :)
(11:23:38 AM) hyc: yeah, that's a possibility
(11:23:52 AM) midipoet: i think we can incentivise an ASIC manufacturer - especially one that buys into our social contract
(11:24:02 AM) midipoet: with regards the open hardware model
(11:24:02 AM) oneiric_: would be an epic trial
(11:24:10 AM) midipoet: i honestly believe it can be done
(11:25:00 AM) hyc: note that while I think GPLv3 for RandomX is vital, now that ArticMine has drawn attention to it, the Monero Project won't accept it.
(11:25:48 AM) gingeropolous: and if we could do the self-asic, we could actually create a product that promotes decentralization. yah know, it could run a node and a private pool etc etc.
(11:26:11 AM) dEBRUYNE: It may also be an attack vector
(11:26:20 AM) dEBRUYNE: Because there would be a company one could go after
(11:26:44 AM) gingeropolous: hrmmm
(11:30:54 AM) gingeropolous: i wonder if in this theoretical asic open design, we could create a hardware design signature
(11:31:23 AM) gingeropolous: like, the design is released, other manufactures do it, but then a user can run something from a monero daemon that says "yup, this is cool"
(11:31:38 AM) gingeropolous: that no balderdash has been put in
(11:31:38 AM) hyc: backing up a step - if we are going to build ASICs, why aren't we just building SHA3 ASICs?
(11:32:34 AM) gingeropolous: in my head its that if you have an ASIC dominated network (which is what sha3 would be), asic manufactures have all the incentive to secretly mine
(11:33:06 AM) gingeropolous: in an asic equivalence network (if that exists), asic manufactures have less incentive to secretly mine and centralize. and if we scorch the earth, there's even less incentive
(11:33:35 AM) gingeropolous: i dunno. just my random idea of the day
(11:34:19 AM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(11:35:26 AM) hyc: back to Mersenne Twister: Moreover, power
(11:35:26 AM) hyc: measurements showed our FPGA implementation to be
(11:35:26 AM) hyc: 37x and 35x more energy efficient than CPU and GPU
(11:35:29 AM) hyc: respectively.
(11:36:52 AM) hyc: in this particular workload, CPU and GPU are basically equal in power efficiency
(11:40:19 AM) hyc: anyway, keeping that number in mind, and knowing that a softcore processor on an FPGA will typically run at 4-5x slower clock speeds than a CPU
(11:40:44 AM) dEBRUYNE: gingeropolous: They have incentive to secretly mine as long as ASIC resistance is stated
(11:40:49 AM) dEBRUYNE: Not on a network that embraces ASICs
(11:41:14 AM) hyc: ... never mind, lost the thought
(11:41:47 AM) dEBRUYNE: hyc: Sdie note, do you think a RandomX audit is less work than a BP audit?
(11:41:51 AM) hyc: dEBRUYNE: I think they still have incentive to keep their newest products to themselves, and only sell the obsolete generation
(11:42:50 AM) hyc: re: audit, probably. it strikes me as the sort of thing a static analysis tool like Coverity could do for us and everyone would be satisfied.
(11:43:51 AM) hyc: 1) is the code implemented correctly, are there any edge cases/undefined behaviors - this should be easy to check.
(11:44:00 AM) dEBRUYNE: hyc: They also have to recoup costs though, which necessitates them to sell (at least some) devices
(11:44:32 AM) hyc: 2) is the design actually difficult to implement with an efficiency advantage in hardware - here we need experts to answer that.
(11:45:24 AM) dEBRUYNE: We don't necessarily need to wait for that before implementing though right?
(11:45:32 AM) hyc: right
(11:45:45 AM) dEBRUYNE: I mean, we can't stop the network either and resume it once we have proper answers ;P
(11:51:42 AM) gingeropolous: did we ever get that azure guy that wanted to fuzz monero whatever he needed?
(11:51:46 AM) gingeropolous: or was it google
(11:55:45 AM) gingeropolous: dEBRUYNE, yeah I guess i have it in my mind that RandomX is the last stand... so Monero wouldn't really wouldn't have a stance of asic resistance at that point, its just more of how monero would live in a world of asics. i.e., would be it be asic dominant or equivalent. 
(12:02:34 PM) gingeropolous: and that of course relies on data that we don't have yet
(12:05:01 PM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(12:05:18 PM) dEBRUYNE: gingeropolous: Your assumption is kind of based on asics only getting a 2x advantage though
(12:05:27 PM) dEBRUYNE: If they somehow achieve x10, you don't really want to continue with RandomX
(12:05:28 PM) gingeropolous: yeah, agreed
(12:06:11 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:09:52 PM) sech1 left the room (quit: Quit: Leaving).
(12:20:09 PM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(12:20:32 PM) moneromooo: If you GPL randomX, Monero will have to also, since it has to include it for verification.
(12:22:33 PM) moneromooo: gingeropolous: that was guidov, last I heard he tried posting a ffs and got a 404 :/ Supposedly fixed now.
(12:30:11 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:40:39 PM) klp: Has anyone ever considered using Google's TPU as an ASIC for a brand new proof-of-work algo?
(12:48:47 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(01:06:47 PM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(01:10:08 PM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(01:16:25 PM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(01:22:48 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:47:30 PM) needmoney90: https://en.wikipedia.org/wiki/GPL_linking_exception[1]
(01:47:32 PM) needmoney90: Moneromooo
(01:47:36 PM) needmoney90: Does this not apply? 
(01:47:38 PM) needmoney90: If done right 
(01:50:50 PM) moneromooo: You could put it in a .so loaded at runtime, in another project. You'd have to have a fallback impl though.
(01:51:06 PM) moneromooo: ie, a slow one coded without the original.
(01:52:25 PM) moneromooo: Oh you mean licence it not as GPLv3, but GPLv3 plus special case ? That'd work.
(01:52:51 PM) moneromooo: The author (technically copyright holder) can do whatever.
(01:55:02 PM) hyc: that might be a good way to go
(01:55:35 PM) hyc: though afaics it means tevador would be the one to pursue any lawsuits
(01:56:12 PM) moneromooo: But then an ASIC maker could run the whole modified monerod on a processor, just doing nothing, even without a blockchain. You'd have to be careful how you'd write it to be effective.
(01:56:53 PM) midipoet: Would we realistically pursue a lawsuit?
(01:56:57 PM) moneromooo: I think the OSS conservancy (or whatever it's called) can "take over" on your behalf. Not sure they'd be interested in that though.
(01:57:10 PM) hyc: also, if they never distribute the ASICs to anyone else, there's no impact on the license
(01:58:28 PM) moneromooo: And anyway, an ASIC maker will likely rewrite their own code anyway.
(01:58:39 PM) hyc: true
(01:59:01 PM) hyc: but .... if we can prove that they copied any part of the original reference design ...
(01:59:17 PM) hyc: i.e., if they don't do a cleanroom reimpl
(01:59:20 PM) moneromooo: You then get to spend 10 years in discovery.
(01:59:26 PM) hyc: anyway it's probably more hassle than it's worth
(02:04:45 PM) hyc: by the way, while we talk about 2x advantages - this is the status quo in ETH right now. ETH ASICs exist and they are 2x more efficient than GPUs.
(02:04:53 PM) hyc: yet GPUs are still the dominant mining device
(02:06:07 PM) hyc: this article is strange  https://www.trustnodes.com/2019/01/12/the-progpow-team-admits-theyre-working-with-nvidia-and-amd
(02:06:22 PM) hyc: there's controversy because ProgPow team asked AMD and Nvidia for feedback?
(02:06:40 PM) hyc: seems to me like it would be irresponsible to develop a GPU algo and *not* ask them for feedback
(02:06:50 PM) hyc: what's the big deal with that?
(02:19:01 PM) needmoney90: Hyc: the worry is that Kristy is working with amd/nvidia to get special parts added to their chips that prevent asic manufacturers from getting an advantage 
(02:19:22 PM) needmoney90: Basically similar to if our Pow devs built asics in secret, but this is an affront to the other gpu miners and asic devs
(02:19:29 PM) hyc: ah, that detail wasn't apparent to me
(02:19:41 PM) needmoney90: Yeah, it's why there's such a shitstorm 
(02:20:07 PM) needmoney90: The big question is 'where did the code come from, and did nvidia/intel write it to cement their monopoly' 
(02:20:40 PM) needmoney90: I'm not taking any sides, just trying to present the current controversy
(02:20:51 PM) needmoney90: Nvidia/amd*
(02:21:02 PM) hyc: right
(02:22:05 PM) hyc: so basically ASIC makers are complaining at being crippled in terms of ProgPw
(02:22:17 PM) hyc: seems kinda like a non-controversy then
(02:22:22 PM) needmoney90: And probably old gpu holdersc
(02:22:27 PM) needmoney90: Anything previous Gen 
(02:22:34 PM) hyc: oh, because only new GPUs could run it
(02:22:38 PM) hyc: interesting
(02:22:38 PM) needmoney90: The new stuff, if the controversy is legit, will blow it out of the water 
(02:23:05 PM) moneromooo: So they're essentially ensuring at least a duopoly.
(02:23:15 PM) hyc: I've already seen complaints that pogpw runs much better on nvidia than current AMD
(02:24:05 PM) hyc: this friggin keyboard keeps dropping keystrokes on me
(02:25:12 PM) hyc: ok, that controversy aside, we have linzhi's unsubstantiated claims of being able to do a progpow asic 3-8x faster than GPUs. or something.
(02:25:26 PM) hyc: it's not really clear what their 3-8x actually refers to - speed, power, etc
(02:25:41 PM) needmoney90: moneromooo: it's all tied up with obsolescence of old hardware, who wrote the code/it's origins, and a lot of shit flinging from people who are heavily invested financially, and want the new software to be optimal on their specific hardware 
(02:26:09 PM) hyc: not too unlike monerocrusher on /r/monero
(02:26:51 PM) gingeropolous: gpus4evah
(02:26:59 PM) needmoney90:  I'm glad that I mentioned his conflict of interest (a couple people have taken to that and are calling him out now), though it's a bit unfortunate it came from a moderator account 
(02:27:23 PM) hyc: he's gotten pretty tiresome
(02:27:28 PM) needmoney90: I kind of wish just a normal user had mentioned it first, it puts him on the spot
(02:27:59 PM) hyc: well, it makes sense that you a mod would have spotted it sooner
(02:28:29 PM) gingeropolous: is anyone using progpow now? i always forget
(02:28:32 PM) needmoney90: He's clearly only in favor of something that works optimally on GPU, and it's pretty clear that anything GPU oriented is ASICable in a short time frame. Which means constant forks, for the sole purpose of maintaining GPU profitability. 
(02:28:44 PM) needmoney90: That seems entirely backwards
(02:28:48 PM) hyc: totally
(02:29:10 PM) hyc: gingeropolous: I think ETH will be the first, and I don't know their timeframe
(02:29:13 PM) needmoney90: The miners are here at our pleasure, we are not here at theirs 
(02:29:23 PM) gingeropolous: ^^ hear hear!
(02:29:27 PM) gingeropolous: or is it here here
(02:29:34 PM) hyc: as always - nobody gets to demand what code volunteers write
(02:31:47 PM) dEBRUYNE: I don't get why he doesn't find 1:1-1:1.5 acceptable
(02:31:55 PM) dEBRUYNE: CPUs are vastly harder to scale + have some additional requirements
(02:32:00 PM) hyc: gingeropolous: it sure would have been nice if ETH had deployed ProgPow by now
(02:32:16 PM) hyc: then we could sit back and observe how their ASIC story unfolds
(02:33:00 PM) hyc: but I get the impression a lot of others are waiting to see what happens in Monero :P
(02:33:43 PM) hyc: dEBRUYNE: agreed. from any perspective he's being unreasonable
(02:36:37 PM) moneromooo: Isn't Ethereum going PoS ?
(02:36:44 PM) moneromooo: Or went.
(02:36:46 PM) moneromooo: Or somehting.
(02:37:02 PM) hyc: soonTM
(02:37:34 PM) dEBRUYNE: Ethereum going PoS is like our soon^tm on steroids :-P
(02:39:12 PM) gethh: they are partialy PoS already, look at Vitalik the undoubt Proof of Starvation
(02:51:54 PM) tevador: RandomX full specs: https://github.com/tevador/RandomX/blob/dev/doc/specs.md[1]
(02:52:14 PM) tevador: design rationale: https://github.com/tevador/RandomX/blob/dev/doc/design.md[1] (possibly incomplete)
(02:52:49 PM) tevador: hyc sech can you review it?
(02:55:48 PM) tevador: gingeropolous Bitcoin Interest (lol) is using ProgPow
(02:57:24 PM) gingeropolous: so could one say that if cpus ever develop L4 cache, and its huge (say, 4 GBs), this could significantly improve RandomX performance?
(02:57:53 PM) tevador: yes, but it won't happen, at least not anytime soon
(02:58:06 PM) tevador: 4 GiB would be enormous for a single chip
(02:58:09 PM) gethh: cpus have l4 already, Power 9 for example
(02:58:11 PM) gingeropolous: well c'mon we gotta think that this is gonna be around for a century
(02:58:11 PM) moneromooo: Spam 4 GB L1d. Yaaaaay.
(02:59:05 PM) tevador: actually it would not significantly improve performance, just allow more parallel cores
(02:59:21 PM) gingeropolous: i guess the overarching concern is that randomx is designed for CPUs of the modern era. How will we adapt if/when cpu architecture has some breakthrough developments?
(02:59:22 PM) tevador: RandomX is not bottlenecked by Dataset reads
(02:59:47 PM) tevador: gingeropolous then it has to be modified accordingly
(03:00:28 PM) tevador: but I'm pretty sure the workload is so general that CPUs will always be good at it
(03:00:30 PM) gingeropolous: there's nothing we can design in on autopilot to change accordingly?
(03:00:47 PM) tevador: if you embed some AI into monerod
(03:00:49 PM) tevador: maybe
(03:00:50 PM) gingeropolous: and... what about.....
(03:00:54 PM) gingeropolous: quantum.......
(03:00:56 PM) gingeropolous: computers
(03:01:03 PM) gingeropolous: !!!###!#!##!#!#
(03:01:10 PM) moneromooo: I guess we can link to libquantumai.
(03:04:31 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(03:04:31 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(03:05:07 PM) tevador left the room (quit: Ping timeout: 240 seconds).
(03:05:13 PM) ArticMine: moneromooo ArticMine: does this drop show up when you run MONERO_USE_CNV4_JIT=1 ./build/release/tests/performance_tests/performance_tests --filter=\*slow\* ? <---- I take it this requires a build from source. I will do that and let you know late today or tomorrow.  
(03:06:25 PM) geonic: don't forget that Vitalik can always fire up his quantum computers and 51% attack us to oblivion
(03:06:28 PM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(03:07:31 PM) sech1: tevador no growing dataset in design yet?
(03:08:16 PM) sech1: ah, found it in specs.md
(03:08:38 PM) sech1: design.md doesn't mention it. It would be nice to add a couple sentences about it there.
(03:10:26 PM) ArticMine: On the GPL v3+ question I do believe we can use a linking exception that would allow the rest of the project to remain under our current license.  
(03:10:27 PM) fort3hlulz left the room (quit: Quit: Leaving).
(03:10:38 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(03:12:14 PM) ArticMine: Any one of the contributors to the GPL V3 code could potentially sue in potentially any jurisdiction. 
(03:12:55 PM) gingeropolous: fun find. https://www.theverge.com/2018/12/12/18137401/intel-foveros-3d-chip-stacking-10nm-roadmap-future[1]
(03:14:43 PM) gingeropolous: more recent methinks: https://www.theverge.com/2019/1/7/18173001/intel-lakefield-foveros-3d-chip-stacking-soc-design-ces-2019[1]
(03:15:05 PM) ArticMine: So if there are more than one contributer the potential legal risk to an infringer is very significant. Also I agree to avoid the GPL V3+ entanglement the algorithm would have to be implemented in a clean room  
(03:15:16 PM) hyc: tevador: pulling now
(03:16:42 PM) sech1: tevador "12. spAddr0 and spAddr1 are both set to zero" Is it correct? They're XORed on the next iteration, what's the point of XORing with 0?
(03:17:03 PM) ArticMine: 3d Chips is by the way well in the pipeline. There are likely already in your cellphone or SSD drive
(03:18:48 PM) ArticMine: This is likely a game changer that will favor CPUs in the near future. Something we must consider before giving up the fight with SHA-3
(03:18:52 PM) gingeropolous: i guess regarding randomx, it just depends on how many randomx vms can fit in the CPU
(03:19:49 PM) sech1: and I don't see in "4.6.2 Loop execution" how dataset prefetch is helping, "mx" is used for prefetch, but spAddrN is used for reading from dataset. And prefetch is done on one 64-byte line while read is done from two (?) random 64-byte lines
(03:20:01 PM) hyc: yeah I read about that stacking stuff a month ago https://semiaccurate.com/2019/02/11/what-is-intels-foveros-tech-and-what-isnt-it/
(03:20:30 PM) tevador: sech1 spAddr is used for reading from the scratchpad
(03:20:52 PM) tevador: they are xored because on the first iteration they are not zero
(03:21:34 PM) ArticMine: I also find the ETH results of ASICs co existing with GPUs very encouraging for RandomX. This can easily happen if the ASIC advantage is down to say 2x or so
(03:22:38 PM) ArticMine: I would not consider such a situation a failure for RandomX quite the opposite.
(03:24:36 PM) hyc: agreed. everybody says "keep ASICs off" but I've been consistent in saying "reduce ASIC advantage" because we know ASICs can always be made
(03:26:47 PM) hyc: tevador: technically a loop requires a branch instruction, so this is not 100% branchless
(03:26:55 PM) hyc: not sure what is a better way to word that though
(03:27:24 PM) hyc: do we instead mean "no conditional branches" ?
(03:28:20 PM) sech1: loops with fixed iterations can be always predicted, so they don't count
(03:28:28 PM) hyc: ok
(03:30:03 PM) spaced0ut left the room (quit: Ping timeout: 245 seconds).
(03:30:40 PM) sech1: "6.4 Dataset block generation" What worries me is that there is no avalanche effect between c0-c7 and only c0 is used as index
(03:31:49 PM) sech1: maybe define SquareHash(c0, ..., cN) where 128-bit product is used to XOR adjacent values together?
(03:32:57 PM) sech1: i.e. c0 is multiplied on 1st iteration as in SquareHash then high 64 bits are also XORed with c1
(03:33:03 PM) sech1: then c1 is used on the next step and so on
(03:39:18 PM) sech1: "3.2 Generator" "During each output iteration, every column is decrypted ... with one AES round" One AES round is not enough for RNG
(03:39:33 PM) sech1: Adjacent values will be highly correlated
(03:39:40 PM) sech1: 10 rounds is minimum
(03:41:52 PM) sech1: So basically scratchpad generation is similar to Cryptonight, but with only 1 AES round
(03:41:59 PM) sech1: Not sure if it's safe
(03:58:34 PM) sech1: On the other hand, 4 AES instructions to generate 64 bytes = 4 clock cycles (assuming 1 independent AES can start every clock cycle)
(03:59:42 PM) sech1: 131072 cycles in total, or ~0.03 ms on CPU. We can add some more AES for better scratchpad generation without hurting hashrate much.
(04:04:28 PM) sech1: plus, CPU = ASIC for AES, it can do 1 AES/cycle at 4+ GHz. Ryzen can even do 2 AES/cycle. So this won't be faster on ASIC.
(04:10:43 PM) sgp_: Can I get some quick feedback on this upgrade schedule diagram before I share it in the GitHub issue? https://usercontent.irccloud-cdn.com/file/mUDfiMlX/Monero%20PoW%20rough%20plan[1]
(04:12:07 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(04:13:01 PM) lafudoci left the room (quit: Read error: Connection reset by peer).
(04:13:13 PM) hyc: I guess as a high level approach it looks ok
(04:13:34 PM) hyc: but I would collapse the two ASIC diamonds
(04:13:46 PM) hyc: "Are there hyper-efficient ASICs?"
(04:14:03 PM) sgp_: fair, I can do that
(04:14:03 PM) hyc: we don't care if there are just *comparable* ASICs
(04:14:58 PM) dEBRUYNE: It's not a problem as long as they can coexist
(04:15:09 PM) dEBRUYNE: sgp_: Agree with hyc btw (on the comment)
(04:15:31 PM) sgp_: new version: https://usercontent.irccloud-cdn.com/file/L6yBNF35/Monero%20PoW%20rough%20plan[1]
(04:15:56 PM) geonic: looks bueno
(04:16:46 PM) dEBRUYNE: geonic: I'll write a longer comment on Github later, but I am not saying we should precommit if there is a lot of contention
(04:16:58 PM) dEBRUYNE: We should only precommit on a course of action for which is community consensus
(04:17:01 PM) sech1: So this diagram means that if RandomX is adopted it'll be main PoW as long as there are not super-fast ASICs?
(04:17:11 PM) sech1: So indefenitely if it does what it promises?
(04:17:26 PM) hyc: that would be my expectation
(04:17:36 PM) hyc: there's no reason to adopt ASICs if randomX keeps working
(04:17:39 PM) moneromooo: I have to say I really dislike these attempts to force things ahead of time. 
(04:17:46 PM) hyc: ^^
(04:17:47 PM) hyc: me too
(04:18:07 PM) moneromooo: And mostly ignore them.
(04:20:19 PM) sgp_: moneromooo: I think it's good to plan, but we don't need to hold these as firm decisions
(04:21:35 PM) geonic: dEBRUYNE: my argument was that future information is unknowable and we're at a huge disadvantage by making a decision without access to that information
(04:21:58 PM) needmoney90: As I said in reddit (post now removed) 
(04:22:07 PM) dEBRUYNE: Likewise we are at a huge disadvantage if we have to make this decision if the ecosystem is 10 times bigger
(04:22:11 PM) needmoney90: Any sort of precommitment is unable to take into account the future makeup of the community, and the progress that has occurred on asic resistant Pow algorithms. While it seems like a good idea, I know that the me now cannot speak for the me in two years, let alone for the rest of the community.
(04:22:11 PM) needmoney90: One example is the Hong Kong agreement. The project's leads and community can express strong opinions on how they feel at this very moment, but any sort of 'official' precommitment is misguided, in my opinion. 
(04:22:44 PM) hyc: agreed
(04:22:54 PM) sgp_: dEBRUYNE: we will need to make that tough decision later anyway. I like to think that we'll be better off if we begin those discussions with a plan
(04:23:16 PM) hyc: a rough plan is fine
(04:23:27 PM) hyc: saying "we will definitely adopt SHA3 in 2 years" makes no sense to me
(04:24:04 PM) sgp_: yeah, I think there are too many factors. It's better to explain the reasoning behind the conditions necessary for us to support certain actions
(04:24:09 PM) needmoney90:  Precommitment in this space, to me, is including the code in a future release 
(04:24:21 PM) needmoney90: If it's not in a client and being voted on by miners, it's not precommitted
(04:24:49 PM) needmoney90: Meh, there's a whole process of precommitment 
(04:24:54 PM) hyc: right - we need a clear definition of what is a failure, what will trigger a new PoW change.
(04:24:55 PM) needmoney90: Github comments, appeals to community 
(04:25:11 PM) needmoney90: Each stage being more and more 'official' 
(04:25:52 PM) needmoney90: Vp11 makes a good point, that if we adopt sha3, we close the door to asic resistance forever 
(04:25:58 PM) needmoney90: R&D will no longer be done 
(04:26:35 PM) needmoney90: If we at least maintain the veneer of asic resistance, with periodic tweaks (even every year) to break the existing ones, we leave the door open to future advances in technology that let us stave them off potentially forever 
(04:27:17 PM) needmoney90: And I think that's a very good point that shouldn't be taken lightly 
(04:27:39 PM) geonic: there's enough plurality of opinion to consider this subject contentious and forget any sort of precommitment. let's think in terms of an action plan - sgp's chart is a good start
(04:28:01 PM) needmoney90: Welcome to  b l o c k c h a i n
(04:28:07 PM) tevador: sech1 do you think it's a problem if c0-c7 do not propagate? maybe we could cycle the index c0-c7-c0-c7 during the 16 iterations?
(04:28:36 PM) sech1: yes, that's what I suggest. To cycle the index
(04:28:55 PM) tevador: sech1 "10 rounds is minimum" not really, it's for encryption and big overkill for RNG
(04:28:56 PM) sech1: and maybe also add XOR with the next index after each mul-add
(04:29:20 PM) sech1: CPU can do this XOR in parallel, it has enough ALUs
(04:29:23 PM) tevador: already 2 AES rounds achieve full avalanche, you can find it in the paper from the authors
(04:30:02 PM) sech1: 2 rounds is enough then
(04:30:11 PM) tevador: but it's too slow
(04:30:23 PM) tevador: it will be 2x slower, so 200 us instead of 100
(04:30:48 PM) tevador: do you have some attack vector against 1 round?
(04:31:06 PM) sech1: I don't know, maybe it's not that important. It's only initial scratchpad
(04:31:09 PM) tevador: we just need some pseudorandom data, quality is not really important here
(04:31:55 PM) tevador: it just have to be close enough to random and nonzero
(04:32:48 PM) moneromooo: < hyc> saying "we will definitely adopt SHA3 in 2 years" makes no sense to me
(04:33:04 PM) moneromooo: I think it would make sense if we've already given up. Not before that.
(04:33:23 PM) moneromooo: And we might give up. Just... not yet IMHO.
(04:33:31 PM) hyc: yes. no sense at this point in time
(04:33:41 PM) dEBRUYNE: I don't think people want to throw in the towel already
(04:33:48 PM) dEBRUYNE: It's more of a matter of "what to do if RandomX fails"
(04:33:54 PM) moneromooo: Some do. stoffu, for instance.
(04:34:02 PM) sgp_: yes
(04:35:00 PM) moneromooo: with good arguments, I might add.
(04:35:21 PM) sech1: I guess people were discouraged by CNv2 failure. The sentiment would be different now if there were no CNv2 ASICs.
(04:35:31 PM) sech1: CNv2 was too weak in retrospective
(04:35:41 PM) moneromooo: Anyway, I think for now I'm thinking there will be a CNv4 tweak before randomx.
(04:35:50 PM) sech1: Not that it's my fault entirely, Cryptonight design itself is too weak now
(04:35:53 PM) moneromooo: But we'll see.
(04:36:38 PM) hyc: tevador: spec 3.2, 3.3 might want to explain where these round keys and initial state values came from, how they were chosen
(04:36:48 PM) sech1: CNv4 may hold better than CNv2 thanks to random code, but tweaking it makes no sense
(04:36:58 PM) moneromooo: Why does it not ?
(04:37:01 PM) sech1: any CNv4 ASIC can handle tweaks
(04:37:07 PM) sech1: because it must be programmable
(04:37:22 PM) sech1: unless we do some radical tweaks
(04:37:32 PM) sech1: like adding huge read-only dataset to it
(04:37:32 PM) tevador: hyc: randomly selected constants
(04:37:44 PM) moneromooo: Well, I have an idea. It might be bollocks, but we'll see closer to the time.
(04:38:10 PM) hyc: tevador: fair enough. but in any cryptographic spec, the origin of constants is usually ecplicitly stated.
(04:38:14 PM) hyc: magc numbers 'n'all.
(04:38:27 PM) hyc: likewise the two extra keys in 3.3, the add offset in 3.4
(04:38:28 PM) sech1: yeah, magic numbers are no-go for cryptographics hashes
(04:38:32 PM) sech1: they raise suspicion
(04:38:54 PM) sech1: like they can be inherent (or implanted) weakness in these numbers
(04:38:57 PM) tevador: firstly, it's not a cryptographic hash
(04:39:10 PM) tevador: secondly, what do you suggest?
(04:39:23 PM) sech1: I'm just talking in general
(04:39:29 PM) hyc: "these numbers were obtained by rolling 16-sided dice 32 times"
(04:39:42 PM) hyc: it doesn't really matter what the origin is, just state what it is.
(04:42:37 PM) tevador: or we can select from the blockchain
(04:42:55 PM) moneromooo: It *does* matter. Make them the keccak from some arbitrary constant.
(04:43:12 PM) tevador: ok, fair enough
(04:43:15 PM) tevador: Blake2b then
(04:43:27 PM) moneromooo: "rolling 16-sided dice 32 times" is unverifiable. If they're keccak from 0x42, it means they're not crafted, or you'd know preimages.
(04:43:42 PM) hyc: ^^ ok
(04:46:01 PM) hyc: section 5.1, just to be clear, the instruction word is little-endian?
(04:46:56 PM) tevador: yes, it's stated in chapter 4 that all data is little endian
(04:47:06 PM) hyc: ok, I see that now
(04:51:46 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(04:52:43 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1006::19c] entered the room.
(04:56:56 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(05:04:21 PM) hyc: tevador I don't have any further comments or questions at the moment. looks good.
(05:09:31 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(05:18:01 PM) sech1: me neither, but I'll ready through it again tomorrow
(05:18:09 PM) sech1: *read through
(05:32:25 PM) sech1: tevador "because DRAM cannot do more than about 25 million random accesses per second per channel." That needs clarification
(05:32:36 PM) sech1: DRAM is organized a bit more complex
(05:33:13 PM) sech1: There are also a number of DRAM banks/pages on each channel and latency depends on access pattern and if we hit same banks/pages
(05:34:13 PM) tevador: it's a bit simplified statement, it's 25M per access port
(05:34:25 PM) tevador: for fully random accesses
(05:34:30 PM) sech1: where does this number come from?
(05:34:31 PM) hyc: good point. at least mention this is ddr4
(05:34:50 PM) tevador: should be the same for DDR3 also
(05:35:16 PM) tevador: actually DDR4 has internal banks, so it behaves like it has 2-4 access ports per channel
(05:35:52 PM) sech1: "DDR4-2400" actually meand 2400 mega-transfers per second
(05:35:55 PM) sech1: not 25M
(05:35:59 PM) sech1: *means
(05:36:02 PM) hyc: ok, so give the context "assuming ddrX etc"
(05:36:16 PM) tevador: sech1 that's for sequential access
(05:36:36 PM) tevador: and assumes you read the whole row each time
(05:36:39 PM) sech1: 64-byte access consumes 8 transfers if I count right
(05:36:41 PM) hyc: we need to identify all of our present-day assumptions that may change for future tech
(05:37:34 PM) tevador: the 25M ffigure is calculated from the time is takes to: open row, read, precharge
(05:37:53 PM) tevador: precharge means writing the row back into the array
(05:38:21 PM) sech1: Have you reviewed other RAM types? 10 years from now we might have some RAM that is much faster at random access and RandomX will be just compute-bound, not memory-hard
(05:38:51 PM) sech1: I guess we need dataset growth to leverage this
(05:38:56 PM) hyc: I think MRAM will not have these same constraints
(05:38:56 PM) tevador: afaik it's a general limitation of DRAM, so unless there is completely new type of RAM
(05:39:00 PM) tevador: this will apply to all
(05:39:21 PM) tevador: hyc: yes, possibly
(05:39:40 PM) tevador: how far is MRAM from some actual product?
(05:39:45 PM) hyc: in my routine research related to LMDB I spend a lot of time looking at upcoming NVRAM technologies. MRAM is on par with DRAM speed, infinite endurance
(05:39:52 PM) hyc: it is 16x less dense than DRAM today
(05:40:05 PM) hyc: but it is already being used in SSD caches, RAID controller caches, etc
(05:40:15 PM) tevador: so even worse than SRAM in terms of density
(05:40:28 PM) hyc: hm, yes for now
(05:40:29 PM) tevador: except it's not volatile
(05:40:37 PM) hyc: right.
(05:40:55 PM) hyc: there was a paper from Toshiba recently saying that on 5nm process, MRAM will be superior to SRAM
(05:41:08 PM) hyc: speed/power/area.
(05:41:51 PM) tevador: I guess we don't expect RandomX to last a decate anyways, do we?
(05:42:08 PM) sech1: Why not?
(05:42:09 PM) hyc: one can dream ;)
(05:42:25 PM) hyc: I don't see any fundamental feature of randomX that will weaken over time
(05:43:25 PM) tevador: cache:core ratio may change for CPUs
(05:43:32 PM) tevador: for example
(05:43:50 PM) tevador: or future CPUs can have 128 byte cache lines
(05:44:01 PM) hyc: true. Itanium had 128byte
(05:44:15 PM) hyc: and apparently modern Intel CPUs now prefetch 2 cachelines at a time
(05:44:27 PM) fort3hlulz_ left the room (quit: Ping timeout: 240 seconds).
(05:44:28 PM) tevador: yes, but it can be disabled
(05:44:38 PM) sech1: https://www.mram-info.com/everspin-starts-ship-customer-samples-its-28nm-1gb-stt-mram-chips[1]
(05:44:47 PM) sech1: So we need 32 such chips for RandomX?
(05:45:25 PM) tevador: price per Gb?
(05:45:46 PM) hyc: I've never found a price quote
(05:46:14 PM) tevador: it means it's too high to publish
(05:46:39 PM) hyc: note they're on GLoFo 28nm process. if they get down to 10nm like current Samsung DRAM, I think they will eclipse DRAM density
(05:47:40 PM) hyc: this is the first commercial product, using 256Mb MRAM http://www.smartm.com/products/dram/nvNITRO_card.asp
(05:48:42 PM) sech1: I found this: https://eu.mouser.com/Search/Refine?Ntk=P_MarCom&Ntt=126414092[1]
(05:49:01 PM) sech1: looks like > 1000 euro for 1 Gb chip if it scales the same
(05:49:28 PM) hyc: I think this is their older toggle-MRAM tech
(05:49:38 PM) hyc: not spin torque transfer MRAM
(05:53:05 PM) tevador: STT MRAM expected to catch up with DRAM density in 2024
(05:53:33 PM) sech1: Well, by that time CPUs will also start using it
(05:55:24 PM) tevador: I guess we would have to tweak RandomX if CPUs/RAM change too much
(05:55:52 PM) hyc: so - 5years
(05:56:15 PM) hyc: not intolerable ;)
(05:56:31 PM) tevador: better than 2x per year I guess
(05:56:37 PM) hyc: definitely
(05:59:37 PM) tevador: hyc: I have fixed the magic constants: https://github.com/tevador/RandomX/commit/a2e7e05c401ef86fb40ffaa5b48ecdcd2ad4b4d7[1]
(05:59:57 PM) tevador: recipe how to calculate them is included
(06:02:01 PM) hyc: looks good
(06:02:56 PM) hyc: in design.md, 9507361525245169745 probably should add a note "See specs 3.4"
(06:04:25 PM) fort3hlulz [~setsimmo@173.38.117.89] entered the room.
(06:05:13 PM) moneromooo: I choose 0x000C1A0013370000
(06:06:45 PM) tevador: too many 0
(06:06:47 PM) tevador: :P
(06:48:08 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(07:36:47 PM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(07:54:47 PM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(07:55:27 PM) sech1 left the room (quit: Quit: Leaving).
(08:04:02 PM) kopite7 left the room (quit: Ping timeout: 246 seconds).
(08:20:51 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:24:39 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(08:37:42 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(08:39:56 PM) needmoney90: Has linzhi-sonia made any progress reading the specs? 
(10:07:50 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(02:27:56 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:32:47 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:45:29 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:18:02 AM) dEBRUYNE left the room ("Leaving").
(03:31:16 AM) sech1 left the room (quit: Quit: Leaving).
(03:40:34 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:43:22 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(03:45:46 AM) ArticMine left the room (quit: Ping timeout: 255 seconds).
(03:58:26 AM) ArticMine [~ArticMine@S0106ac202ecaeb73.vn.shawcable.net] entered the room.
(04:18:27 AM) midipoet [uid316937@gateway/web/irccloud.com/x-zaqyrjansrioqppp] entered the room.
(04:20:50 AM) sech1: tevador Table 5.2.1. Do I understand it right that random program only reads from cache?
(04:20:58 AM) sech1: I mean these 256 instructions
(04:21:19 AM) sech1: Load-Store unit is optimized for 2:1 read:write ratio, this will be sub-optimal on CPUs
(04:21:49 AM) sech1: We need to have 2:1 read:write ratio for at least for L1
(04:22:36 AM) sech1: ASIC can even have specialized "load-only unit" for 256 instructions, not the full LSU
(04:24:06 AM) sech1: All complex things like handling memory dependencies go away if we only read from cache, that makes LSU logic much simpler for ASIC
(04:32:15 AM) sech1: Yep, 2 load + 1 store each cycle (L1 cache only): https://cdn.arstechnica.net/wp-content/uploads/2017/03/zen-core.png[1]
(04:34:03 AM) sech1: From Agner's manuals: "The data cache has two 128-bit ports which can be used for either read or write. It can do
(04:34:03 AM) sech1:  two reads or one read and one write in the same clock cycle"
(04:36:10 AM) sech1: Right now we have ~24 reads on average, I suggest to change it to 16 reads + 8 writes (writes go to L1 only)
(04:41:20 AM) sech1: For Intel Skylake (and newer CPUs): "The theoretical maximum throughput is two cache reads and one write per clock cycle."
(04:55:14 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(04:59:48 AM) sech1: You can use reserved bits in "mod" instruction encoding flag to define if it's a read or a write
(05:03:15 AM) sech1: Something like if mod.mem != 0 and reserved bits 5-6 are 0 (25% probability) then we also write instruction result back into L1 (same location)
(05:06:41 AM) sech1: so it will be read-modify-write instruction essentially
(05:09:10 AM) sech1: or better have 50% L1 accesses read-only and the other 50% read-modify-write
(05:09:19 AM) sech1: then it will be exactly 2:1 read:write ratio
(05:09:55 AM) sech1: so you can use only bit 5 in "mod" flag
(05:19:59 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:21:51 AM) lafudoci [~lafudoci@122-116-59-198.HINET-IP.hinet.net] entered the room.
(05:46:37 AM) sech1: hmm, I guess all scratchpad accesses can be 50% read-only and 50% read-modify-write because data always ends up in L1 after the "read" part in "read-modify-write"
(05:53:48 AM) linzhi-sonia: needmoney90: I don't think I can provide much valuable input at this time. The conversations here are respectful and of high quality!
(05:54:06 AM) linzhi-sonia: has anyone compared the work/verification asymmetry between CNv4 and RandomX?
(05:58:06 AM) linzhi-sonia: the reason why I like RandomX over CNv4 is maybe a little different from others :) I like the fact that it adds the memory dimension to PoW. You can think of a chip as made of 3 parts: logic, memory, IO. First-gen PoW is logic-only. Second-gen PoW is logic+memory (Ethash, progpow, randomx, all "memory-hard" algos). Third-gen will hopefully also include IO.
(05:58:11 AM) sech1: linzhi-sonia https://github.com/tevador/RandomX/issues/25[1]
(05:59:05 AM) sech1: Fast CPU spends 25 ms for verification in light mode vs 12-15 ms on Cryptonight
(05:59:34 AM) sech1: but verification is not optimized properly yet, I think it can go down to < 20 ms if we add JIT compilation to light mode
(06:01:27 AM) linzhi-sonia: ok! I just thought that asymmetry ratio should be understood, documented, and part of the reasoning for switching to RandomX
(06:01:40 AM) linzhi-sonia: which it looks like you are doing
(06:01:54 AM) linzhi-sonia: because the asymmetry is a very important factor towards decentralization
(06:02:07 AM) linzhi-sonia: so if the asymmetry worsens, that's bad for decentralization. I think you can say that, right?
(06:02:51 AM) linzhi-sonia: that doesn't mean an algo should be rejected, but it should be documented properly and you decide "yes, we accept that xx% verification slowdown because we have benefits A, B, C which justify the verification slowdown"
(06:02:52 AM) sech1: Yes, but with enough free RAM (> 4 GB) we can use fast mode for verification (2-3 ms) which is an improvement
(06:03:07 AM) linzhi-sonia: all good. I just think the asymmetry is important.
(06:03:14 AM) sech1: at least when syncing blockchain and verifying consecutive blocks
(06:03:16 AM) linzhi-sonia: if we care about decentralization
(06:03:33 AM) linzhi-sonia: some people forget that or try to not talk about it or try to dismiss the point
(06:03:47 AM) linzhi-sonia: I think it should be documented and it's an important spec of any PoW algo
(06:04:33 AM) linzhi-sonia: but it looks like you guys are already aware of this and trying to bring the randomx verification time down - great!
(06:34:14 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(08:10:27 AM) gingeropolous: ugh monerocrusher spammed that github with his .... stuff
(08:15:16 AM) dEBRUYNE: Little birdy told me the plan is to fork each week, starting Jan 1 2019
(09:04:48 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(09:17:14 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:a5ba:d1f8:ea11:b082] entered the room.
(09:57:12 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:58:26 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:12:38 AM) gingeropolous: i really think we should revisit this whole thing after seeing randomx perform in the wild
(11:13:00 AM) gingeropolous: i don't see how we'd be in any usefully different footing
(11:13:32 AM) gingeropolous: help us tevador-one-kanobi, you're our only hope
(11:13:43 AM) gingeropolous: the empire is approaching
(11:27:56 AM) hyc: sech1: Intel Xeon with on-chip FPGA is 2x cost of regular Xeon
(11:28:06 AM) hyc: I don't think FPGA is really accessible
(11:28:08 AM) sech1: for now
(11:28:14 AM) sech1: If it goes mainstream...
(11:28:19 AM) hyc: Intel bought Altera in 2015
(11:28:29 AM) hyc: FPGAs are still tiny niche market
(11:28:36 AM) hyc: small numbers, high prices 
(11:28:44 AM) sech1: You underestimate it. Do you have 4K TV? It has FPGA built-in
(11:29:08 AM) sech1: FPGAs are produced in huge quantities
(11:29:17 AM) sech1: all high-performance network routers have them too
(11:29:19 AM) sech1: for packet processing
(11:29:43 AM) hyc: yes.... but not many end up on consumer market by themselves
(11:29:50 AM) hyc: millions get ordered for specific OEM devices
(11:30:12 AM) sech1: Yes, someone can also order them... to make mining hardware
(11:30:24 AM) sech1: If Monero decides to do this
(11:30:41 AM) hyc: there was a natural evolution from FPGA to ASIC in bitcoin already, no?
(11:30:46 AM) sech1: Making FPGA design and ordering chips is easier for startups
(11:31:17 AM) sech1: Bitcoin is a bad example, SHA256 PoW wasn't designed for FPGA
(11:33:15 AM) sech1: FPGA-only PoW can exploit reprogrammability and specific blocks (DSPs for example) to use 100% of FPGA chip and make ASIC similar to FPGA and the same level of performance
(11:33:31 AM) sech1: *force ASIC to be similar
(11:33:58 AM) hyc: FPGA isn't instantly, dynamically reprogrammable. 
(11:34:13 AM) hyc: IIRC it's quite slow, like EPROM slow. no?
(11:35:21 AM) sech1: there's also dynamic reconfiguration that takes < 1 second
(11:35:34 AM) sech1: It's not full reprogramming, but it can change internal logic significantly
(11:36:03 AM) sech1: I'm not an expert in this. I asked GPUHoarder about what exactly can be done there.
(11:36:55 AM) LSDog left the room (quit: Ping timeout: 255 seconds).
(11:37:01 AM) LSDog_ [~LSDog@unaffiliated/lsdog] entered the room.
(11:38:06 AM) hyc: and we'd probably get accused of playing favorites ... FPGAs have a widely varying set of functional units
(11:38:58 AM) hyc: if we use 100% of a Xilinx VU9P today, that puts every other model at a disadvantage
(11:39:17 AM) hyc: and it even gives a disadvantage to migrate to newer models in the future
(11:47:50 AM) sech1: I'm sure a high-level algorithm can be designed that allows efficient implementations on all current FPGAs. We need to ask actual FPGA designers.
(11:48:27 AM) sech1: Anyway, it's only the alternative to SHA3 and ASICs. If I were given this choice, I would prefer to buy FPGA which is general purpose, not ASIC.
(11:48:46 AM) sech1: The main target here is to have RandomX running for as long as possible.
(11:49:02 AM) hyc: got ya. agreed.
(11:50:17 AM) sech1: It would be fun actually. One day mine Monero on your FPGA, next day to some 8K video encoding for your family archive, using the same FPGA.
(11:50:53 AM) sech1: I hope 8K video will be mainstream by 2022, lol
(11:51:26 AM) hyc: heh. I have no 4K TV by the way. No TV at all. There's a ridiculous 180euro/yr TV license fee here in Ireland
(11:51:58 AM) hyc: I have a 1280x800 video projector that I occasionally use to watch streamed videos ;)
(11:52:28 AM) hyc: looks good enough against my wall, 4K would be wasted
(11:54:43 AM) klp: I suggested yesterday that you can also consider google's TPU as an asic for brand new pow algo.
(11:54:55 AM) sech1: I have 55" 4K TV, but use it as a monitor. Bought it during Black Friday sale, don't care about TV fee since it's obligatory for everyone now in Sweden.
(11:55:01 AM) hyc: TPU, not really
(11:58:56 AM) hyc: Is Google going to sell TPUs openly? Would you willingly buy a processor from Google?
(11:59:05 AM) hyc: I certainly would not 
(11:59:29 AM) sech1: They don't sell and their TPUs are not bit-accurate. AI learning tolerates small errors.
(12:00:10 PM) hyc: right, they're using 8-bit integer multipliers
(12:00:19 PM) hyc: it is really s lobotmized DSP
(12:04:32 PM) hyc: it's still instructive to read about TPU design, what they omitted, etc. https://cloud.google.com/blog/products/gcp/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu
(12:05:17 PM) midipoet: hyc: the rte radio documentaries are pretty good, and some of their sports coverage. not sure it merits the licence fee though, granted.
(12:05:57 PM) midipoet: https://www.rte.ie/radio1/doconone/[1]
(12:21:49 PM) sech1 left the room (quit: Quit: Leaving).
(12:31:25 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:45:19 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 255 seconds).
(12:49:56 PM) hyc: I'm quite doubtful that you cna have an FPGA-only algo that ASICs can't excel at.
(12:50:08 PM) hyc: ASICs will always have a logic density advantage
(12:50:20 PM) hyc: smaller chip area, lower power cost
(12:50:31 PM) needmoney90: Is lower power cost guaranteed? 
(12:50:35 PM) needmoney90: If the process is the same 
(12:50:48 PM) needmoney90: I can see the clock speed argument because parts are closer together 
(12:50:55 PM) needmoney90: But I didn't think energy usage would be impacted 
(12:50:58 PM) hyc: well.... lcocks can go higher actually
(12:51:06 PM) needmoney90: Lcocks
(12:51:12 PM) hyc: so ASIC can have a perf advantage too  clocks
(12:51:13 PM) needmoney90: That's a new one
(12:51:36 PM) needmoney90: Yeah, I know the clock rates are a thing, but power usage feels tenuous at the same process
(12:51:38 PM) hyc: but it can definitely have a smaller footprint
(12:52:29 PM) hyc: higher clocks would eat more power of course, and could eat up the power advantage
(12:52:43 PM) needmoney90: That would be offset by hashrate 
(12:52:47 PM) needmoney90: Er wait
(12:52:49 PM) needmoney90: You're right 
(12:52:57 PM) needmoney90: There's an efficiency thing when you scale up 
(12:53:37 PM) hyc: hmmm. 
(01:04:34 PM) cjd: 16:49 < hyc> I'm quite doubtful that you cna have an FPGA-only algo that ASICs can't excel at   <-- just saw this but ... wouldn't "random circuit" basically favor fpgas over anything ?
(01:20:59 PM) tevador: sech1: there is a dedicated store instruction (5.4.3)
(01:21:30 PM) tevador: there are 39 reads and 16 stores on average per program
(01:22:44 PM) sech1: Oh, didn't see it. 39 reads and 16 stores is perfect
(01:23:22 PM) sech1: hyc I wait for FPGA designers response, but I also think that "random circuit" algo can't be made faster on an ASIC
(01:23:22 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:23:53 PM) tevador: I guess I should mention this in the design doc
(01:24:48 PM) tevador: btw sech1 did GPUHoarder say anything about RandomX?
(01:24:57 PM) sech1: No, not yet
(01:25:15 PM) hyc: who esle can we ask to review it?
(01:25:20 PM) hyc: who else
(01:25:25 PM) tevador: "AirSquirrels" that's him?
(01:25:59 PM) sech1: GPUHoarder, yes
(01:27:38 PM) tevador: yes, we should ask him for a review
(01:27:58 PM) tevador: I have asked tim olson to do a review also
(01:28:16 PM) hyc: great, will he have time to do so?
(01:28:46 PM) sech1: Probably no unless we pay for it
(01:28:52 PM) sech1: He's swamped with work now
(01:28:54 PM) tevador: no reply yet, but he said he could do some review for free
(01:28:58 PM) tevador: last month
(01:29:08 PM) tevador: he refused to get paid actually
(01:29:17 PM) sech1: That's nice of him
(01:29:41 PM) tevador: the reason is he didn't want his company's reputation damaged if RandomX fails
(01:29:56 PM) tevador: so he will do only "unofficial" free review
(01:30:43 PM) dEBRUYNE: So we have GPUHoarder + tim olsen that can review stuff from the hardware side basically right?
(01:31:19 PM) tevador: yes
(01:31:47 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(01:32:17 PM) tevador: the github issue kinda exploded
(01:32:45 PM) dEBRUYNE: Seems like an understatement :P
(01:32:48 PM) hyc: yeah but I think the surge is over
(01:33:51 PM) dEBRUYNE: Btw, I said this to hyc in PM, but I think currently the path of least resistance is either of these two options:
(01:33:53 PM) dEBRUYNE: <dEBRUYNE> 1. RandomX -> if fails SHA3
(01:33:53 PM) dEBRUYNE: <dEBRUYNE> 2. RandomX -> SHA3 in May 2022, even if RandomX works
(01:34:38 PM) hyc: I've already said <2> is stupid, if it's still working there's no good reason to change it.
(01:35:23 PM) hyc: I kinda like where sech1 is going with the FPGA angle
(01:35:23 PM) dEBRUYNE: There were arguments against that, but I don't think we have to rehash them here
(01:35:35 PM) dEBRUYNE: I am trying to find the options where we can come to an agreement
(01:35:54 PM) hyc: we might also declare "we will only endorse ASIC makers who guarantee to buyback their old models when selling new models"
(01:36:04 PM) hyc: or who guarantee recycling, or something
(01:36:20 PM) dEBRUYNE: Seems too much of a slippery slope
(01:36:23 PM) sech1: We're not in a fairy tale world, lol
(01:36:29 PM) sech1: No ASIC maker would go for this
(01:36:41 PM) tevador: they should at least provide 2 year warrany for starters
(01:36:43 PM) hyc: innosilicon is already doing it, actually
(01:36:44 PM) moneromooo: All ASIC makers would go for this, than flake out.
(01:37:21 PM) hyc: you can pre-order their future ASIC, take delivery of current gen, then send it back when new unit ships
(01:39:37 PM) cjd: What's SHA3 ?  like .. just raw NIST SHA3 ?
(01:40:07 PM) hyc: I'd expect it to iterate a few thousand times
(01:40:19 PM) hyc: we don't need to hit terahash/sec right out of the gate
(01:43:36 PM) tevador: why not? if we do SHA-3, we should do just 1 hash for fast verification
(01:44:26 PM) cjd: how is that different from just doing sha256 though ?
(01:45:38 PM) hyc: sha256 is already widely deployed for BTC. we'd be vulnerable to 51% attack immediately
(01:46:27 PM) tevador: also sha3 is simpler and not vulnerable to some attacks like length extension
(01:46:35 PM) tevador: no reason to use sha256 nowadays
(01:46:59 PM) cjd: So basically giving up on the idea of CPU hardness ?
(01:47:19 PM) tevador: either in 2022 or when RandomX provably fails
(01:47:47 PM) cjd: what happens in 2022 ?
(01:47:55 PM) tevador: tail emission kicks in
(01:47:56 PM) cjd: sorry if these are dumb questions
(01:48:47 PM) cjd: ahh ok
(02:01:08 PM) hyc: imagine starting with the design of a 6502 and building a RandomX ASIC
(02:01:41 PM) hyc: single-cycle instructions, all hardwired, no microcode
(02:05:01 PM) hyc: as another fun diversion, imagine trying to write a meaninful program in randomX machine code
(02:07:20 PM) tevador: lol, X16R
(02:08:08 PM) tevador: is he serious?
(02:12:51 PM) hyc: well... requiring a large chip area *is* a good deterrent
(02:14:17 PM) hyc: interesting edit to his comment
(02:14:18 PM) tevador: is X11 significantly smaller?
(02:14:37 PM) hyc: hm, dunno
(02:14:40 PM) tevador: X11 = dash, which is ASIC only afaik
(02:16:20 PM) tevador: I think he means that the chip would require 16x16 hashes in hardware, which is not true
(02:18:10 PM) hyc: rather poor of him to allude to other posts explaining himself, and not link any
(02:35:15 PM) hyc: Hm, so SHA3 ASICs are already for sale? who is using them?
(02:42:49 PM) dEBRUYNE: There are a few small coins that use SHA3
(02:43:00 PM) dEBRUYNE: Maxcoin is one of them afaik
(02:45:55 PM) wowario: lol, cringeworthy perv lineup https://maxcoinproject.org/#selfies[1]
(02:52:35 PM) gethh left the room (quit: Quit: Connection closed for inactivity).
(02:52:58 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(03:09:27 PM) sech1: omg 338 replies already: https://imgur.com/a/8REazSk
(03:09:34 PM) sech1: Never seen anything like this on Github
(03:09:46 PM) sech1: in 2 days
(03:13:57 PM) luigi1111 [sid85934@gateway/web/irccloud.com/x-cvqzqitfregusrgo] entered the room.
(03:18:38 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(03:19:03 PM) tevador: whitefire990 ignored my comment, means I'm right I guess
(03:22:41 PM) sech1: 352 replies and counting, lol
(03:22:49 PM) sech1: I have to turn off my e-mail notifications
(03:25:44 PM) dEBRUYNE: I think we had a constructive discussion earlier today, but now the random zero day accounts seem to have come out of the woodwork
(03:27:18 PM) needmoney90: Shhh, we need to listen to the miners and ignore the long-time community members
(03:27:37 PM) needmoney90: Dont give more weight to people who have been around for longer, why would you do that
(03:27:59 PM) needmoney90: Give authority to the people who are profit seeking and the network literally assumes are malicious as a premise 
(03:28:34 PM) fort3hlulz [~setsimmo@173.38.117.67] entered the room.
(03:29:12 PM) gethh [uid264798@gateway/web/irccloud.com/x-tsvcvocgdawjdfnb] entered the room.
(03:33:19 PM) dEBRUYNE: Muh GPUs
(03:34:02 PM) dEBRUYNE: Whilst I do think we should somewhat take them into consideration, I also think they would definintely accept it if the advantage is only slightly in favor of CPUs
(03:34:12 PM) dEBRUYNE: Which I think should be achievable by a decent GPU miner dev
(03:34:17 PM) dEBRUYNE: + GPUs are better scalable
(03:35:05 PM) midipoet: Who are the random zero day accounts?
(03:35:17 PM) midipoet: who=which?
(03:36:15 PM) dEBRUYNE: Not particularly zero day, but there are some people I've never seen before
(03:36:54 PM) sech1: Because it was posted on reddit, people come from there
(03:37:18 PM) sgp_: the x16 wasn't serious, they probably don't know much about what they are discussing
(03:40:23 PM) dEBRUYNE: sech1: It was posted on reddit a few days ago
(03:40:28 PM) dEBRUYNE: The accounts popping up seems only recently
(03:42:56 PM) sech1: and I posted it in FPGA discord today
(04:00:12 PM) hyc: ^^ aha
(04:00:23 PM) hyc: it's all sech1's fault :P
(04:00:39 PM) ***dEBRUYNE grabs pitchfork and torch
(04:00:49 PM) sech1: Not really in the whole FPGA discord, only the closed dev part of it
(04:01:01 PM) hyc: and please please please please put game theory on options list already please please please
(04:01:03 PM) sech1: yes, I'm in the inner circle, lol
(04:01:14 PM) hyc:  /s
(04:02:41 PM) dEBRUYNE: The only reason that option is being considered valid by some is because it aligns with their profit making
(04:02:54 PM) dEBRUYNE: They don't seem to particularly care if it destroys Monero as a side effect
(04:03:09 PM) hyc: yeah it's fucking stupid. only a non-developer could dream up such a thing
(04:03:22 PM) hyc: because it still requires us to ocnvincingly develop a new algorithm for each fork, even if we don't deploy it
(04:03:54 PM) sgp_: Does anyone agree with timolson's idea to create a community ASIC that initially dominates the network?
(04:04:05 PM) hyc: not as a first step, no
(04:04:45 PM) hyc: I'm wondering if timolson can think of a way to implement a randomX ASIC without an instruction fetch/decode pipeline.
(04:04:59 PM) sgp_: Do most people think that if Monero switches to ASIC-friendly, it simply make it easy for others to make their own ASICs?
(04:05:24 PM) hyc: ^^ probably, and that may not be a bad thing
(04:05:34 PM) hyc: but so far the evidence is that ASICs are not a fair market
(04:05:48 PM) hyc: also, in terms of ubiquitous access, they totally suck.
(04:06:07 PM) sgp_: I support doing our best to make it "fair" if we get there, I'm just not convinced that means making Monero ASIC Cooperative
(04:14:36 PM) ferretinjapan: sgp_, I think the general viewpoint is that Monero will eventually use ASICs, and in principal it not a bad thing. But thats in principal. My major beef is that ASICs are a trade off, and that the tradeoff should only be made much further in the future than some want. Also, "locking in" that tradeoff is also extremely bad, for various reasons...
(04:15:22 PM) sgp_: ferretinjapan: I've generally been against moving to an ASIC algorithm unless RandomX is a failure
(04:17:17 PM) ferretinjapan: agreed. My other thing is that holding off for as long as possible has, in itself opened up other innovations down the line. RingCT is a perfect example of that. nOone even conceived RingCT when Monero launched, and it's only due to the protocol being malleable via community driven hardforks it got integrated. Locking in sha3 could very well cut off Monero's nose to spite it's face.
(04:19:09 PM) ferretinjapan: The community should only fully embrace sha3 when the community is satisfied that Monero is by and large, feature complete, because after tht, any upgrades will only be brought about by ASIC users, and that usually mans a small group holding the keys.
(04:19:53 PM) sgp_: yes, the current flexibility of not really caring about miner voting is nice
(04:21:06 PM) ferretinjapan: I'd like to romantically say "the community is in control" but the reality is these recent hardforks have only come about due to a very staunch community spirit that is not locked into hardware that can't switch, once even a small amount of the community is locked into that even modest investment, the ASIC mining farms will be the gatekeepers by proxy.
(04:21:26 PM) ferretinjapan: I think thats lost on a large number of people...
(04:41:23 PM) gethh: well RandomX ASIC is comming in June anyway
(04:49:04 PM) ferretinjapan: yep, and that was not originally part of the plan when pow hfs began too. Being flexible has  opened up these opportunities.
(04:51:14 PM) ferretinjapan: oh I misread. Predicting that is rather presuptuous.  I can just as easily say. "well we'll change RX so their asics also fail".
(04:52:33 PM) tevador: ferretinjapan: he meant AMD Ryzen 3rd gen = RandomX ASIC
(04:52:49 PM) tevador: which is basically true
(04:53:01 PM) ferretinjapan: oh, I'm out of the loop it seems :)
(04:53:21 PM) ferretinjapan: my bad
(05:02:49 PM) gethh: ferretinjapan there are well grounded expectations new AMD will be capable of ~50kh
(05:03:54 PM) ferretinjapan: dayummm
(05:06:46 PM) gethh: I kinda like hat as everybody and their mother will run to offset their new PC cost
(05:07:01 PM) gethh:  s/hat/that/
(05:10:29 PM) dEBRUYNE left the room ("Leaving").
(05:37:57 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(05:39:14 PM) tevador: linzhi-sonia do you have any comments about RandomX specification (if you've read it)?
(06:13:29 PM) hyc: I'm not really convinced there will be a lot of SHA3 makers. if the algorithm is so simple and there's nothing to optimize, why would anyone enter the market?
(06:13:46 PM) hyc: they would only do so if they believed they had an edge that makes their product more attractive
(06:15:31 PM) hyc: In the ARM/Android TVbox market there's basically a couple of reference designs and a bunch of companies slap their names on them and sell them. I guess that works because there's sufficient demand for TVboxes.
(06:15:42 PM) hyc: mining ASICs don't have those kind of numbers for consumer demand
(06:21:30 PM) crCr62U0: hyc: How many SoC makers do you know which compete with samsung in the market of wearable devices?
(06:21:57 PM) hyc: a few. Apple and Huawei the big obvious ones
(06:22:00 PM) hyc: QUalcomm
(06:22:04 PM) crCr62U0: I've recently tried to make a prototype of monero cryptocurrency wallet from the hardware of gear fit 2
(06:22:18 PM) crCr62U0: I've managed to launch archlinux their instead of tizen os.
(06:22:32 PM) hyc: in the CHinese market there's Mediatek, rockchip, others
(06:23:31 PM) crCr62U0: I've failed due proprietary bootloader that forbids kernel update. But i've managed to boot it with upstream user space of archlinux.
(06:23:41 PM) hyc: nice
(06:23:49 PM) hyc: yeah locked bootloaders are annoying
(06:24:01 PM) crCr62U0: Can you point me to the direction: where can i get device with similar performance but without prorpietary things.
(06:24:09 PM) crCr62U0: I've spend about 45 days on that prototype.
(06:24:18 PM) luigi1111: low chances for optimization is very positive
(06:24:25 PM) luigi1111: but I wouldn't but on it
(06:25:22 PM) hyc: full wallet on smartwatch? that's ambitious. I don't know of any watch with battery life I find acceptable
(06:25:35 PM) crCr62U0: I've tested battery usage : it's nice
(06:25:45 PM) crCr62U0: It's possiblet o keep daemon syncing in background
(06:25:46 PM) hyc: meanwhile my ancient Casio runs for years on a single 2032 coin cell
(06:26:03 PM) hyc: or is it 2016, I think it's 2016
(06:26:08 PM) crCr62U0: We're about smart watches, not bare watches.
(06:26:13 PM) crCr62U0: *We're talking
(06:26:22 PM) hyc: yeah I know. but I got burnt on smart watches
(06:26:30 PM) hyc: really no interest now
(06:27:23 PM) crCr62U0: I've tried to make an alternative to useless crap with 100$ price from trezor and others.
(06:27:32 PM) crCr62U0: gear fit 2 costs ~120$
(06:28:12 PM) crCr62U0: And it's much more functional: high quality touch screen, wifi, bluetooth, almost fully customizable linux.
(06:28:40 PM) hyc: who is it sending all your biosensor data to?
(06:28:42 PM) crCr62U0: Do you know any companies similar to pine64 that can sell 1 device similar to smart watch from samsung?
(06:29:07 PM) crCr62U0: As i said, I was going to delete all bullshit with tizen from that device and install archlinux
(06:29:17 PM) crCr62U0: It's up to user to control his OS on the device
(06:29:39 PM) hyc: this is the one I bought on kickstarter a few years back http://hotsmartwatch.com/
(06:29:46 PM) hyc: I dunno if they ever updated to newer hardware
(06:30:23 PM) hyc: battery life of about 1 day. I never use it any more
(06:32:41 PM) hyc: the whole community ASIC project thing sounds pie in the sky at the moment. Let's see the community hardware wallet available for sale first.
(06:34:11 PM) crCr62U0: What does it mean: "sounds pie in the sky"?
(06:34:24 PM) hyc: big dreams with little reality
(06:34:43 PM) crCr62U0: ASIC project means open source ASIC?
(06:34:49 PM) hyc: yes
(06:36:48 PM) crCr62U0: I want to share some things about double spending of coins within 500-1500 range according to capitalization.
(06:44:07 PM) crCr62U0: I've tried to implement double spending mining pool with for so called *shitcoins*
(06:44:34 PM) crCr62U0: Rigs were used from public renting services.
(06:45:00 PM) crCr62U0: The whole budget was about 400$
(06:45:50 PM) crCr62U0: I've finished implementation too late so that target shitcoin switched to PoS
(06:46:05 PM) crCr62U0: Later i've looke through all coins at some exchange (~500coins)
(06:46:28 PM) crCr62U0: And built short list of appropriate ones
(06:46:55 PM) crCr62U0: I want to note that most shitcoins have > 25 blocks confirmations for deposit tx
(06:47:03 PM) crCr62U0: So it's not so easy as 3 blocks of bitcoin
(06:48:56 PM) crCr62U0: 23 / 500 were appropriate to double spending with initial budget of 0.11 bitcoins using public rig rentals
(06:49:16 PM) crCr62U0: Monero wasn't in that list due to very few hashing power available in public renting services.
(06:56:14 PM) crCr62U0: I've used mathematical model: profit= S(rigs_hashrate, rigs_rent_duration, main_net_blocks, initial_sum_in_btc) = (number_of_possible_alt_chais, final_sum_it_btc)
(06:57:03 PM) crCr62U0: *including rigs renting for predefined amount of work and period of time
(06:57:11 PM) crCr62U0: I mean all my calculations was precise
(06:57:37 PM) crCr62U0: It's good to have such model for the monero in order to know exact amount of money or hash power to double spendi it right now.
(06:58:25 PM) crCr62U0: Also hashrate that is calculated from diff was useless at all
(07:00:21 PM) crCr62U0: I've upper boundary instead that can be defined as f(start_block, end_block, period_of_time) = [maximum hashrate during period_of_time according to timestamps and diff of blocks between [start_block, end_block] ]
(07:00:25 PM) midipoet: hyc: I stated that I thought it a good idea for an open hardware ASIC, and am willing to work towards seeing if it's feasible, but I didn't get the impression there was consensus it was a good idea. 
(07:00:50 PM) crCr62U0: *I've used
(07:01:17 PM) midipoet: If people think it's worth putting in the leg work to approach manufacturers about it with RandomX, I dont see what we have to lose 
(07:02:07 PM) crCr62U0: open source cpu, fpga are much more useable than ASIC
(07:02:24 PM) hyc: yeah, ASICs become doorstops all too quickly
(07:04:04 PM) midipoet: so enquire about feasibility of designing an open hardware FPGA that would be suitable for RandomX?
(07:05:16 PM) crCr62U0: With time all those shitcoins moved to PoS
(07:17:17 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(07:20:46 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(07:21:43 PM) sech1 left the room (quit: Quit: Leaving).
(07:22:43 PM) fort3hlulz_ [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(07:26:08 PM) fort3hlulz left the room (quit: Ping timeout: 246 seconds).
(07:27:10 PM) hyc: I've posted a note looking for reviewers on a hardware forum I frequent https://www.realworldtech.com/forum/?threadid=183905&curpostid=183905
(07:27:30 PM) hyc: hopefully someone shows up
(08:26:10 PM) fort3hlulz_ left the room (quit: Read error: Connection reset by peer).
(08:53:59 PM) spaced0ut left the room (quit: Ping timeout: 246 seconds).
(10:08:07 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(12:09:08 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(12:09:08 AM) wowario left the room (quit: Ping timeout: 256 seconds).
(12:11:09 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(12:15:05 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:30:48 AM) needmoney90 is now known as NeedMoney90
(12:37:45 AM) NeedMoney90 is now known as needmoney90
(12:57:58 AM) dossier left the room (quit: Ping timeout: 245 seconds).
(02:09:21 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:14:50 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:23:22 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(03:28:13 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:57:25 AM) sech1 left the room (quit: Quit: Leaving).
(04:10:20 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(05:10:32 AM) midipoet [uid316937@gateway/web/irccloud.com/x-dyjqzrlhkevkofkw] entered the room.
(05:55:24 AM) tevador left the room (quit: Quit: Leaving).
(05:55:47 AM) tevador [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(06:16:51 AM) sech1: tevador hyc lengthy chat with GPUHoarder about RandomX (must read!): https://paste.debian.net/1073223/[1]
(06:22:35 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(06:25:51 AM) sech1: GPUHoarder about ASIC advantage: "I think the gains would be small for sure. 20x+ just out of the question"
(06:28:30 AM) midipoet: sech1: can you ELI5 the line about an agent being able to enter malicious code? i understand that is what the audit is for, but then you mention code isolation, which i assume means that there is no way for the RandomX code to interface with the consensus/protocol code. is that right? 
(06:29:16 AM) sech1: If RandomX VM implementation has a bug (aka security vulnerability), an attacker can mine a block that makes verification code do bad things
(06:29:36 AM) sech1: Remote code execution, DoS on all nodes that get this block
(06:29:53 AM) tevador: interesting read
(06:30:08 AM) tevador: midipoet: malicious code is impossible with RandomX
(06:30:28 AM) midipoet: tevador: that's much more reassuring
(06:30:29 AM) sech1: don't say impossible, many have burnt on it before
(06:30:43 AM) tevador: 1) you don't control the code 2) the code has no malicious power apart writing garbage into the scratchpad
(06:30:44 AM) sech1: JAVA VM is supposed to be isolated too yet how many exploits it had in the past?
(06:30:55 AM) midipoet: can i just confirm, the danger is due to RandomX being some form of 'dynamic code module'
(06:31:02 AM) midipoet: as apposed to a static algo, like SHA-3
(06:31:03 AM) tevador: you cannot compare java vm and RandomX vm
(06:31:03 AM) midipoet: ?
(06:31:12 AM) tevador: java has to call jitted functions
(06:31:15 AM) tevador: etc.
(06:31:31 AM) sech1: midipoet It's some form of random code execution, but much more restricted than Java
(06:31:35 AM) tevador: RandomX doesn't even use call/ret/jump
(06:31:49 AM) sech1: yes, I mean it's safe by the looks of it
(06:32:01 AM) sech1: Easier to audit
(06:32:09 AM) midipoet: and there is "no way" that someone that just replace the RandomX code with "some other code"
(06:32:22 AM) tevador: I'm 99.9999% sure it's impossible to exploit
(06:32:24 AM) sech1: No, attacker doesn't have direct control over the code at all
(06:32:30 AM) tevador: the only chance would be some CPU bug
(06:32:33 AM) sech1: So it might be DoS on nodes in the worst case
(06:33:10 AM) sech1: if they implement some part unsafely, like not checking division by zero in IMUL_RCP instruction
(06:33:21 AM) tevador: the at most you can crash
(06:33:24 AM) tevador: then*
(06:33:38 AM) sech1: and the whole network would stop at this block until fix is released
(06:33:57 AM) tevador: but this would show up in testing
(06:34:07 AM) sech1: yes, definitely
(06:34:20 AM) sech1: Not sure how to test IMUL_RCP in real conditions
(06:34:32 AM) sech1: We need to generate 2^64 random programs on average to get 0 there
(06:34:37 AM) midipoet: another question. what do you think the rough resource cost would be to design an ASIC? i.e only the schematic, blueprint, and virtual testing - as apposed to actually manufacturing one
(06:34:40 AM) tevador: first version of RandomX had a bug crashing if you divided INT64_MIN by -1
(06:34:59 AM) tevador: it crashed during testing after ~30000 nonces
(06:35:19 AM) sech1: Designing RandomX ASIC can be not very expensive if you start with ARM core and just strip it down
(06:35:20 AM) tevador: this version doesn't have division anymore
(06:35:28 AM) sech1: But it won't have much advantage over regular CPUs
(06:35:53 AM) tevador: yes, ARM is an option, but memory accesses will not be so easy
(06:35:59 AM) tevador: you need some NUMA design
(06:36:08 AM) tevador: or central chiplet like Epyc
(06:36:24 AM) midipoet: i am just asking, as in theory, we could provide some bounty that incentivises someone to prove (even in a sim environment) better than 2x performance. if they can prove that, we know we are on the wrong path
(06:36:39 AM) tevador: giving each ARM chip a dedicated 4 GB space is unrealistic
(06:36:52 AM) tevador: the die would be too big
(06:37:03 AM) tevador: to saturate the memory
(06:37:33 AM) sech1: So the hardest part would be memory controller that can feed 16-32 ARM chips
(06:37:52 AM) tevador: 4 GB needs a minimum of 4 DRAM chips (4x8 Gb), so you need at least ~6000 H/s to saturate that
(06:38:03 AM) tevador: so about 1.5 Ryzen 1700 level of performance
(06:38:27 AM) sech1: 64-128 ARM chips then
(06:38:59 AM) tevador: you could put 4 cores per chip to bring this down to maybe 16 chips
(06:39:13 AM) tevador: still not easy
(06:40:16 AM) tevador: and I'm not even sure if ARM supports directly addressable SRAM cache
(06:40:23 AM) sech1: No it doesn't
(06:40:33 AM) sech1: and it doesn't support more than 2 MB cache per chip
(06:40:39 AM) tevador: if not, you need some additional DRAM for scratchpads which would be shadowed in cache
(06:40:48 AM) sech1: which means a bigger rework is needed for ARM-based chips
(06:41:06 AM) tevador: I think some ARM chips have more than 2 MB
(06:41:39 AM) sech1: Another option he mentioned is custom boards + many AMD EPYCs on them
(06:41:45 AM) tevador: https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores[1]
(06:41:49 AM) tevador: some have 4 MB of L3
(06:42:34 AM) sech1: but custom boards + EPYCs for sure have < 2x advantage over normal PC builds
(06:43:30 AM) tevador: for sure and they would need to work with AMD to make their boards work probably
(06:44:27 AM) sech1: bottom line is, to create RandomX ASIC you need to create a CPU
(06:44:36 AM) sech1: and compete with AMD/Intel
(06:45:04 AM) tevador: "Writes very low probability of being re-read near term so usually I fire and forget those into a queue" I think this would cause a lot of incorrect hashes
(06:45:32 AM) tevador: 1/2048 chance of L1 dependency
(06:46:29 AM) tevador: and you need just one such write-read dependency in any of the 16384 program loops
(06:46:41 AM) sech1: it depends on how fast these writes are done
(06:46:59 AM) sech1: if it's only 1-2 cycles latency, it might work without synchronization logic
(06:47:00 AM) tevador: yes
(06:47:24 AM) tevador: or if the queue is too long
(06:48:14 AM) tevador: btw there are some reads from constant addresses in RandomX
(06:48:40 AM) tevador: it's tempting to cache it, but here you *need* coherency checking or >70% of hashes will be incorrect
(06:48:45 AM) sech1: 1/2048 chance x 16384 iterations -> 99.97% chance it will happen
(06:49:14 AM) sech1: used formula "1-(2047/2048)^16384"
(06:49:45 AM) tevador: it's a good first order approximation I think
(06:49:59 AM) tevador: it also depends on the code if there is a write and read immediately follows
(06:50:10 AM) sech1: and there's more than read-write pair in each program, so even higher chance
(06:50:16 AM) sech1: *than 1 read-write pair
(06:50:31 AM) tevador: yes, so write-read dependency checking is a must I think
(06:50:53 AM) tevador: this is what takes a lot of silicon in CPUs
(06:51:04 AM) sech1: this is what LSU is for
(06:51:40 AM) sech1: it's as big as FPU here: https://en.wikichip.org/wiki/File:amd_zen_core_(annotated).png[1]
(06:52:12 AM) tevador: yes, they have store buffers and write-read forwarding
(06:52:44 AM) tevador: basically every read has to be checked if it matches an address in the write queue
(06:53:14 AM) sech1: which increases read latency to level comparable with CPU L1 cache
(06:53:43 AM) tevador: I think ARM can do L1 read in 2 cycles
(06:53:58 AM) tevador: but they don't run at more than 1.5-2 GHz
(06:54:36 AM) tevador: this is for A53, which is in-order
(06:54:42 AM) tevador: so it needs low access latency
(06:54:47 AM) tevador: or it would stall all the time
(06:56:33 AM) tevador: I think a custom ASIC for RandomX is probably not feasible, would cost too much in R&D
(06:56:41 AM) tevador: some ARM based design is more likely
(07:02:39 AM) tevador: btw RandomX is actually only about ~85-90% of the hash time I think
(07:02:55 AM) tevador: 5-10% are scratchpad init/hash and JIT
(07:03:07 AM) tevador: JIT is about 1%
(07:05:36 AM) tevador: the "Generator" custom function is about as fast as you can generate pseudorandom data on a CPU, even copying from memory is slower
(07:09:34 AM) tevador: I hope the new Epyc has at least 16 memory channels :P
(07:21:37 AM) hyc: This Intel guy is quite scornful (but that's typical of him) but he has a point https://www.realworldtech.com/forum/?threadid=183905&curpostid=183913
(07:22:04 AM) hyc: branching is hard to optimize...
(07:29:04 AM) tevador: yes, branching *in general* is hard to optimize, but PoW needs to have consensus, so branches would be either random or predictable
(07:29:20 AM) tevador: neither is good for current branch predictors
(07:29:23 AM) tevador: we have tested that
(07:30:26 AM) moneromooo: You don't really care whether it's good or not, just whether it's better that what an ASIC could do though.
(07:31:08 AM) tevador: ASIC would always outcompete CPUs for predictable branches
(07:31:21 AM) tevador: CPU has to look at branc patterns and guess the formula
(07:31:33 AM) tevador: ASIC would just read the formula on PoW specification and optimize for that
(07:32:34 AM) tevador: and if you go for fully random branches, then branch predictor is actually *worse* than not predicting at all
(07:32:48 AM) tevador: it will try to find patterns while there are none
(07:33:26 AM) moneromooo: I find it hard to believe it can be worse than no prediction for random branches.
(07:33:42 AM) tevador: read the agner fog docs, they explain it pretty well
(07:33:59 AM) moneromooo: He's got lots. Any one in particular ? :)
(07:34:41 AM) moneromooo: microarchitecture I guess.
(07:35:56 AM) moneromooo: OK, I found a table. Random 50/50 goes to .5, seems exactly the same.
(07:36:10 AM) moneromooo: I assumed equoprobability, true.
(07:36:45 AM) moneromooo: Because if you'd do *worse*, hten you could change your prediction algorithm to do the opposite of what it'd otherwise do, and then you'd do better.
(07:36:51 AM) tevador: moneromooo page 15 of Microarchitecture "The fraction of mispredictions is slightly higher than it would be without pattern recognition because the processor keeps trying to find repeated patterns in a sequence that has no regularities."
(07:38:07 AM) tevador: so for a 50/50 branch, ASIC would simply always take it, but CPU would waste power on trying to guess which way it will go
(07:39:41 AM) gethh [uid264798@gateway/web/irccloud.com/x-sbxqlxmwlhhyrwup] entered the room.
(07:42:23 AM) moneromooo: Ah, the "waste power" thing is a good point, yes.
(07:43:11 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(07:50:38 AM) tevador: the hardware guy didn't realize that in a consensus protocol, all the rules must be known in advance, so there is no point to try to predict something
(07:55:33 AM) hyc: right. I've responded to his comment, hopefully captured enough of the points
(07:57:45 AM) dEBRUYNE: tevador: I have some concerns about the increasing mem requirement btw. As far as I can see, we could remove it without affecting the strength of the algorithm right?
(07:58:57 AM) tevador: dEBRUYNE: it's one of the configurable parameters, so easy to remove
(07:59:07 AM) dEBRUYNE: Okay
(07:59:16 AM) tevador: but arguably it somewhat increases the hardness
(07:59:50 AM) dEBRUYNE: Yes, but if we keep it at 4 GB, technology will likely catch up and increase verification performance for lower end devices
(08:01:42 AM) hyc: tech will catch up, yes, and make it cheaper to embed in an asic
(08:02:55 AM) dEBRUYNE: Yes but we have to keep trade-offs into account
(08:03:01 AM) dEBRUYNE: Verification time performance is imo quite important
(08:03:11 AM) dEBRUYNE: We don't want the cost of running a node increase significantly
(08:03:22 AM) hyc: which cost?
(08:03:35 AM) hyc: up front, or over time?
(08:04:14 AM) dEBRUYNE: Both imo
(08:04:23 AM) dEBRUYNE: But the cost over time becomes less if you keep the parameters static
(08:05:23 AM) hyc: static means ASICs can catch up
(08:05:49 AM) hyc: it's not like we should expect 10 year old PCs to continue to be useful
(08:06:12 AM) moneromooo: For maintaining a chain, I argue they should.
(08:06:21 AM) hyc: tech doesn't stand still, ASIC makers won't stand still. we have to cull older systems sooner or later
(08:06:23 AM) moneromooo: At least absent massive usage increase.
(08:06:47 AM) moneromooo: Slower, fine. But still usable would be nice.
(08:07:40 AM) dEBRUYNE: hyc: I know quite some people that use those old PCs to run a node
(08:07:55 AM) hyc: I think majority of PCs with 64bit CPUs can still be upgraded above 4GB
(08:08:29 AM) hyc: but obviously 32bit CPUs are already out of the game
(08:08:32 AM) moneromooo: That was just a generic comment to "it's not like we should expect 10 year old PCs to continue to be useful".
(08:08:50 AM) moneromooo: Yes, 32 bit being out is fine, it's a benefit/cost thing.
(08:09:15 AM) dEBRUYNE: hyc: We also have to account for scenarios where technology stalls and the mem requirement increases
(08:09:29 AM) dEBRUYNE: Then verification performance takes another hit
(08:13:49 AM) hyc: 1 verification every 2 minutes is not really a cost I'd worry about
(08:20:46 AM) sech1: tevador "The fraction of mispredictions is slightly higher than it would be without pattern recognition because the processor keeps trying to find repeated patterns in a sequence that has no regularities."
(08:20:51 AM) sech1: Agner is incorrect here
(08:20:57 AM) sech1: it's exactly 50%
(08:21:39 AM) sech1: If a branch is truly random, there is nothing you can do to not get 50% mispredictions there
(08:21:54 AM) sech1: otherwise you could cheat in casino using the same strategy
(08:22:22 AM) fort3hlulz [~setsimmo@173.38.117.81] entered the room.
(08:29:14 AM) sech1: That Intel guy probably thinks about interpreter on x86 vs hardware implementation in ASIC, that's why he's skeptical
(08:29:31 AM) sech1: GPUHoarder thought the same in the beginning, maybe we need to clarify it in design doc
(08:29:56 AM) sech1: That these VM instructions translate perfectly into native x86/ARM/PPC instructions and we use JIT compilation with small overhead
(08:31:11 AM) hyc: yeah, dunno. and yes, you could build a chip that implements than randomX instruction set directly
(08:31:17 AM) hyc: shouldn't make much difference
(08:31:30 AM) sech1: it doesn't because x86 has micro-op cache
(08:31:38 AM) sech1: so decoders not a bottleneck
(08:40:24 AM) dEBRUYNE: <hyc> 1 verification every 2 minutes is not really a cost I'd worry about <= That applies to real time nodes, not people newly syncing the block chain
(08:40:57 AM) hyc: they only have to endure that once :P
(08:48:22 AM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(08:50:13 AM) tevador: sech1: the higher misprediction applies to for example 30/70 random branches
(08:50:26 AM) tevador: 50/50 still suffers from power inefficiency of the predictor
(08:50:29 AM) sech1: if they're truly random it will be 30/70 anyway
(08:50:38 AM) sech1: no matter what branch predictor spits out
(08:50:48 AM) sech1: probability theory, can't go against it
(08:51:19 AM) tevador: 30/70 branch predictor will mispredict in 36% of cases
(08:51:30 AM) sech1: then it's not a random branch
(08:51:32 AM) tevador: this is the simple 2-bit predictor I think
(08:51:38 AM) tevador: it is
(08:52:30 AM) tevador: no, it's not the simple predictor, he actually tested a physical CPU
(08:52:32 AM) sech1: you mean, if it's 30% taken and predictor tends to predict not-taken? Then yes
(08:52:38 AM) tevador: yes
(08:53:18 AM) tevador: 30% taken, 70% not taken - predictor will predict the opposite in 36% of cases
(08:53:42 AM) sech1: yes, anything random and different from 50/50 can vary
(08:53:44 AM) tevador: if you never take, you will mispredict only in 30% of casews
(08:53:46 AM) sech1: depending on predictor output
(08:54:09 AM) tevador: but for 50/50, you can simply remove the branch predictor from the chip
(08:54:12 AM) tevador: and save power
(08:54:27 AM) tevador: CPU loses on any cases with branches
(08:54:54 AM) fort3hlulz [~setsimmo@173.38.117.81] entered the room.
(08:56:02 AM) sech1: no, there is one case where it doesn't lose
(08:56:06 AM) sech1: 100% predicted branches
(08:56:23 AM) sech1: then still give headache to ASICs because they break pipelining
(08:56:33 AM) sech1: *they
(08:57:29 AM) sech1: But I have no idea how to introduce them
(08:57:54 AM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(08:58:33 AM) sech1: ASICs can just use the branch pattern that must be defined for such branches and save power on prediction
(08:58:39 AM) sech1: so bad idea after all
(08:58:42 AM) tevador: sech1 100% predicted branches require some specific pattern, which the ASIC can just hardwire 
(08:58:55 AM) tevador: yes
(08:59:58 AM) sech1: GPUHoarder talked about simple loop instructions like "repeat previous N instructions M times"
(09:00:14 AM) sech1: these loop will have 100% prediction and will be random
(09:00:25 AM) sech1: no hardwiring possible
(09:00:30 AM) tevador: is M/N compile time constant?
(09:00:51 AM) sech1: compile time as in taken from loop instruction fields
(09:00:59 AM) sech1: so it's in random program
(09:00:59 AM) fort3hlulz [~setsimmo@173.38.117.81] entered the room.
(09:01:17 AM) tevador: it would be possible, but it would increase the variance of hash times
(09:01:31 AM) hyc: still needs a stack. if previous N instructions also includes a loop instruction
(09:01:32 AM) tevador: and break the sync with the DRAM access latency
(09:02:27 AM) tevador: I had this issue with RandomJS - nested loops kill performance very quickly
(09:02:34 AM) hyc: right
(09:02:42 AM) sech1: yes, that's the problem. And if we use small M,N to mitigate it, ASICs can just unroll these loops during compilation
(09:03:47 AM) tevador: too bad the BPU has to be unused, but it's better to power it off
(09:06:01 AM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(09:08:59 AM) hyc: I think this guy has nothing else useful to tell us https://www.realworldtech.com/forum/?threadid=183905&curpostid=183921
(09:10:43 AM) tevador: crappy PC from before 2000 didn't have 4 GB of RAM
(09:10:50 AM) hyc: indeed
(09:12:57 AM) tevador: branches *are* harder for CPUs because they have to handle anything you throw at them, not just a predetermined patterns
(09:15:39 AM) sech1: I bought a new PC with 128 MB ram in 2002
(09:15:59 AM) sech1: then upgraded it to 512 MB couple years later
(09:16:02 AM) sech1: it was a LOT back then
(09:17:29 AM) hyc: yeah he's off base
(09:30:20 AM) tevador: btw sech1: I have implemented the rotation of indexes c0-c7 in initBlock - verification time is up 4%
(09:30:47 AM) tevador: it's mostly because the compiler is stupid and keeps 4 of the variables on the stack
(09:31:07 AM) sech1: rewriting it in asm is not a problem
(09:31:14 AM) sech1: and we can also use JIT for verification
(09:31:16 AM) tevador: yes, it will be needed
(09:55:29 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:57:28 AM) fort3hlulz [~setsimmo@173.38.117.81] entered the room.
(10:07:12 AM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(10:45:27 AM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(10:47:20 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(10:55:21 AM) fort3hlulz [~setsimmo@173.38.117.81] entered the room.
(11:01:02 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:11:21 AM) camthegeek left the room (quit: Ping timeout: 268 seconds).
(11:12:38 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(11:33:22 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(11:37:51 AM) oneiric_ left the room (quit: Remote host closed the connection).
(11:39:49 AM) ferretinjapan is now known as Soi-injapan
(11:45:51 AM) Soi-injapan is now known as ferretinjapan
(11:55:56 AM) [-mugatu-] is now known as ShilloSoi
(12:10:24 PM) sech1 left the room (quit: Quit: Leaving).
(12:11:01 PM) camthegeek` [~ctg@community.of.aeonminingpool.com] entered the room.
(12:14:31 PM) camthegeek` is now known as camthegeek
(12:21:05 PM) sech1 [~sech1@31.208.119.248] entered the room.
(12:44:19 PM) tevador: hm, I rewrote it in asm and it's even 1% slower
(12:45:01 PM) tevador: although I removed 100 instructions from the function
(12:45:40 PM) hyc: removed the wrong instrs :P
(12:54:52 PM) sech1: optimizing in asm is tricky
(12:55:08 PM) sech1: you can't just rewrite it and it'll magically be faster
(12:55:40 PM) sech1: we can leave optimization for later, I can do it
(12:56:43 PM) tevador: sech1 I will push the code, can you have a look?
(12:56:49 PM) sech1: yes
(12:57:21 PM) tevador: well, if the cycling of indexes causes unavoidable increase in verification time, it could be an issue
(01:01:58 PM) tevador: sech1: https://github.com/tevador/RandomX/commit/edde7672e0d928b473b571736fef8b68e5c6a475[1]
(01:02:28 PM) tevador: my asm version is 100 instructions shorter than what Visual Studio 2017 produces
(01:03:27 PM) sech1: ok, what I see immediately: squarehash is not inlined, you loose 3-5% here
(01:03:43 PM) sech1: My approach is to always get optimized and fully inlined asm code generated by compiler
(01:03:46 PM) sech1: and then optimize it
(01:03:48 PM) tevador: msvc also doesn't inline it
(01:03:55 PM) sech1: it can be force inlined
(01:04:30 PM) tevador: squareHash is ~85 instructions
(01:04:46 PM) sech1: By the structure of this loop, 1% change (slower/faster) is pretty random. Instruction level tuning is needed here
(01:05:36 PM) tevador: if you inline squareHash, the loop will not fit into uop cache
(01:05:43 PM) tevador: so there may be some degradation
(01:05:44 PM) sech1: Sometimes replacing prefetch with regular mov instruction makes it faster
(01:05:57 PM) sech1: try prefetcht0 also
(01:06:45 PM) Mafaka [~Mafaka@74-116-186-137.qc.dsl.ebox.net] entered the room.
(01:06:51 PM) tevador: C++ version was faster with NTA
(01:07:08 PM) tevador: NTA loads only into L1
(01:07:12 PM) sech1: it's too hard to say where it became slower
(01:07:25 PM) sech1: You need to start with ASM output of C++ version and gradually optimize it
(01:07:31 PM) sech1: comparing performance after each change
(01:07:45 PM) sech1: But it takes time, not sure it's worth doing now
(01:08:43 PM) sech1: and comparing performance is also tricky when we're talking about +-1% changes
(01:08:43 PM) tevador: msvc version is very ugly: https://pastebin.com/CK0wg6Wj
(01:08:47 PM) hyc: you're developing under windows? I guess you could use Vtune or something
(01:09:16 PM) hyc: on Linux you can do instruction-level profiling with perf
(01:09:30 PM) hyc: codeAnalyst on windows
(01:10:22 PM) sech1: I think inlining squarehash and rolling back this loop could help
(01:10:28 PM) sech1: You don't need it unrolled 8 times
(01:11:48 PM) sech1: The only way to know is to try everything on C++ level first (checking the generated asm code to make sure it inlined)
(01:13:19 PM) hyc: feedback from a different poster https://www.realworldtech.com/forum/?threadid=183905&curpostid=183923
(01:57:24 PM) sech1: again, he thinks in the wrong direction. The main thing is not instruction execution and not the eventual feasibility of RandomX ASIC
(01:57:37 PM) sech1: it's the level of advantage an ASIC can have in theory
(01:58:15 PM) hyc: well, a simple in-order core would probably be cheap and power efficient
(02:13:03 PM) sech1: except it'll be very slow
(02:13:17 PM) sech1: some instructions like div/sqrt are slower than the other
(02:14:15 PM) sech1: unless they pipeline them, but it's not in-order anymore when 2 or more instructions execute at the same time
(02:15:50 PM) ferretinjapan is now known as Soinjapan
(02:16:03 PM) Mafaka left the room (quit: Ping timeout: 252 seconds).
(02:16:34 PM) Mafaka [~Mafaka@74-116-186-137.qc.dsl.ebox.net] entered the room.
(02:21:02 PM) Mafaka left the room (quit: Read error: No route to host).
(02:22:52 PM) Mafaka [~Mafaka@74-116-186-137.qc.dsl.ebox.net] entered the room.
(02:25:41 PM) tevador: sech1: it needs to be unrolled because each iteration uses a different register
(02:26:40 PM) tevador: I'm mainly interested if we can afford to cycle the columns without impacting performance
(02:31:40 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:33:18 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:33:54 PM) gethh left the room (quit: Quit: Connection closed for inactivity).
(02:37:01 PM) Soinjapan is now known as ferretinjapan
(02:45:30 PM) ShilloSoi is now known as PopeOfSoi
(02:47:05 PM) tevador: tested on another PC, asm version is tiny little bit faster there
(02:50:13 PM) crCr62U0_ [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:53:07 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(02:56:43 PM) sech1: good. I think further micro-optimizations can get it even more faster
(02:56:58 PM) sech1: The main bottleneck ther is memory access anyway
(03:26:53 PM) gethh [uid264798@gateway/web/irccloud.com/x-vsciteaervacmjah] entered the room.
(03:29:23 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(03:46:52 PM) sech1: This is an interesting point: "I can also assure you that a 2x512 bit FPU with 200 registers for out of order execution and 32 architectural registers is not optimal for emulating a 1x64 bit in order FPU with 12 architectural registers, especially in terms of performance per watt, which is your preferred metric."
(03:47:18 PM) sech1: Except Intel CPUs are 256-bit and they power down high 128 bits if AVX is not used
(03:47:28 PM) sech1: so they're essentially 128-bit
(03:48:23 PM) sech1: And these "200 registers" give proportional speedup compared to plain in-order pipeline
(03:50:54 PM) hyc: speaking of which, should we think about vector instructions for a future version of randomX?
(03:51:37 PM) sech1: AVX?
(03:51:54 PM) hyc: or just SSE. also ARM NEON
(03:52:03 PM) sech1: but it's already 2x64 bit now
(03:52:10 PM) sech1: RandomX uses SSE
(03:52:50 PM) hyc: hm I don't think ARM has an AVX equivalent yet. their SVE is not yet in real chips
(03:53:31 PM) sech1: SSE is good enough now
(03:53:58 PM) sech1: Intel chips completely power down the upper half of 256-bit pipeline if only SSE is used
(03:54:06 PM) sech1: so power is not wasted
(03:54:07 PM) hyc: ok. yeah, well supported
(03:54:38 PM) sech1: Ryzen has 128-bit pipeline, so it's not a concern there
(03:54:58 PM) sech1: new Ryzens will have 256-bit pipeline, but I'm sure they'll use similar clock gating as Intel did
(03:57:45 PM) sech1: Also, this anon's point about "200 registers" not optimal for performance watt doesn't really hold
(03:58:02 PM) sech1: registers consume chip area, but most of power is consumed in FPU doing actual work
(03:59:00 PM) sech1: yes, the ASIC chip will be tiny, especially if they decide to go full-RAM, without caches or only with L1
(03:59:13 PM) sech1: But power consumption will be similar 
(04:02:44 PM) sech1: I saw a research article somewhere where they put a transparent waterblock on top of bare CPU chip and captured infrared images when it was running
(04:03:10 PM) sech1: It was ALU and FPU producing the heat, other parts of chip were cold
(04:03:20 PM) hyc: makes sense
(04:13:36 PM) tevador: yes, FP is currently 128-bit in RandomX, but could be extended to 256 bits in the future if needed
(04:15:22 PM) tevador: btw OoOE is not about branches, it's about dependency stalls, mostly memory dependencies
(04:15:51 PM) tevador: so we are still fully benefiting from OoOE even without branches
(04:16:01 PM) sech1: Branch unit doesn't use much power especially when there are no braches
(04:16:20 PM) sech1: Intel/AMD CPUs are very good at clock gating and power down unused parts of the chip
(04:16:55 PM) tevador: yes, BTB is not updated if there are no branches, fetch/decode doesn't see any branches to query the BPU
(04:17:43 PM) tevador: I would like to see how many chip you would need for the full DRAM version wihtout any cache
(04:18:11 PM) tevador: then you can have comparatively small cores, maybe 1-2 mm2
(04:18:30 PM) sech1: L1 is tiny
(04:18:44 PM) sech1: no reason not to add it
(04:19:14 PM) tevador: L1 only probably makes more sense
(04:19:36 PM) sech1: can fit in 0.1 mm^2
(04:20:03 PM) tevador: so you will have 14+4 DRAM accesses per iteration
(04:20:26 PM) tevador: actually 14+4+1 (Dataset), so total of ~19
(04:21:04 PM) tevador: so you can do about 80 H/s per DRAM port
(04:22:52 PM) sech1: 19 accesses per iteration?
(04:23:02 PM) sech1: 311296 per hash
(04:23:25 PM) sech1: HBM2 memory can do 13 kh/s then
(04:23:50 PM) sech1: Vega can do 2 kh/s on Cryptonight, and each cryptonight hash has 2097152 memory accesses (50% read, 50% write)
(04:25:20 PM) tevador: we didn't count initialization/finalization for RandomX
(04:25:31 PM) sech1: So many tiny cores + L1 cache on each core, advanced memory controller and HBM2 memory = 13 kh/s
(04:25:33 PM) tevador: that's 2 MiB of writes + 2 MiB of reads per hash
(04:25:43 PM) sech1: Still enough bandwidth for this
(04:25:55 PM) tevador: ok
(04:26:15 PM) sech1: But it'll be an expensive device
(04:26:33 PM) tevador: how much HBM needed?
(04:27:06 PM) sech1: 4 GB + 2 MB for each core
(04:27:24 PM) tevador: the question is how many cores
(04:27:27 PM) sech1: if each core does 50 h/s (conservative), it's 4.5 GB
(04:28:06 PM) sech1: if each core does 5 h/s (considering external memory accesses), it's 9.2 GB
(04:28:24 PM) sech1: so it's feasible
(04:28:47 PM) tevador: ok
(04:29:18 PM) tevador: 13 KH/s is like 3 Ryzens
(04:30:06 PM) tevador: so it the device uses less than ~250 W, it's probably a win
(04:30:19 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(04:30:41 PM) tevador: if less than 120 W, it's already 2x more efficient
(04:40:00 PM) tevador: btw tim olson will give feedback early next week
(04:44:47 PM) sech1: We can also estimate the different way: Vega on Cryptonight can process the batch of 4000 hashes in 2 seconds, so 2097152 random dependent accesses take 2 seconds
(04:45:02 PM) sech1: or 1000 ns latency to access HBM2 RAM
(04:45:27 PM) sech1: so each CPU core takes 311296 mcs for 1 hash
(04:45:34 PM) sech1: or roughly 3 h/s per core
(04:46:04 PM) sech1: which requires 8.6 GB for scratchpads to achieve 13 kh/s
(04:46:33 PM) dEBRUYNE left the room ("Leaving").
(04:46:41 PM) sech1: if such device only has 8 GB in total, it'll be limited to 4096/2*3 h/s = 6 kh/s
(04:46:46 PM) tevador: so if we are conservative and estimate 10 H/s, this device still needs at least 1300 cores and ~7 GiB of HBM2
(04:46:46 PM) sech1: and decreasing as dataset grows
(04:47:31 PM) tevador: I think 1300 cores may be too large unless they share some functional units
(04:47:41 PM) tevador: too large for a single chip
(04:47:58 PM) sech1: it can be multiple chips on board
(04:48:04 PM) sech1: and single memory controller for HBM
(04:48:07 PM) sech1: and fast interconnect
(04:48:11 PM) sech1: but it's big R&D cost
(04:48:15 PM) tevador: so some chiplet design like Ryzen
(04:48:30 PM) tevador: Ryzen 3rd gen I mean
(04:48:53 PM) sech1: yes, it's optimal when you need to have _many_ cores
(04:49:07 PM) tevador: in that case I doubt power would be less than 100 W
(04:50:28 PM) sech1: HBM is well-known for low power consumption
(04:51:33 PM) sech1: but 1300+ cores + interconnect will still eat a lot
(04:51:54 PM) tevador: you need a lot of IO pins, memory controller chip and probably a hundred compute chips
(04:53:35 PM) sech1: yes, each chip needs 64-byte access width
(04:53:53 PM) sech1: or it'll be even slower with thin IO bus
(04:54:52 PM) sech1: they can use 64-bit bus for each chip, or some shared wide bus, but it'll use a lot of silicon anyway
(05:10:16 PM) sech1: 1300 cores are not needed actually
(05:10:36 PM) sech1: It's possible to have multiple contexts for single computing core
(05:10:51 PM) sech1: because each context is idle waiting for RAM most of the time
(05:11:25 PM) sech1: something like 1 MB SRAM for 64 contexts and registers and 1 CPU core that can switch between contexts instantly
(05:11:51 PM) sech1: then only 32-48 such cores (compute units) are needed
(05:11:56 PM) sech1: looks more and more like GPU
(05:12:52 PM) sech1: it won't save power though, it'll just make interconnect simpler
(05:24:33 PM) tevador: it's like a GPU with a more beefy instruction decoder and 64-bit math
(05:28:48 PM) sech1: the difference from GPU is that instead of multiple SIMD execution cores it has multiple contexts and one execution core
(05:30:24 PM) tevador: so it's kinda like a 64-way hyperthreaded core?
(05:31:13 PM) sech1: yes
(05:31:18 PM) tevador: I think it's not very easy to switch between the contexts
(05:31:27 PM) tevador: you would do some round robin I guess
(05:32:01 PM) sech1: register indexing + base address for scratchpad
(05:32:35 PM) tevador: I mean to know when to switch the context to maximize performance
(05:32:48 PM) sech1: switch context when memory request finishes
(05:32:51 PM) tevador: surely when you reach a memory stall
(05:33:13 PM) sech1: when you get new data from memory, process it until you have new memory address to read or write
(05:33:45 PM) sech1: It's all a theory now, I'm curios what Tim Olson says
(05:34:00 PM) tevador: I think this would still need a ton of R&D
(05:37:33 PM) tevador: so 8 GB of HBM2 costs about $175 and consumes ~15 W
(05:39:00 PM) tevador: comparable GDDR5 would cost $50 and consume ~50 W
(05:39:56 PM) tevador: info from this article: https://www.gamersnexus.net/guides/3032-vega-56-cost-of-hbm2-and-necessity-to-use-it[1]
(05:43:27 PM) spaced0ut left the room (quit: Remote host closed the connection).
(05:53:15 PM) cjd: Why are we not seeing HBM on processors for l4 ?
(05:57:34 PM) tevador: too expensive
(06:00:02 PM) tevador: btw sech1 not sure if your "hyperthreading" idea would work, the cores would need to have performance of around 200-400 H/s each, which seems high for an in-order core running at ~1 GHz
(06:01:36 PM) tevador: so you would have most likely not more than 8 or so threads per core
(06:09:01 PM) geonic left the room (quit: Remote host closed the connection).
(06:09:48 PM) geonic [debug@2001:19f0:ac01:1e23:0:1ce:c01d:bee2] entered the room.
(06:10:10 PM) geonic left the room (quit: Changing host).
(06:10:10 PM) geonic [debug@unaffiliated/geozdr] entered the room.
(06:20:39 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(06:22:32 PM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(07:46:39 PM) sech1 left the room (quit: Quit: Leaving).
(07:56:05 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(07:59:28 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 272 seconds).
(09:53:45 PM) hyc: sounds like you're describing an ultrasparc t1000
(10:14:09 PM) Mafaka left the room (quit: Ping timeout: 244 seconds).
(10:15:07 PM) Mafaka [~Mafaka@74-116-186-137.qc.dsl.ebox.net] entered the room.
(11:19:51 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(02:20:51 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:47:58 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(03:06:52 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:50:55 AM) el00ruobuob_[m] [~el00ruobu@37.169.180.12] entered the room.
(03:52:05 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:55:35 AM) sech1: hyc yes, exactly what I was describing: https://en.wikipedia.org/wiki/Barrel_processor[1]
(03:55:59 AM) sech1: I think this architecture can be the best for RandomX
(03:57:11 AM) sech1: We need to ask Tim Olson if it's feasible
(04:13:45 AM) sech1: a simple in-order core @ 500 MHz, running each instruction in 1 cycle and div/sqrt in 3 cycles can do 110 h/s if feeded with enough data
(04:13:53 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(04:14:08 AM) sech1: so it can accomodate 32 independent contexts (16 KB of cache + registers)
(04:14:41 AM) sech1: and 128 such cores will be needed to saturate HBM2
(04:19:34 AM) sech1: and these cores will be small - 512 KB cache is 0.5 mm^2, so they all can fit on one chip
(04:20:32 AM) sech1: the whole core for 32 contexts can fit in 1 mm^2, 128 core chip will be smaller than most recent CPUs
(04:22:21 AM) sech1: no, my numbers were off. 512 KB cache is 1.5 mm^2, the whole core will be 2 mm^2
(04:25:16 AM) sech1: so total silicon needed for cores will be 256 mm^2 + some more silicon for memory controller, totally feasible
(04:27:46 AM) sech1: the question is how much power per hash/s simple in-order core would consume
(04:31:43 AM) sech1: if it turns out to be more than 2x economy, I think we'll have to use AVX (256-bit FP registers) to shift the power balance towards computations
(04:32:26 AM) sech1: out of order logic consumes quite a lot, in-order core doesn't have it, but it has context switching logic
(04:32:33 AM) sech1: still less power I think
(04:47:48 AM) p0nziph0ne left the room (quit: Quit: Leaving).
(05:00:17 AM) sech1: Another advantage of using AVX is that we can have up to 32 256-bit registers
(05:00:30 AM) sech1: So register file of x86 CPU will be used much more
(05:24:09 AM) tevador: sech1: extending FP to 256 bits is an option, but it's a bit tricky since you'd have to change reads/writes from 64 bytes to 128 or 256 bytes per iteration
(05:25:45 AM) sech1: we can still read 64 bytes and roll through FP registers
(05:26:22 AM) sech1: 4 iterations will be enough to roll through all 256-bit registers
(05:26:43 AM) tevador: for example vcvtdq2pd requires 16 bytes of data to initialize a 256-bit register
(05:26:59 AM) tevador: 4 packed 32-bit integers
(05:28:07 AM) tevador: if we extend to 24 registers (16 dynamic), you need 16x16 = 256 bytes instead of current 8x8 = 64 bytes
(05:29:12 AM) tevador: you mean to initialize only 4 registers and copy the values?
(05:30:05 AM) sech1: not copy, just don't change other registers
(05:30:18 AM) sech1: they were initialized before
(05:30:21 AM) tevador: we have to change them each round of they will overflow
(05:30:42 AM) tevador: all FP registers must be reset each interation
(05:31:07 AM) sech1: we can read 64 bytes and uses 4xAES to get next 64 bytes
(05:31:24 AM) sech1: or something like this
(05:31:35 AM) tevador: that might work
(05:32:00 AM) sech1: 4xAES is fast, it can run in 4-5 cycles
(05:32:03 AM) tevador: we would have exactly 4 spare registers for 4 round keys
(05:32:27 AM) tevador: 24 RandomX registers, 4 AES, 4 temp registers
(05:32:34 AM) tevador: so all 32 are used
(05:32:39 AM) sech1: plus we have AES in the main cycle
(05:33:14 AM) tevador: there would be some overhead, however
(05:34:00 AM) tevador: btw your estimates are a bit optimistic
(05:34:31 AM) tevador: the core would have to make 32x310000x110 context switches per second
(05:34:59 AM) sech1: GPUs can switch every cycle
(05:35:07 AM) sech1: if all contexts are stored on chip, it's basically free
(05:35:35 AM) tevador: GPUs switch only data, not code
(05:37:08 AM) sech1: but barrel processors existed, they switch every cycle
(05:37:13 AM) tevador: and the core would be more like 3 mm2, memory controller is ~15 mm2
(05:37:26 AM) sech1: they didn't get adopted because there were no tasks with such massive parallelism
(05:37:27 AM) tevador: HBM2 controller is possibly even bigger
(05:38:02 AM) tevador: so the chip is ~400 mm2, still doable, but expensive
(05:38:15 AM) sech1: I'm more concerned about power saving
(05:38:24 AM) sech1: 400 mm2 chip can be done is 4x100 mm2 chips instead
(05:38:29 AM) sech1: *as
(05:38:40 AM) tevador: then you need IO for memory accesses
(05:38:44 AM) tevador: power goes up a lot
(05:39:38 AM) tevador: vega is ~400 mm2 and the chip eats 300 W at full power, so I don't think it could use less than 100 W
(05:39:48 AM) tevador: even at 500 MHz
(05:40:05 AM) sech1: let's assume 200 W for 13 kh/s
(05:40:25 AM) tevador: could be even 150 W
(05:40:38 AM) sech1: so it's already in 2x range
(05:40:40 AM) sech1: more efficient
(05:40:42 AM) tevador: yes
(05:40:49 AM) tevador: unless it's less than 130 W
(05:41:06 AM) sech1: I think we need AVX to have more power on computations. Computations can't be removed
(05:41:23 AM) tevador: CPUs do around 50 H/J
(05:41:41 AM) tevador: this ASIC at 130 W would be 100 H/J
(05:41:43 AM) tevador: exactly 2x
(05:42:33 AM) tevador: btw using AVX reduces the clock of most CPUs
(05:42:43 AM) tevador: they have special power state for AVX
(05:43:06 AM) sech1: yes, because it's 50% of FPU that goes from 0% to 100% power
(05:43:29 AM) gethh [uid264798@gateway/web/irccloud.com/x-juqaneqonsfdydon] entered the room.
(05:43:36 AM) sech1: absolute clock speed doesn't matter
(05:43:50 AM) sech1: more important is that we go from 50% power on computations to 80% power on computations
(05:44:24 AM) sech1: btw AVX offset can be forced to 0 in BIOS
(05:44:38 AM) sech1: proper tuning can give the same clock speed
(05:45:10 AM) sech1: I even think that lower clock speed + undervolting will be the most optimal
(05:57:33 AM) sech1: tevador With 24 FP registers, is it enough to have ~94 FP operations per program?
(05:57:45 AM) sech1: We need to increase FP weights too
(06:00:50 AM) sech1: there are 16 possible destination registers, so each register will be only in ~6 instructions on average
(06:18:32 AM) tevador: then the ALU will not be fully used maybe
(06:19:56 AM) sech1: ALU has fewer registers, so there will be more dependencies between instructions
(06:20:16 AM) sech1: We need to test different instruction weights when we have AVX there
(06:20:27 AM) sech1: and choose the one that gives maximal IPC
(06:21:35 AM) sech1: or better - maximal power usage at the same clock speed since we're trying to shift power balance to computations
(06:32:59 AM) tevador: I would wait for tim olsons review first
(06:33:26 AM) tevador: extending fp to 256 bits is not a trivial change
(06:33:50 AM) tevador: and it can potentially affect verification time
(06:34:04 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 272 seconds).
(06:38:15 AM) el00ruobuob_[m] [~el00ruobu@37.169.180.12] entered the room.
(06:38:40 AM) tevador: btw sech1: only AVX512 has 32 architectural registers, so it's unusable
(06:39:04 AM) tevador: AVX/AVX2 only have ymm0 - ymm15
(06:40:46 AM) tevador: only some Intel CPUs have AVX512, so we cannot use it
(07:46:22 AM) tevador: sech1: xmrig-amd using 8.5 GB of RAM is normal?
(08:05:32 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(08:08:02 AM) el00ruobuob_[m] [~el00ruobu@37.169.180.12] entered the room.
(08:13:20 AM) cjd: I would love to see barrel processors make a comeback, that would be so cool for fuzz testing
(08:21:24 AM) el00ruobuob_[m] left the room (quit: Read error: Connection reset by peer).
(08:26:38 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:18:59 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(09:20:07 AM) PopeOfSoi left the room (quit: Ping timeout: 255 seconds).
(09:22:22 AM) midipoet [uid316937@gateway/web/irccloud.com/x-udhwhcrmhqncnncy] entered the room.
(10:16:08 AM) sech1: tevador what version of xmrig-amd? 2.14.0 had memory leak, it was fixed in 2.14.1
(10:58:46 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(10:59:04 AM) dEBRUYNE: fyi -> https://github.com/monero-project/meta/issues/315#issuecomment-473538744[1]
(10:59:19 AM) dEBRUYNE: sech1: I tagged you, but not sure if you get a notification of that, since you did not respond on #315
(11:02:52 AM) sech1: Next unday? Works fine for me
(11:06:23 AM) dEBRUYNE: Yeah
(11:06:27 AM) dEBRUYNE: This sunday seems a little short
(11:08:01 AM) tevador: yes, it's better to let the github discussion settle
(11:08:18 AM) tevador: sech1: ok, must be the memory leak, I have 2.14.0
(11:08:53 AM) dEBRUYNE: tevador: Quality is fastly detoriating as well :P
(11:08:54 AM) sech1: plus we'll have Tim Olson's feedback on RandomX by next Sunday
(11:09:13 AM) dEBRUYNE: "Critical intelligence on our enemies approach"
(11:09:22 AM) dEBRUYNE: sech1: cool
(11:09:30 AM) dEBRUYNE: Guess we can add that to the meeting then
(11:32:40 AM) parasew[m] left the room (quit: Read error: Connection reset by peer).
(11:40:59 AM) midipoet: There has indeed been a lot said on that GitHub thread.
(11:41:16 AM) midipoet: I am not sure if anything is any clearer to me
(11:43:30 AM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-ejbwqafenoqoaosw] entered the room.
(11:45:19 AM) luigi1111: clear as mud 
(12:00:21 PM) midipoet:  
(12:00:58 PM) midipoet: Does anybody know why SHA-3 has not been adopted as a POW algorithm by any "large cap" coin?
(12:09:23 PM) luigi1111: most tried asic resistance 
(12:14:17 PM) tevador: tried and failed
(12:38:11 PM) luigi1111: I assume sha3 or keccak is in those x whatever coins 
(12:38:19 PM) LSDog_ left the room (quit: Ping timeout: 246 seconds).
(12:40:25 PM) Mafaka left the room (quit: Ping timeout: 246 seconds).
(12:50:05 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:13:58 PM) LSDog_ [~LSDog@unaffiliated/lsdog] entered the room.
(01:36:56 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(01:38:19 PM) Mafaka [~Mafaka@72.143.55.50] entered the room.
(01:48:46 PM) Mafaka left the room (quit: Ping timeout: 255 seconds).
(01:50:49 PM) Mafaka [~Mafaka@72.143.55.50] entered the room.
(01:53:25 PM) crCr62U0_ left the room (quit: Remote host closed the connection).
(01:53:45 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:55:00 PM) Mafaka left the room (quit: Ping timeout: 244 seconds).
(02:22:40 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:22:53 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:16:08 PM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:18:58 PM) sech1 left the room (quit: Ping timeout: 246 seconds).
(03:20:35 PM) sech11 left the room (quit: Ping timeout: 246 seconds).
(03:39:55 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(04:44:46 PM) linzhi-sonia left the room (quit: Quit: leaving).
(04:59:10 PM) ferretinjapan left the room (quit: Ping timeout: 272 seconds).
(05:01:33 PM) tevador: sech1: updated block initialization specs: https://github.com/tevador/RandomX/blob/dev/doc/specs.md#64-dataset-block-generation[1]
(05:09:54 PM) sech1: so it goes twice through all columns, nice
(05:20:23 PM) linzhi-sonia [~linzhi-so@static.173.42.9.176.clients.your-server.de] entered the room.
(05:33:05 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(05:39:54 PM) tevador: yes
(06:01:27 PM) lafudoci left the room (quit: Ping timeout: 252 seconds).
(06:48:51 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(07:13:51 PM) linzhi-sonia left the room (quit: Remote host closed the connection).
(07:19:21 PM) linzhi-sonia [~linzhi-so@q-ag.de] entered the room.
(07:40:52 PM) [-mugatu-] left the room (quit: Ping timeout: 245 seconds).
(07:49:03 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(08:43:37 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(08:44:00 PM) sech1 left the room (quit: Quit: Leaving).
(11:42:05 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(01:28:49 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(02:54:28 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:27:49 AM) dEBRUYNE left the room ("Leaving").
(04:06:46 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(04:25:52 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(04:49:58 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:51:01 AM) ferretinjapan left the room (quit: Remote host closed the connection).
(04:58:43 AM) linzhi-sonia left the room (quit: Quit: leaving).
(04:59:18 AM) linzhi-sonia [~linzhi-so@q-ag.de] entered the room.
(05:04:43 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:33:09 AM) wowario left the room (quit: Remote host closed the connection).
(05:33:34 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(06:58:37 AM) sech1: That's a big discussion now: https://www.realworldtech.com/forum/?threadid=183905[1]
(06:58:54 AM) sech1: is anyone tracking useful there?
(06:59:02 AM) sech1: *useful points
(06:59:45 AM) sech1: The only things I found so far is that out-of-order pipeline and branch predictors waste a lot of power (presumably)
(07:01:50 AM) tevador: I'm "dev"
(07:02:17 AM) tevador: yes they had some interesting points
(07:02:44 AM) tevador: I'm still not convinced about the wasted power
(07:03:17 AM) tevador: power gating the BPU is probably not possible, that was a good point
(07:04:17 AM) sech1: I found that article about where heat is generated in CPUs: https://arxiv.org/pdf/1808.09651.pdf[1]
(07:04:39 AM) sech1: but it's not very detailed when it comes down to x86 core blocks
(07:06:32 AM) sech1: But I think it's still mostly ALU/FPU, not the rest of pipeline
(07:06:42 AM) sech1: especially when FPU-intensive code runs
(07:06:49 AM) tevador: that's not very useful, x86 core is basically eveything except of L3 cache
(07:07:43 AM) sech1: we can do a test: run some SSE code, then the same code in AVX mode (2xFPU operations) and compare power usage
(07:08:20 AM) tevador: I would be interested in some good comparison of heavy branched code nad branchless
(07:08:22 AM) sech1: with the same clock speed/voltage, turbo-boost off
(07:08:45 AM) sech1: you can just add branches to RandomX which are never taken
(07:08:48 AM) tevador: for example one version with cmp/jmp and one version with cmov
(07:09:11 AM) sech1: something like cmp rax, MAGIC_CONST/je NEVER_TAKEN_DESTINATION
(07:09:37 AM) sech1: and see how it behaves with 10 branches per program, 20 branches per program etc.
(07:09:59 AM) tevador: I have one idea
(07:10:02 AM) sech1: there's still 2^-64 probability it will be taken, but we can ignore it
(07:10:20 AM) tevador: I can test this with the existing COND instruction
(07:10:36 AM) sech1: yes, that's an option too
(07:10:59 AM) tevador: I could just jump 1 isn forward or something
(07:11:18 AM) sech1: and you probably need to remove dataset accesses so you only have load on CPU core itself
(07:11:23 AM) sech1: to get clean data
(07:26:18 AM) tevador: so RandomX currently uses 60-61W over idle
(07:26:27 AM) tevador: on Ryzen 1700 with 8 threads
(07:29:36 AM) midipoet [uid316937@gateway/web/irccloud.com/x-rgmmnqdsjsseovkd] entered the room.
(07:29:52 AM) tevador: without dataset accesses, it's ~64W and 24% faster
(07:31:02 AM) sech1: Is it power at the wall? Or CPU core sensors?
(07:31:23 AM) tevador: wall
(07:31:53 AM) sech1: makes sense then. 5% more power, but more than 5% on CPU core because DRAM access is off
(07:54:31 AM) tevador: so I have replaced setcc instruction with jcc (conditional jump) in COND_R
(07:54:43 AM) tevador: power exactly the same, just performance tanked 5300 -> 4000 H/s
(07:55:18 AM) tevador: I will try to increase the frequency of COND
(09:28:34 AM) sech1: so h/s/watt decreased with branches
(09:28:52 AM) sech1: which means branch predictor and OoO logic started to consume more
(09:29:07 AM) sech1: I think there's also some wasted power on mispredicted branches
(09:29:17 AM) sech1: you need to test the case when all branches are 100% predicted
(09:48:37 AM) tevador: hm, got some strange results
(09:49:01 AM) tevador: I increased COND frequency to 128
(09:49:12 AM) tevador: out of 256
(09:49:59 AM) tevador: and did this: cmp rax, rsp; jne next; inc ecx; next: add r8, rcx
(09:50:08 AM) tevador: cmp rax, rsp is always false
(09:50:57 AM) tevador: and it gets 2795.66 H/s with ~52 W of power
(09:51:26 AM) tevador: if I remove all except add r8, rcx, it gets 6544.87 H/s and ~578 W
(09:51:36 AM) tevador: 57 W*
(09:52:03 AM) tevador: so there must be some other bottleneck
(09:52:09 AM) tevador: probably BTB was exhausted
(09:53:58 AM) tevador: it's definitely not easy to test this...
(10:09:13 AM) tevador: if I decrease the frequency to 64, the branchless version still runs 1.44 times faster and uses the same power
(10:10:10 AM) cjd: This is an interesting thread ^^
(10:11:50 AM) cjd: I'm told that you can shove native code over to a GPU fairly quickly, it's really the driver that takes a long time, and that GPUs are implementing something a bit like a barrel processor design so flooding them with divergent branches is not as much a killer as one might think...
(10:12:38 AM) cjd: Might be interesting to write an opencl interpreter just to see how good they really are at divergent branches
(10:12:49 AM) cjd: *interpreter in opencl
(10:13:11 AM) tevador: I would expect very poor results from an opencl interpreter running on a GPU
(10:17:27 AM) cjd: Interpreters should always be pretty slow, but at least it would give a good idea of how much diversion a GPU is really capable of
(10:18:50 AM) cjd: If they're hyperthreading 4 or 8 threads on a core, that's 4 or 8 * 64 which is not nothing... Just need to be able to quickly jit to the actual asm that the hardware speaks
(10:20:50 AM) cjd: > https://devtalk.nvidia.com/default/topic/508515/running-one-thread-per-cuda-core-or-at-least-allow-for-highly-divergent-register-intensive-kernels/[1]
(10:20:55 AM) cjd: > The main advantage of GPUs over CPUs comes from the fact that GPUs save on the control logic (and caches) and spend their transistor budget on additional arithmetic units instead. (Another advantage comes from the 'hyperthreading' on the GPU being much more advanced than what Intel ever managed to do).
(10:21:37 AM) hyc: I would expect that using larger vectors (AVX) would also tilt some more in GPU's favor
(10:22:40 AM) hyc: Interesting notes on programming AMD Vega https://www.reddit.com/r/Amd/comments/acg22i/musings_on_vega_gcn_architecture/
(10:22:51 AM) tevador: so I changed the branch from always taken to never taken and the performance improved to the level of the branchless version with basically the same power
(10:23:48 AM) cjd: > Wavefront level latency hiding is roughly equivalent to a CPU's SMT / Hyperthreading. Except instead of 2-way hyperthreading, the Vega GPU supports 10-way hyperthreads.
(10:23:55 AM) cjd: ^^from your link
(10:24:14 AM) cjd: 10*64 is quite cool
(10:24:55 AM) tevador: so it looks like we could support almost-never-taken branches without any power penalty
(10:25:10 AM) tevador: taken branches are expensive
(10:25:24 AM) tevador: sech1
(10:25:25 AM) hyc: pipeline flush in a taken branch
(10:25:29 AM) cjd: What's the point of almost-never-taken branches ?  Wouldn't the hardware just ignore them entirely and hope not to score a broken hash ?
(10:25:36 AM) tevador: hyc: not if it's predicted taken
(10:26:10 AM) tevador: cjd: you can set the probability such that each hash has at least 1 taken branch
(10:26:24 AM) tevador: so if you don't handle it correctly, you will have all incorrect results
(10:27:00 AM) tevador: for example 16384 branches per hash and one is taken
(10:27:02 AM) cjd: ahh I see, each one individually is almost never taken but there's a very good chance that at least one of them is taken
(10:27:06 AM) cjd: gotchya
(10:27:28 AM) cjd: sure thing that one is taken ?  or 90% chance ? or what ?
(10:27:41 AM) tevador: soemthing like 99.999...%
(10:27:48 AM) cjd: ok, that's good
(10:27:52 AM) tevador: that at least one is taken
(10:27:56 AM) tevador: you cans et the numbers this way
(10:28:11 AM) tevador: and still have >99% of not taken branches
(10:29:11 AM) sech1: yes, predicted-not-taken branches are basically free on modern CPUs
(10:29:24 AM) sech1: I used this tricks in my CNv2 asm code
(10:30:00 AM) sech1: where I had to correct SQRT result with 1/524288 probability, so I just added a branch which was taken in 1 or 524288 cases on average
(10:30:38 AM) cjd: because of wrong hardware or what ?
(10:30:53 AM) sech1: No, because of rounding
(10:30:58 AM) sech1: I needed exact result, not rounded
(10:31:05 AM) cjd: I see, that's cool
(10:31:43 AM) sech1: so 64-bit FP SQRT instruction gave 19 bits more than was needed so correction was not required most of the time
(10:32:01 AM) sech1: but if these 19 bits are all 0, it's not known what the exact result is
(10:32:44 AM) cjd: do you have a link to the code ?
(10:32:51 AM) sech1: because changing 1 bit (subtracting 1) could ripple-carry to the bits that were needed for exact result
(10:33:00 AM) cjd: *nod*
(10:33:26 AM) sech1: https://github.com/xmrig/xmrig/blob/master/src/crypto/asm/cn2/cnv2_main_loop_ryzen.inc#L103[1]
(10:39:34 AM) cjd: I take it this is the slow verifier? https://github.com/xmrig/xmrig/blob/5cd48f483e513aa2b437d6420218b7ecb4277249/src/crypto/CryptoNight_x86.h#L510[1]
(10:40:39 AM) sech1: yes, but it's written as branch-free code
(10:41:11 AM) sech1: because compiler is not smart enough to arrange branches correctly, it always choose predicted-taken version
(10:42:01 AM) cjd: even with an unlikely() attribute ?
(10:42:12 AM) sech1: Found my code with branches: https://pastebin.com/r8mrz4yG
(10:42:18 AM) sech1: the one I used to create asm code
(10:42:47 AM) cjd: nice
(10:43:25 AM) cjd: I might borrow that for sqrt on a 64 bit posit (which is 58 bit mantissa)
(10:43:52 AM) cjd: well, 59, hidden bit
(10:48:46 AM) sech1: tevador I think we can just use "test reg, 1023/jz" combo to skip a few next instructions or jump a few instructions back with 1/1023 probability
(10:49:06 AM) sech1: *1/1024
(10:49:34 AM) sech1: and when we jump back we need to be sure that this register changes to avoid infinite loops, so there must be some instruction that changes it
(10:50:16 AM) hyc: sounds like you want a decrement-and-branch instr then
(10:50:46 AM) sech1: No, just after take some arithmetic instruction that changes target register and do test/jz combo right after it
(10:51:13 AM) sech1: or inc/test/jz combo to be 100% sure it changes
(10:51:49 AM) sech1: and jump back 4-5 instructions
(10:52:11 AM) sech1: because jumping forward won't help - ASICs will just use predicates to skip execution when needed
(10:54:26 AM) sech1: tevador I think we need to change COND instructions to do this
(10:54:51 AM) sech1: ASIC will just predict these branches as "always not taken", but it'll have to either stall pipeline until branch condition is known
(10:55:00 AM) sech1: or waste some power on speculative execution
(10:55:32 AM) sech1: and GPUHoarder said that branches mess up everything with pipelining
(10:58:32 AM) sech1: "Branching just destroys pipelines" (c) GPUHoarder
(11:04:06 AM) dossier [49e955be@gateway/web/cgi-irc/kiwiirc.com/ip.73.233.85.190] entered the room.
(11:15:12 AM) sech1: tevador I think inc reg/test reg,1023/jz back is safe if we only jump back over instructions that don't change this register
(11:15:25 AM) sech1: then we have a guaratee there won't be an infinite loop
(11:15:58 AM) sech1: a bit more logic into JIT compiler but it's still very simple and quick
(11:41:22 AM) hyc: ? how do we gurantee that in the generated programs?
(11:42:35 AM) sech1: by tracking which registers weren't changed in the last 4-5 instructions
(11:42:40 AM) sech1: and using unchanged register
(11:42:53 AM) sech1: like I said, some additional logic for code generator
(11:43:12 AM) sech1: but it can be down without slowing down JIT compiler
(11:43:31 AM) sech1: *done
(11:46:40 AM) hyc: there is currently no logic at all in the code generator, it's a stream of random bytes
(11:48:05 AM) sech1: but there is logic in JIT compiler
(11:48:12 AM) sech1: it translates VM code to x86
(11:48:39 AM) sech1: it takes O(1) time to track used/unused registers for each new instruction
(11:48:53 AM) sech1: and O(N) time to choose unused register for branch where we have N registers
(11:49:03 AM) hyc: yes but how do you express this in the VM instruction set?
(11:49:20 AM) sech1: just define it in COND instruction
(11:49:24 AM) sech1: as pseudo-code
(11:49:55 AM) sech1: something like "jump back 5 instructions depending on the value of first register that wasn't destination in these 5 instructions"
(11:50:11 AM) sech1: since we have 8 integer registers, such register always exists
(11:50:50 AM) hyc: seems like a fixed value "5 instructions" may be easy to handle
(11:50:57 AM) sech1: no, not 5
(11:51:06 AM) sech1: use 3-bit field to choose how far back it jumps
(11:51:07 AM) hyc: just keep a 2nd queue of the last 5 instructions
(11:51:13 AM) hyc: or the last 8...
(11:51:35 AM) sech1: yeah, but there can be another branch within these 5-8 instructions
(11:51:40 AM) sech1: so proper branching is easier to do
(11:55:56 AM) tevador: sech1: I have a better idea: make each instruction (potentially) conditional
(11:56:06 AM) tevador: this will keep instructions independent like now
(11:56:16 AM) sech1: bad idea, ASIC will use predicates
(11:56:46 AM) tevador: predicate for store?
(11:57:06 AM) sech1: why not if it's in-order pipeline
(11:57:45 AM) tevador: I want to avoid code generator logic
(11:58:12 AM) sech1: then you can't guarantee that branches don't generate infinite loops
(11:59:21 AM) tevador: you can of you have onlt forward jumps
(11:59:25 AM) tevador: only*
(11:59:46 AM) sech1: with only forward jumps ASIC will just use predicates for instructions
(12:00:09 PM) sech1: this is how short forward branches are resolved on GPU by compilers
(12:01:28 PM) sech1: well, it might be hard if there are 2 forward jumps which overlap
(12:01:35 PM) sech1: one branch skips another one
(12:02:35 PM) sech1: no, it's still can be solved with predicates
(12:03:34 PM) sech1: but some instructions (which can be skipped by either of branches) will have to use 2 predicates
(12:04:15 PM) tevador: so you want to jump back 1-8 instructions
(12:04:37 PM) sech1: yes
(12:04:47 PM) sech1: with some low probability
(12:04:50 PM) tevador: for 8, all registers may be modified theoretically
(12:05:01 PM) sech1: yes, so no more than 7 instructions back
(12:05:53 PM) tevador: we have to calculate how many instructions per hash this will add
(12:06:07 PM) sech1: if branch probability is 1/1023, not many
(12:06:41 PM) tevador: so around 16*4 per branch
(12:07:02 PM) tevador: that might be acceptable
(12:07:04 PM) sech1: probability can be tweaked
(12:07:30 PM) sech1: but it must be low to have near 100% branch predicted as not taken
(12:07:42 PM) tevador: yes that's the idea
(12:08:40 PM) sech1: there are 8 COND instructions per program, each can add up to 7 instructions with 1/1023 probability
(12:09:15 PM) sech1: so "56/1023" of instruction is added on each iteration, very little
(12:09:17 PM) tevador: yes, we have 3 unused bits in the mod field
(12:09:35 PM) sech1: and we can use the "111" case for forward jump
(12:09:40 PM) sech1: to force ASIC use predicates too
(12:09:58 PM) sech1: and somewhat compensate instruction count increase
(12:10:50 PM) tevador: we can do 0 = skip next instruction, 1-7 -> backwards jump
(12:11:02 PM) sech1: yes, even better
(12:11:35 PM) sech1: there are special cases when COND instruction is in the beginning of the loop or the very last
(12:11:47 PM) sech1: then we need to limit how far it can jump
(12:11:47 PM) tevador: then this will be ignored
(12:12:01 PM) tevador: if it's the first or last instruction
(12:12:20 PM) sech1: yes, for the case when instrution encoding makes it jump outside of the loop
(12:12:39 PM) tevador: I think this is acceptable, not much additional logic
(12:13:51 PM) tevador: we can use the least recently modified register as condition register
(12:14:02 PM) tevador: this will work for all 1-7 instructions
(12:14:17 PM) sech1: yes
(12:14:25 PM) sech1: tracking least recently modified is simple
(12:14:53 PM) sech1: just have array of 8 elements where each element N is instruction index when register N was changed
(12:15:04 PM) sech1: and then find the smallest value
(12:15:13 PM) tevador: yes exactly
(12:15:41 PM) sech1: plus it will take advantage of OoO execution
(12:16:00 PM) sech1: modern CPUs can execute this branch ahead of other instrutions because this register will be ready
(12:16:27 PM) tevador: so inc reg; test reg, 1023; jz
(12:17:04 PM) sech1: yes
(12:17:09 PM) tevador: we can make 1023 configurable
(12:17:23 PM) sech1: yes, a tweakable parameter
(12:20:02 PM) tevador: so 64 cond instructions per hash, each executed ~2048 times = 1E-56 chance there are no jumps 
(12:20:28 PM) tevador: so ASIC which ignores these branches will not produce any correct hashes
(12:29:13 PM) sech1: "A CMP or TEST instruction immediately followed by a conditional jump can be fused into a
(12:29:13 PM) sech1: single µop."
(12:29:35 PM) sech1: int/test/jz will be only 2 uops on Ryzen
(12:29:37 PM) sech1: low overhead
(12:29:48 PM) sech1: *inc/test/jz
(12:48:49 PM) LSDog_ left the room (quit: Ping timeout: 244 seconds).
(01:19:01 PM) tevador: sech1: backwards jump cannot be handled as a predicate? if you know it will not be repeated
(01:19:37 PM) sech1: hmm
(01:20:17 PM) sech1: technically you could just duplicate previous N instructions, but with predicate
(01:20:23 PM) tevador: exactly
(01:20:57 PM) sech1: so the branch must be not taken with 99.9% probability, but when taken, it must loop some random number of iterations
(01:21:37 PM) tevador: anyways it would be costly to do it as predicated execution, no?
(01:21:46 PM) tevador: you would waste most of the results
(01:22:23 PM) sech1: yes
(01:23:40 PM) tevador: even if it was a loop, you could just unroll it
(01:23:42 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(01:24:22 PM) sech1: we need to ask Tim Olson how hard it's to have predicated execution
(01:24:33 PM) sech1: at least it will slow down in-order pipeline proportionally
(01:24:57 PM) sech1: it'll add ~56 instructions to the each loop iteration
(01:25:03 PM) sech1: 7*8 = 56
(01:25:23 PM) sech1: either way it slows down ASIC/makes it less efficient
(01:25:30 PM) sech1: and doesn't hurt CPU
(01:25:39 PM) tevador: it would add about 32 instructions per iteration, yes
(01:26:49 PM) tevador: actually 29 instructions on average
(01:26:55 PM) tevador: still more than 10%
(01:27:06 PM) sech1: maybe we can jump more than 7 instructions back?
(01:27:20 PM) sech1: Just check when this register was changed and jump to instruction after it
(01:27:24 PM) sech1: can be way more than 7 instructions
(01:27:32 PM) sech1: much harder for predicated execution approach
(01:27:48 PM) tevador: yes, because I'm tracking when the register was last changed anyways
(01:28:07 PM) tevador: so it's for free during compilation
(01:28:26 PM) sech1: and we don't have specific limit, so jumps back can even double loop size for predicated approach
(01:28:29 PM) tevador: but it will add more instructions, so we have to compensate with forward jumps
(01:28:45 PM) sech1: not really if jump probability is 1/1024
(01:29:07 PM) LSDog left the room (quit: Ping timeout: 244 seconds).
(01:29:17 PM) sech1: 8 jumps per program, each for 256 instructions at worst = 2048/1024 = 2 instructions added at worst (on average)
(01:29:31 PM) sech1: much fewer in reality
(01:32:02 PM) tevador: so it jumps more than 20 instructions on average
(01:32:12 PM) sech1: good enough
(01:42:27 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(01:43:26 PM) tevador: sech: sample program: https://pastebin.com/jBV2sd7t
(01:43:39 PM) tevador: first jump is on line 82
(01:45:24 PM) tevador: sech1 *
(01:46:15 PM) sech1: yes, I'm looking at it
(01:47:06 PM) sech1: Most jumps are even overlaping each other
(01:47:23 PM) sech1: should be safe though
(01:47:38 PM) sech1: worst case some jump will trigger twice if two jumps overlap
(01:47:42 PM) tevador: largest jump is 33 instructions
(01:47:59 PM) tevador: in this program
(01:48:12 PM) sech1: randomly overlapping jumps kill the predicated approach
(01:48:22 PM) tevador: yes, that's good
(01:50:41 PM) tevador: also this is good because it prevents cases when some register is unchanged for a long time
(01:51:45 PM) sech1: oh, yes. Jump instruction itself changes the "old" register
(01:52:37 PM) tevador: so in the end the 3 bits in the mod field are still unused
(01:52:58 PM) tevador: this change is using existing implicit entropy
(02:03:26 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:07:26 PM) LSDog left the room (quit: Quit: MONERO NUMBA 1).
(02:09:20 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(02:10:43 PM) tevador: I will use the 3 bits to shift the 1023 mask to it's harder to hardcode
(02:11:35 PM) tevador: hardwire*
(02:13:22 PM) sech1: if you shift it (left) then you need to change "add reg, 1" instruction too
(02:14:56 PM) tevador: yes, by shifting the 1 bye the same amount
(02:15:00 PM) tevador: by*
(02:57:36 PM) OsrsNeedsF2P left the room (quit: Ping timeout: 252 seconds).
(03:16:18 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(03:58:59 PM) tevador: I think I've hit an infinite loop somehow...
(04:13:31 PM) tevador: ok, so this caused an infinite loop: add r8,r13; xchg r8,r13 - both registers have values ending with 0x7ff
(04:15:20 PM) tevador: so xchg must mark both registers as modified I guess
(04:20:25 PM) p0nziph0ne left the room (quit: Ping timeout: 255 seconds).
(04:28:24 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(04:32:03 PM) midipoet [uid316937@gateway/web/irccloud.com/x-ucgweyfdrcgtlmmf] entered the room.
(04:48:59 PM) sech1: "xchg must mark both registers as modified I guess" -> of course
(04:49:05 PM) sech1: because they both change
(04:56:02 PM) wowario left the room (quit: Remote host closed the connection).
(04:56:30 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(05:06:54 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(05:10:16 PM) tevador: another infinite loop *sigh*
(05:12:32 PM) sech1: can you paste this loop so I can look?
(05:14:54 PM) tevador: sech1: https://pastebin.com/i1r9zZvd
(05:15:04 PM) tevador: it's two jumps that overlap
(05:16:37 PM) tevador: yes, I get it, each loop changes the control register of the other...
(05:17:49 PM) sech1: they both do "neg" with another's loop register
(05:17:51 PM) sech1: taking turns
(05:17:56 PM) tevador: bottom loop has r14, top loop r10
(05:17:58 PM) tevador: yes
(05:18:25 PM) tevador: we thought this was impossible?
(05:20:12 PM) sech1: so loop 1 changes r10 to 0, jumps back, then loop 2 chages r14 to 0, jumps back, then r10 is negated to all 1, then r14 is negated to all 1, then everything repeats
(05:20:50 PM) sech1: then problem is "neg" and "inc" are complementary operations
(05:21:15 PM) sech1: (-1)+1 = 0
(05:21:18 PM) sech1: neg(0)=-1
(05:22:40 PM) sech1: can you do a quick test - replace "add reg, 1" with "lea reg, [reg+another_reg+1]"
(05:22:49 PM) sech1: where another_reg is the most recently changed
(05:22:54 PM) sech1: and see if it ever hangs
(05:27:48 PM) tevador: it's more complicated, r10 switches between values ...0000 ...0008 ...FFF8 and when r10 = ...0000 it multiplies r14, which causes it to also end with ...0000 and then the sub instruction at address 0000000000460622 uses r10 as address register, which subtracts E929AF257C580002 from r14, causing it to become ...FFFE, which triggers the jump on the next iteration
(05:28:04 PM) tevador: hell of a coincidence
(05:28:30 PM) sech1: Rupe Goldberg machine, lol
(05:28:30 PM) tevador: so it's not just the neg
(05:29:38 PM) sech1: so, we just disable overlapping loops?
(05:30:19 PM) tevador: I thought we had solved the branching problem :(
(05:31:07 PM) sech1: technically, when you encouter the "jump back" instruction, you should assume it changes all registers in instructions it jumps over
(05:31:09 PM) tevador: yes, so a COND instruction causes all registers to behave like modified
(05:31:27 PM) tevador: this will disable overlaps
(05:31:41 PM) sech1: even without overlaps it's still good enough
(05:32:07 PM) sech1: predicated execution will be 2 times slower because jumps will cover most of the program
(05:33:21 PM) tevador: btw this was nonce 440000 something
(05:35:57 PM) sech1: even single nonce that causes infinite loop is DoS for nodes
(05:36:14 PM) sech1: an attacker can just send it to node and it will hang while verifying
(05:36:49 PM) sech1: so it's safer without overlapping branches for now
(05:37:00 PM) sech1: unless we can come up with somethig provable safe
(05:37:54 PM) tevador: yesm we cannot allow infinite loops
(05:39:18 PM) tevador: so we will know in about 5 minutes if it works or not :D
(05:39:24 PM) tevador: it's running now
(05:39:44 PM) tevador: but I don't see how there could be an infinite loop now
(05:40:41 PM) sech1: if they don't overlap and you track registers correctly, it can't be
(05:41:01 PM) sech1: how fast did it hang before?
(05:41:39 PM) tevador: well, normally it takes ~5 min to run 1M nonces
(05:41:48 PM) tevador: after 10 minutes, I realized something was wrong
(05:42:17 PM) tevador: actually about 4 min for 1 M nonces
(05:42:50 PM) tevador: also I can tell from the power consumption
(05:43:05 PM) tevador: if it gets stuck, power goes down by ~10 W
(05:43:39 PM) tevador: finished \o/
(05:43:40 PM) tevador: Performance: 4179.05 hashes per second
(05:43:52 PM) tevador: so exactly zero effect on performance
(05:43:57 PM) sech1: oh, nice
(05:44:04 PM) sech1: maybe we can even increase branch probability
(05:44:17 PM) tevador: and power consumption is also the same
(05:44:25 PM) tevador: +/- 1 W
(05:44:29 PM) sech1: btw I think you could get infinite loop faster with 50% branch probability
(05:44:47 PM) tevador: right
(05:44:54 PM) tevador: so lets test it
(05:45:02 PM) sech1: try with the overlapping branches
(05:45:07 PM) sech1: and check at which nonce it hangs
(05:45:12 PM) sech1: I bet it will be < 1000
(05:47:19 PM) tevador: with 50% branch prob: Performance: 3443.36 hashes per second
(05:47:21 PM) tevador: not bad
(05:47:39 PM) tevador: I expected much worse
(05:48:07 PM) sech1: I think we can go with 1/128 probability
(05:49:44 PM) sech1: it can be tweaked later anyway
(05:50:20 PM) tevador: 1/128: Performance: 4133.96 hashes per second
(05:50:32 PM) tevador: so about 1%
(05:51:13 PM) sech1: I think it correlates with the number of additional instructions executed because of branches taken
(05:53:29 PM) tevador: it's still 99% of not taken
(05:53:50 PM) sech1: yes, but taken branches increase the total amount of work by 1%
(05:54:14 PM) tevador: yes
(05:55:40 PM) tevador: that's still a lot of taken branches in total, ~1300 per hash
(05:57:35 PM) tevador: 1M hashes completed ~4120 H/s
(05:57:41 PM) tevador: I'm quite satisfied with this solution
(05:58:11 PM) sech1: waiting for Tim Olson's comments then
(05:58:20 PM) sech1: I guess his review will be for branchless version
(05:59:07 PM) tevador: yes
(05:59:29 PM) tevador: I still have to implement this in the interpreter
(05:59:54 PM) tevador: this time I cannot unroll the program, oops
(06:00:23 PM) tevador: so verification without JIT will definitely take a hit
(06:01:17 PM) sech1: we will need JIT for verification anyway
(06:05:25 PM) sech1: technically, you could do branches in unrolled program too
(06:05:52 PM) sech1: https://stackoverflow.com/questions/938518/how-to-store-goto-labels-in-an-array-and-then-jump-to-them[1]
(06:07:10 PM) sech1: only in GCC in clang, but these are Monero's primary compilers
(06:10:06 PM) sech1: Macros and goto's instead of fancy C++ templates, but it can work
(06:10:20 PM) tevador: yes, I did this in the early RandomX prototype, which had only a C code generator
(06:12:36 PM) kopite7 left the room (quit: Quit: Leaving.).
(06:15:52 PM) tevador: btw the blockchain space requirements being limiting is a good point
(06:22:56 PM) tevador: also someone mentioned RandomX tweaks being impossible... this branching tweak would definitely brick all ASICs that are not actual CPUs (e.g. ARM)
(06:36:12 PM) hyc: it assumes that they implement only a specific functioality and nothing more
(06:36:31 PM) hyc: obviously, adding a new feature like branches, to a branchless algorithm, could catch some of them off guard
(06:36:55 PM) hyc: but all of our development is public, they can see every step we take
(06:37:36 PM) sech1: secret development doesn't make sense if this algo will be used for more than 6 months
(06:38:22 PM) tevador: I'm not a fan of tweaks, I'd prefer to make RandomX exhaust all CPU capabilities and tweak only if CPUs get new functions or some fundamental changes like core:cache ratio
(06:39:10 PM) hyc: agreed, we should really design such that tweaks are completely ruled out
(06:39:11 PM) tevador: at the moment we are using everything because the BPU was the last large unused component in the core
(06:39:50 PM) hyc: and apparently we're always paying for speculation, whethwe we used it or not, so might as well get some use out of it
(06:40:10 PM) hyc: this means a cheap/simple in-order core will stall on randomX
(06:40:28 PM) tevador: yes, it was a good kick in the right direction on the hardware forum
(06:40:48 PM) hyc: So ARM cortex-A53 will no longer be a viable starting point for an ASIC
(06:40:59 PM) tevador: it still may be
(06:41:07 PM) tevador: but I'm not expecting a large advantage
(06:41:19 PM) hyc: I would hate to have to retire my 2 dozen ARM boxes here :P
(06:41:21 PM) tevador: using many slow cores has its perks in the design
(06:42:23 PM) tevador: the question is if it affects the barrel processor design which we discussed earlier
(06:42:46 PM) sech1: probably not
(06:43:01 PM) sech1: it executes 1 instruction at a time, and fetches instruction every time
(06:43:23 PM) sech1: it can simply update instruction pointer to wherever it will after current instruction
(06:44:01 PM) sech1: but it's inherently slower because it needs to fetch instruction and its operands every time
(06:44:14 PM) sech1: one more access to SRAM for each instruction
(06:45:02 PM) sech1: I don't think it will be more than 2x efficient
(06:48:24 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(06:52:05 PM) tevador: I guess no need to tell Tim Olson about this new feature? better to have his review regardless
(06:53:56 PM) sech1: We're developing in public, right? Tell after review.
(07:00:30 PM) tevador: hm, how can you change the L3 cache clock separately?
(07:01:21 PM) sech1: in BIOS?
(07:02:04 PM) tevador: I wasn't aware it was possible
(07:04:40 PM) sech1: https://www.anandtech.com/show/6355/intels-haswell-architecture/10[1]
(07:06:15 PM) sech1: "The CPU cores all run at the same frequency, the on-die GPU runs at a separate frequency and now the L3 + ring bus are in their own independent frequency domain."
(07:08:36 PM) sech1: that actually helped when overclocking Haswells
(07:13:58 PM) tevador: so L3 running at 1/4 reduces performance only by 40%
(07:14:09 PM) tevador: in RandomX 
(07:46:11 PM) midipoet [uid316937@gateway/web/irccloud.com/x-suhtzapccbjpjast] entered the room.
(08:37:55 PM) sech1 left the room (quit: Quit: Leaving).
(09:45:21 PM) geonic is now known as ziprar
(09:45:53 PM) ziprar is now known as geonic
(11:23:36 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(01:08:55 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(01:11:01 AM) kopite7 left the room (quit: Client Quit).
(01:13:35 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(02:34:49 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:00:59 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:15:48 AM) linzhi-sonia: so interesting this conversation... happy to be here. it looks like trying to anticipate hardware (chip design) with the intent of limiting performance, or finding some kind of maximum
(03:16:39 AM) linzhi-sonia: the opposite would make more sense :) work with chipmakers to increase performance or efficiency, or decrease cost. but ok.
(03:17:00 AM) linzhi-sonia: why is an algo designed for a chip good, but chip designed for algo is not good?
(03:17:32 AM) Inge-: Centralization.
(03:19:26 AM) sech1: Because an algo designed for an "everywhere" chip (CPU) is good for decentralization
(03:21:22 AM) linzhi-sonia: that was discussed for years...
(03:22:14 AM) linzhi-sonia: ok here is our path forward: we are thinking about a next-gen chip, more programmable
(03:22:47 AM) linzhi-sonia: it can accelerate typical crypto functions needed for node operation, and also mining (ethash, progpow, randomx)
(03:23:12 AM) linzhi-sonia: right now is just thinking, it will be months away to even start on a design
(03:23:30 AM) linzhi-sonia: maybe someone is interested in being involved. we are fairly open.
(03:24:27 AM) linzhi-sonia: this is not "against" randomx. you can continue to anticipate this or that "maximum" hardware performance. it's just a side-effect of the programmability that would make it an efficient chip for randomx.
(03:24:50 AM) linzhi-sonia: very early thinking all this, feedback welcome
(03:26:15 AM) linzhi-sonia: oh btw, another thing. since I see you speculating so much about hardware. my wish is that you guys design an "io-hard" algo
(03:26:18 AM) linzhi-sonia: :)
(03:26:20 AM) Inge-: < linzhi-sonia> that was discussed for years... <-- the Monero community still values algorithms that run on broadly available commodity hardware that had multi-use. Are you able to articulate WHY this is important to the Monero community?
(03:26:42 AM) linzhi-sonia: we already have "memory-hard", which is good. the missing angle is "io-hard", but I'm not sure how one could go about designing that. does something like that already exist?
(03:27:11 AM) linzhi-sonia: Inge-: why what is important?
(03:27:33 AM) linzhi-sonia: decentralization is the result of mainly 3 goals: permissionless, trustless, resilient
(03:27:51 AM) linzhi-sonia: gpus and cpus are asics
(03:28:05 AM) linzhi-sonia: with all asics (including cpu and gpu), cost advantage leads to centralization
(03:28:22 AM) Inge-: linzhi-sonia: Why it is important to the monero community to have a POW algorithm that runs on broadly available commodity hardware with multiple uses (not just monero mining)
(03:28:52 AM) linzhi-sonia: because it follows a line of thought that was contemporary 5 years ago
(03:29:38 AM) linzhi-sonia: when crypto was started, we barely knew what "asic" was. 10,000 USD would have seemed like a huge amount.
(03:29:58 AM) linzhi-sonia: at that time, the concepts of "asic resistance" and "asics lead to centralization" appeared
(03:30:21 AM) linzhi-sonia: take our story: we started with a budget of 1500 USD, all money we had
(03:30:31 AM) Inge-: I am asking if you are able to put on the "Monero hat" and correctly represent the view of the XMR community. I am not asking you to argue against their views.
(03:30:33 AM) linzhi-sonia: we bought a bunch of fpgas, made fpga miners, and sold them for 3000 USD
(03:30:54 AM) linzhi-sonia: we did that a couple times, until we had the funds to try the exciting "asics" (tsmc 110nm)
(03:33:03 AM) linzhi-sonia: Inge-: no I cannot do that, because the "community" is diverse. everything has its time, and culture is self-selecting.
(03:34:09 AM) Inge-: < linzhi-sonia> why is an algo designed for a chip good, but chip designed for algo is not good? <- I don't think you will find an answer to this, unless you are able to understand the XMR community views on the matter.
(03:34:09 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(03:35:07 AM) linzhi-sonia: for example me personally, I sold all my XMR before the first anti-asic hardfork. I have a right to do that, yes? I never got behind the asic-forks either. I am on the sidelines. XMR remains one of the greatest coins! But when I see all this engineering brainpower wasted here over, imo, useless asic-resistance, that's not good. It should be spent on kovri, i2p, etc.
(03:35:35 AM) linzhi-sonia: Inge-: you can totally say "algo designed for chip is the one and only right thing to do!"
(03:35:54 AM) linzhi-sonia: I asked the question as an invitation to think and question one's own beliefs
(03:36:02 AM) sech1 left the room (quit: Quit: Leaving).
(03:36:12 AM) linzhi-sonia: you can already imagine: we think they are equal
(03:36:36 AM) wowario: linzhi-sonia: what do you think about the idea of having an open source hardware design before accepting a pro asic pow?
(03:36:37 AM) linzhi-sonia: it doesn't matter whether algo for chip, or chip for algo. what matters is that it works, scales, is usable.
(03:36:51 AM) linzhi-sonia: I think a switch to "pro-asic" is dangerous, culturally.
(03:37:21 AM) linzhi-sonia: I would hope the core members can 100% unite behind that first, and take the largest part of the community with them emotionally.
(03:37:43 AM) linzhi-sonia: it's very dangerous. years of fighting against asics leave memories.
(03:37:58 AM) linzhi-sonia: I would think the unity of the xmr community is more important than asics or not asics.
(03:38:38 AM) linzhi-sonia: about open source hardware design: yes and no. yes of course the more documentation the better. but in addition I would have a focus on cost and production transparency, and reverse engineering.
(03:39:40 AM) linzhi-sonia: the idea that you can have one open design, and then manufacture it in multiple places, still totally misses what hardware manufacturing is all about: optimizing cost, performance, efficiency, lead-time or reliability.
(03:40:39 AM) linzhi-sonia: back to my programmable chip: if someone is interested, let's keep talking
(03:40:58 AM) linzhi-sonia: but it won't be fast, it's going to be over the next few months
(03:41:36 AM) linzhi-sonia: we would want that chip to be as flexible as possible, so on the mining side with the current dynamics, we would target ethash, progpow and randomx
(03:42:11 AM) linzhi-sonia: on the node side we would target elliptic curve ops, finite or prime field ops, etc
(03:46:02 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:48:45 AM) linzhi-sonia: you ask me to understand your perspective, and I'm here and reading. not just since yesterday. but you also need to understand the hardware perspective, eventually.
(03:48:59 AM) linzhi-sonia: for us the more algos there are the better
(03:49:26 AM) linzhi-sonia: it helps us design a chip that can accelerate them all, it helps on the path to a programmable crypto chip architecture
(03:49:53 AM) linzhi-sonia: I'm seriously curious whether anyone has started to work on "io-hard"
(03:50:17 AM) linzhi-sonia: once you have 10 mio USD, for example, *any* kind of chip can and will be made
(03:50:36 AM) linzhi-sonia: that's a lot of money. some people just totally forget how the crypto scene has changed over the years
(03:50:57 AM) linzhi-sonia: back when 10,000 USD was a lot of money, some millionaire who could come in and make an "asic", and take over the network, was a threat
(03:51:29 AM) linzhi-sonia: but today you are all designing and managing PoW algos that pay out millions of USD per month, even millions of USD a day sometimes.
(03:51:55 AM) linzhi-sonia: the asics are popping up everywhere, and they are "our" asics, not made by some government or NSA or so to crack our networks
(03:52:17 AM) linzhi-sonia: if you are still in the "let's fight asics" mindset, not much I can do about that
(04:07:56 AM) Inge-: It will be interesting to see where you go with that design for sure!
(04:17:07 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:24:07 AM) sech1: linzhi-sonia "a chip that can accelerate them all" sounds like a GPU with crypto instructions, I don't think a startup company can handle this level of R&D
(04:46:01 AM) linzhi-sonia: woah :) sech1 I frankly never know what to make of a comment like that. It's a little bit better than openly wishing us (or anyone) to fail, which we also see a lot. Strange stuff. how many chips have you designed or taped out? what is the basis for your reasoning?
(04:46:09 AM) linzhi-sonia: I know you mean well, just sharing my feeling.
(04:47:11 AM) sech1: The basis of my reasoning? R&D budgets of AMD/NVIDIA
(04:47:25 AM) linzhi-sonia: it's like me saying this: "Monero is cash for a connected world. It's fast, private, and secure. With Monero, you are your own bank." familiar? I don't think a bunch of FOSS devs can handle this level of goals.
(04:47:33 AM) linzhi-sonia: I am not saying this! :)
(04:47:37 AM) linzhi-sonia: I believe you guys can, it's great.
(04:47:59 AM) linzhi-sonia: but you shouldn't, at all, worry about our goals and what we can or cannot pull off. we will definitely try, take my word.
(04:47:59 AM) sech1: Software development is different, devs can work for free during their spare time
(04:48:17 AM) linzhi-sonia: do you worry about competition with Morgan Stanley? Alibaba? Google?
(04:48:26 AM) linzhi-sonia: should I compare Monero "budget" with the budget of those guys?
(04:48:36 AM) linzhi-sonia: so anyway. we shall continue.
(04:48:58 AM) linzhi-sonia: we are very optimistic about our path, naturally, otherwise we wouldn'd do it
(04:49:07 AM) linzhi-sonia: no need to repeat the chip specs
(04:49:15 AM) linzhi-sonia: randomx is a good target
(04:49:19 AM) linzhi-sonia: I wish someone would work on io-hard
(04:49:47 AM) sech1: I you think you can do this it's great. But the general-purpose chip you're trying to do will be a GPU by definition (General-Purpose-Unit). With similar level of complexity.
(04:49:50 AM) linzhi-sonia: AMD/NV are huge bureaucratic organizations
(04:49:59 AM) linzhi-sonia: no no, totally not
(04:50:21 AM) linzhi-sonia: "GPU" is a market that is monopoly-controlled by nvidia, lots of patents, lots of invisible business entry barriers
(04:50:33 AM) linzhi-sonia: we will stay far away from that
(04:50:53 AM) linzhi-sonia: these chips are dinosaurs
(04:51:07 AM) linzhi-sonia: big, expensive
(04:51:19 AM) linzhi-sonia: like I said. that's as if I compare Monero with Morgan Stanley
(04:51:33 AM) linzhi-sonia: you wouldn't even know where to begin rejecting that comparison
(04:51:44 AM) linzhi-sonia: I say "You cannot do what you claim to do because you are not as big as Morgan Stanley"
(04:51:47 AM) linzhi-sonia: so weird, yes?
(04:52:01 AM) linzhi-sonia: "If you would succeed with what you claim to do, you would be like Morgan Stanley"
(04:52:04 AM) linzhi-sonia: ahhh
(04:52:05 AM) linzhi-sonia: no! :)
(04:52:06 AM) linzhi-sonia: ha ha
(04:52:43 AM) linzhi-sonia: we have nothing to do with NV, AMD, GPU, etc.
(04:58:38 AM) hyc: "IO-hard" would imply contiual access to a large off-chip data set? like the blockchain itself? I thought we discussed this already several days ago
(04:59:04 AM) hyc: it has been proposed in the past as well, as a way to discourage mining pools
(04:59:18 AM) linzhi-sonia: interesting
(04:59:22 AM) linzhi-sonia: I never saw that connection
(04:59:27 AM) linzhi-sonia: got a link?
(04:59:30 AM) hyc: if every mining node needs a complete copy of the blockchain
(04:59:39 AM) linzhi-sonia: why would io-hard discourage mining pools?
(04:59:44 AM) hyc: sorry, no recent link, this is a very old conversation
(04:59:47 AM) linzhi-sonia: need to think about it
(05:00:02 AM) linzhi-sonia: for us from the chip side, io is the 3rd dimension: logic, memory, io
(05:00:32 AM) linzhi-sonia: if a PoW algo would be io hard, it would force (reward) interesting new chip designs
(05:00:33 AM) hyc: sure
(05:00:46 AM) hyc: but IO is too ambiguous
(05:01:02 AM) linzhi-sonia: quick googling didn't lead to anything
(05:01:08 AM) hyc: a small cluster of miners might share a single dataset over multi-gigabit ethernet
(05:01:23 AM) linzhi-sonia: yes true. but now you start to think about it, design it...
(05:01:26 AM) hyc: or it might require a closely coupled NVMe SSD
(05:02:06 AM) hyc: anyway, there are lots of options, with broad range of latencies. too variable.
(05:02:47 AM) linzhi-sonia: maybe one more thought from me, re: "switch to asic-friendly"
(05:03:04 AM) linzhi-sonia: first that worries me from a unitedness/culture perspective
(05:03:18 AM) linzhi-sonia: on the technical side, I cannot follow the idea that "asic friendly" means logic-only
(05:03:28 AM) linzhi-sonia: that sounds like adding new misconceptions on top of old ones
(05:03:49 AM) linzhi-sonia: logic-only asics are subject to economics same as logic+memory asics
(05:04:13 AM) linzhi-sonia: I don't see the connection the same way. you can stay on a logic+memory PoW and be "asic friendly"
(05:05:26 AM) linzhi-sonia: for short-term considerations, a few months, yes you can safely make these kinds of assumptions
(05:06:06 AM) linzhi-sonia: but if you want to have a concept that can be stable for 3, 5, 10 years and be stable once the economics go up (1 mio USD, 10 mio USD, 100 mio USD), then assuming asic-friendly means logic-only cannot hold
(05:06:42 AM) hyc: what do you mean by logic-only asic? something like sha3 with a small simple algorithm?
(05:06:54 AM) linzhi-sonia: yes
(05:07:30 AM) linzhi-sonia: I see many times when people discuss "we should switch to asic-friendly", they mean sha3/keccak etc.
(05:07:35 AM) hyc: what is the thread that you perceive? bitcoin has been running for years on logic-only sha256
(05:07:43 AM) linzhi-sonia: no threat
(05:07:44 AM) hyc: s/thread/threat/
(05:08:02 AM) linzhi-sonia: you can be asic-friendly on ethash, progpow, randomx
(05:08:27 AM) linzhi-sonia: asic-friendly to me means to start to use asics, rather than fight them
(05:08:33 AM) linzhi-sonia: and be proud of bricking asics :)
(05:09:00 AM) hyc: there are people talking about coexistence, sure.
(05:09:14 AM) hyc: ETH currently appears to have ASICs and GPUs coexisting
(05:09:25 AM) linzhi-sonia: sure
(05:09:55 AM) hyc: but that is only a realistic discussion if ASICs don't completely outclass other hardware
(05:10:33 AM) hyc: right now the most ubiquitous processing device in the world resides in smartphones
(05:10:45 AM) hyc: we want to leverage those, to ensure decentralization
(05:11:03 AM) hyc: can't do that if we require everybody to go order a new ASIC
(05:11:26 AM) linzhi-sonia: those are some of the most centrally controlled, expensive and patented chips in the world
(05:11:58 AM) hyc: centrally controlled? not really. multiple different makers.
(05:12:04 AM) hyc: sure, they all license from ARM
(05:12:27 AM) hyc: but there are different license levels. E.g. Qualcomm's license allows them to do independent innovation
(05:12:46 AM) linzhi-sonia: ok! from our side we are not worried about this competition anyway, as I explained
(05:13:35 AM) linzhi-sonia: there will always be asics that outperform such chips, and you need to do constant hardforking/bricking
(05:14:05 AM) linzhi-sonia: "constant" can be quantified, say in less than a year, and with 5 mio USD or more on the table
(05:14:12 AM) linzhi-sonia: just as a ballpark
(05:14:37 AM) linzhi-sonia: the best asic resistance is if you go back a few years and make coins worth much less
(05:14:45 AM) linzhi-sonia: or decrease the security budget (pow fees) a lot
(05:15:01 AM) hyc: well, tail emission kicks in in 3 years
(05:15:53 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:18:12 AM) hyc: what would be the difference between a randomX ASIC and an ARM/Intel/AMD CPU?
(05:18:54 AM) hyc: if a really good chip design comes along, why wouldn't we just modify it slightly and use it as a general purpose programmable computing chip?
(05:21:55 AM) hyc: still there linzhi-sonia?
(05:22:00 AM) linzhi-sonia: yes
(05:22:16 AM) linzhi-sonia: this is the thought path we hear over and over
(05:22:46 AM) sech1: "if a really good chip design comes along" then AMD/Intel would be the first to tear it down and reverse-engineer it
(05:22:56 AM) linzhi-sonia: maybe your idea of what a chipmaker is, how they function, is wrong
(05:22:59 AM) sech1: or just buy whoever made it
(05:23:08 AM) linzhi-sonia: please think of a chipmaker first as a hardware maker
(05:23:09 AM) linzhi-sonia: just that
(05:23:18 AM) linzhi-sonia: you order 5 chairs to some specs, you get them
(05:23:26 AM) linzhi-sonia: you order 5000 chairs, you get them
(05:23:37 AM) linzhi-sonia: chip business is hardware business
(05:23:42 AM) linzhi-sonia: supply chain is very important
(05:23:50 AM) linzhi-sonia: they compete with each other
(05:24:09 AM) linzhi-sonia: economics are very important. inventory, product cycles, cost
(05:24:41 AM) linzhi-sonia: I give you an example: let's take a chip design team
(05:24:43 AM) linzhi-sonia: 5 people
(05:24:45 AM) linzhi-sonia: small team
(05:24:56 AM) linzhi-sonia: let's say 200k USD fully loaded per person, that's 1 mio USD / yr
(05:25:09 AM) linzhi-sonia: what is the main worry of a chipmaker?
(05:25:18 AM) linzhi-sonia: that the team is always busy! always designing "some" chip
(05:25:23 AM) linzhi-sonia: that's all
(05:25:28 AM) linzhi-sonia: it's not world domination
(05:25:43 AM) linzhi-sonia: you tapeout, then the chip team will do what?
(05:25:46 AM) linzhi-sonia: wait 3 months?
(05:25:52 AM) linzhi-sonia: prepare for chip-back?
(05:25:58 AM) linzhi-sonia: start a new design right away?
(05:26:45 AM) linzhi-sonia: back to the hypothesis "why not modify it slightly and use it as a general purpose programmable chip"
(05:27:19 AM) linzhi-sonia: noone would buy such a chip?
(05:27:41 AM) hyc: ... for Intel, it is about world domination
(05:28:12 AM) linzhi-sonia: chipmakers may be less scary than you think
(05:28:33 AM) hyc: if you can produce a design that beats them on 2 out of 3 of power/performance/cost that's going to be noted
(05:28:48 AM) linzhi-sonia: not really, they won't care. do you think Morgan Stanley cares about Monero?
(05:29:05 AM) linzhi-sonia: (sorry I keep making this horrible comparison, kinda my revenge today :))
(05:29:17 AM) hyc: I'm pretty sure that Intel and AMD are always reverse-engineering each other's chips
(05:29:22 AM) linzhi-sonia: yes
(05:29:26 AM) linzhi-sonia: of course
(05:29:31 AM) linzhi-sonia: competitive analysis
(05:29:37 AM) hyc: yes
(05:30:07 AM) linzhi-sonia: a little startup from shenzhen is no threat to nv/amd/intel
(05:30:46 AM) hyc: so now we come along with a PoW algorithm that requires general programmability and some ASIC desginer creates a chip that outclasses AMD/Intel/Nvidia
(05:30:58 AM) linzhi-sonia: yes
(05:31:00 AM) hyc: that's going to be interesting, to a lot of people.
(05:31:11 AM) linzhi-sonia: I would hope so!
(05:31:14 AM) linzhi-sonia: we like it
(05:31:54 AM) linzhi-sonia: at the beginning of "GPU", it wasn't clear which algos or operations should be hardware accelerated
(05:31:58 AM) linzhi-sonia: it emerged
(05:32:21 AM) linzhi-sonia: today we have this big and successful architecture, which can be successfully applied to many computing problems
(05:32:27 AM) linzhi-sonia: (the GPU)
(05:33:00 AM) linzhi-sonia: I think crypto will lead to one, or more, new commercially successful architectures, with strong software stack and software integration
(05:33:24 AM) linzhi-sonia: there is a huge difference between "computing architecture" and "commercially successful computing architecture"
(05:33:37 AM) linzhi-sonia: it looks like Google is onto something with the TPU, for example
(05:33:49 AM) hyc: possibly. there have already been SSL accelerators 
(05:33:55 AM) linzhi-sonia: yes!
(05:33:56 AM) linzhi-sonia: exactly
(05:34:10 AM) linzhi-sonia: the question is which architecture emerges as new commercially viable one, if any
(05:34:10 AM) hyc: they're not common outside of big data centers, afaics
(05:34:17 AM) linzhi-sonia: maybe noone
(05:34:22 AM) linzhi-sonia: maybe it all goes back to the TPU
(05:34:25 AM) linzhi-sonia: sorry, typo: GPU
(05:34:33 AM) linzhi-sonia: maybe Google will give up on the TPU one day
(05:34:40 AM) linzhi-sonia: but you cannot blame startups for trying, right?
(05:34:45 AM) linzhi-sonia: so maybe it's more clear what we do
(05:34:48 AM) linzhi-sonia: we are not a threat to anyone
(05:34:51 AM) linzhi-sonia: we are chip designers
(05:35:02 AM) hyc: the TPU makes sense for their goals. 8-bit math, lots of ops/sec as cheaply as possible
(05:35:09 AM) linzhi-sonia: we always start with - currently - commercially unsuccessful computing architectures. by definition.
(05:35:37 AM) linzhi-sonia: hyc: let me tell you from my perspective what great thing google is doing with the TPU
(05:35:48 AM) linzhi-sonia: first they setup a software framework, tensorflow
(05:36:05 AM) linzhi-sonia: they make it such that any app can be compiled for different chips: cpu, gpu, fpga (I think), tpu
(05:36:08 AM) linzhi-sonia: now you can compare!
(05:36:24 AM) linzhi-sonia: if some google-internal app wants to rollout, they can decide which chip to buy
(05:36:36 AM) linzhi-sonia: and the tpu team has to compete with whatever the cpu, gpu, fpga guys have to offer
(05:36:45 AM) linzhi-sonia: that looks like a very strong model
(05:36:54 AM) linzhi-sonia: it doesn't mean the tpu will stay
(05:37:07 AM) linzhi-sonia: but it means google creates a market (economic) opening for a new chip architecture
(05:37:26 AM) linzhi-sonia: maybe the cpu, gpu, fpga guys can defend their architectures, fine
(05:37:31 AM) linzhi-sonia: then google will close down the tpu unit
(05:37:44 AM) linzhi-sonia: but they opened it up
(05:37:48 AM) linzhi-sonia: PoW algos do the same thing, first
(05:37:56 AM) linzhi-sonia: they open up a chance (reward mechanism) for new chips
(05:38:26 AM) linzhi-sonia: every time you "brick" (hardfork), you are actually also commissioning a new chip
(05:38:32 AM) linzhi-sonia: you are setting a bounty for a new design
(05:38:46 AM) linzhi-sonia: for monero, currently 100k usd / day
(05:39:15 AM) linzhi-sonia: hyc: which ssl accelerator do you know?
(05:39:19 AM) stoffu: 6:07 PM <linzhi-sonia> I see many times when people discuss "we should switch to asic-friendly", they mean sha3/keccak etc. << The rationale is to minimize the verification cost for everyone. Going ASIC friendly with CryptoNight/RandomX/Ethash makes no sense because laptops/smartphones will still have to pay the high verification cost while being unable to participate in mining.
(05:39:57 AM) hyc: I haven't used any SSL accelerators myself
(05:39:57 AM) linzhi-sonia: stoffu: yes asymmetry of work/verification is very important
(05:40:18 AM) linzhi-sonia: but don't ask me why that argument seems to be a lesser argument than "asic resistance"
(05:40:30 AM) hyc: but I've worked on OpenSSL and looked at its Engine interface for supporting accelerators...
(05:40:43 AM) linzhi-sonia: oh, interesting. will google
(05:40:43 AM) stoffu: I don't ask then
(05:41:15 AM) linzhi-sonia: I'm around too long. when crypto started, we feared "asic" because noone had money
(05:41:43 AM) linzhi-sonia: some "rich guy, or big corp, or government" coming with an asic was a threat to our emerging networks
(05:41:52 AM) linzhi-sonia: but hey, this has changed 100x over
(05:42:08 AM) hyc: those things are still a threat to monero
(05:42:18 AM) linzhi-sonia: you are paying out 100k usd / day
(05:42:25 AM) linzhi-sonia: use it well! use it for your goals
(05:42:37 AM) linzhi-sonia: your "bricking" devalues your own network
(05:42:39 AM) hyc: we aren't paying it out to ourselves
(05:44:04 AM) hyc: history shows that the market valuation of monero pays no attention to its technical fundamentals. the price moves at the whim of market makers. not in reaction to any development features
(05:47:44 AM) cjd: I would suggest that markets, to personify them, do react to fundimentals but they jealously guard their unpredictability
(05:51:41 AM) hyc: stoffu - on that note of verification costs, the test results we've collected so far don't look like randomX is such a burden
(05:52:10 AM) linzhi-sonia: hyc: how do you quantify the asymmetry vs. decentralization force?
(05:52:24 AM) hyc: what do you mean?
(05:52:26 AM) linzhi-sonia: if verification is 1.5x slower, 2x, 5x, 10x - what does it mean?
(05:52:35 AM) stoffu: Requirement of 256MB seems like a big burden.
(05:53:01 AM) hyc: from what I can see, RandomX is faster than Cryptonight
(05:53:10 AM) stoffu: Currently the consumes only 70MB or so when syncing
(05:53:31 AM) hyc: 256MB in a world of 6GB smartphones seems like nothing to worry about
(05:53:42 AM) linzhi-sonia: the increased verification cost is definitely one aspect of the "random" class of memory-hard algos I don't understand
(05:54:00 AM) linzhi-sonia: it seems to be thrown under the bus
(05:54:28 AM) linzhi-sonia: but I have no data, paper, study that would be able to quantify the pros/cons of a bigger asymmetry
(05:54:58 AM) hyc: at this point I'm probably still the only person in the world routinely running a monero fullnode on their phone. it's not like we're hurting a lot of users.
(05:55:14 AM) linzhi-sonia: which phone?
(05:55:20 AM) hyc: Huawei P10
(05:55:30 AM) hyc: previously was running on a P9-Lite
(05:55:34 AM) linzhi-sonia: nice
(05:55:38 AM) stoffu: It'll hurt exchanges listing many coins. The higher the cost to run full node, the less incentive to list it.
(05:55:45 AM) linzhi-sonia: that's very cool!
(05:55:54 AM) stoffu: Also for merchants accepting payment in various cryptocurrencies.
(05:56:20 AM) linzhi-sonia: totally agree on bringing full node costs down
(05:56:35 AM) linzhi-sonia: and naturally, I think asics can help with that :)
(05:57:04 AM) linzhi-sonia: you guys may say "oh no! more things we need to brick!" :) (just kidding...)
(05:57:45 AM) linzhi-sonia: hopefully our programmable crypto chip can help with full node speed and cost
(05:57:59 AM) linzhi-sonia: those are our design goals...
(06:10:07 AM) sech1: stoffu the cost to run full node is mainly disk space, not RAM
(06:10:40 AM) stoffu: Disagree.
(06:11:26 AM) sech1: I disagree with your disagreement
(06:11:55 AM) stoffu: Then goodbye
(06:12:25 AM) sech1: Very useful conversation, lol
(06:13:58 AM) cjd: 09:53 < linzhi-sonia> the increased verification cost is definitely one aspect of the "random" class of memory-hard algos I don't understand   <-- Algo designers are up against a wall because any way that verification becomes faster allows mining to become more parallel, because an obvious way to mine is attempt "verification" on sequencial nonces
(06:14:20 AM) stoffu: Good luck Monero with RandomX, I’m out.
(06:14:55 AM) sech1: wtf is wrong with you?
(06:15:13 AM) stoffu: This isn’t something I subscribed to. Kinda cultish
(06:16:15 AM) cjd: linzhi-sonia: super description of the problem space here: https://www.gwern.net/Self-decrypting-files[1]
(06:21:02 AM) sech1: stoffu I can say they same for sudden ASIC supports including fluffy
(06:21:10 AM) sech1: *the same
(06:21:32 AM) sech1: very suspicious a few people started pushing ASICs so hard
(06:22:03 AM) sech1: while they had completely opposite stance a few months ago
(06:23:34 AM) moneromooo: Can you point me to a couple of those examples ? AFAIK fluffy long had this "ASIC when it makes sense, it does not make sense yet" opinion.
(06:23:50 AM) sech1: he had "when ASIC is commoditized" stance before
(06:24:06 AM) sech1: Now he's like "switch to SHA3 first and then ASIC will be common"
(06:24:08 AM) sech1: see the difference?
(06:24:15 AM) moneromooo: I meant links :)
(06:25:24 AM) sech1: https://github.com/monero-project/monero/pull/4218#issuecomment-418086651[1]
(06:26:05 AM) moneromooo: That is not any different AFAICT.
(06:26:23 AM) sech1: SHA3 is not commoditized and Monero it too small to change it
(06:27:08 AM) sech1: Nothing with SHA3 changed since that quote
(06:27:37 AM) moneromooo: Can you paste here what you read here, on the off chance you're reading something else than I am ?
(06:27:45 AM) moneromooo: what you read there
(06:28:02 AM) moneromooo: Because I don';t see anything about SHA-3 or wanting to switch to ASICs.
(06:28:25 AM) moneromooo: (in the near future anyway)
(06:28:47 AM) moneromooo: I find it unlikely one of us would be MITM'd to change that post but you never know.
(06:35:55 AM) sech1: "Note that I'm not the decider of things; if the community decides it wants to be ASIC resistant forever who am I to do otherwise. But beyond that, @SChernykh is correct - it is my hope that we stave off ASICs until there is an algorithm we can switch to that is sufficiently commoditised."
(06:36:00 AM) sech1: His post form September
(06:36:13 AM) sech1: It wasn't edited, I just double-checked my e-mail notification from that time
(06:37:21 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(06:38:07 AM) moneromooo: Good. I read that too. I don't read this as "sudden ASIC supports".
(06:39:34 AM) sech1: No, I mean his recent posts where he clearly changed from "Commoditized ASIC first then switch" to "Switch first then ASICs"
(06:40:18 AM) moneromooo: OK. I asked for links to that.
(06:40:54 AM) sech1: https://github.com/monero-project/meta/issues/316#issuecomment-471951861[1]
(06:41:08 AM) sech1: "(1) choosing an algorithm where we can dominate the mining capacity; (2) choosing an algorithm that is easy to ASIC, is general purpose, and is easy to validate - I suggest SHA3; and (3) setting that fork date right now so that ASIC manufacturers have a few years to get their act together. "
(06:41:54 AM) sech1: I mean, this plan is naive. Monero is too small to drive ASIC industry
(06:42:09 AM) sech1: There will be SHA3 monopoly in Monero at the start
(06:44:05 AM) dEBRUYNE: Too small now, but maybe not in 3-4 years
(06:44:18 AM) moneromooo: That does not look like a 180 to me. It's essentially saying "we tried, it did not work out as well as we hoped, maybe we should try to force the commoditization part".
(06:44:42 AM) moneromooo: About "Monero is too small to drive ASIC industry", well, several such companies did make CN ASICs.
(06:44:52 AM) moneromooo: It's less expensive now for sure.
(06:45:08 AM) sech1: They only did it during crazy bull run of 2017
(06:45:12 AM) dEBRUYNE: sech1: As far as I can see, fluffypony would be okay with a path where we go to RandomX first and switch to SHA3 in case that fails
(06:45:15 AM) sech1: Because it became profitable
(06:45:25 AM) moneromooo: They did it again very recently.
(06:45:36 AM) moneromooo: Admittedly, maybe the extra design was only incremental.
(06:45:37 AM) sech1: Then they had working CN design, so it was less expensive to create CNv2 ASICs
(06:46:10 AM) moneromooo: That's why I think stoffu's experiment will not tell us much anyway. But I'm still curious to see what happens.
(06:46:27 AM) dEBRUYNE: sech1: I wonder when they made the decision about profitability though
(06:46:34 AM) sech1: What happens is FPGAs will flood SHA3-coin first
(06:46:35 AM) dEBRUYNE: Because Nov 2017 Monero was still at $100 approximately
(06:46:47 AM) dEBRUYNE: And ASICs appeared in January I think
(06:46:57 AM) sech1: ASICs appeared much earlier, but at small scale
(06:47:21 AM) sech1: maybe a few "pilot" chips that shared wafers with something else
(06:47:31 AM) dEBRUYNE: I see, but when did you think Bitmain made the decision regarding profitability?
(06:47:40 AM) dEBRUYNE: Because $100 is not that far off from the current price (in the grand scheme of things)
(06:47:42 AM) sech1: FPGA designs for CN existed in 2016 already
(06:47:54 AM) sech1: that's all you need to tape out an ASIC quickly when it's profitable
(06:48:36 AM) sech1: When they saw that with $100 they can tape out ASICs that ROI in a week
(06:48:42 AM) sech1: Design was already done by then
(06:49:21 AM) cjd: Is there a documented list of objectives for a future mining algo ?     I hear "prevent asics", then "accept asics if they're commodity", then "but not sha256 because they're *too* widely deployed",  feels like there needs to be a list of baseline objectives
(06:49:40 AM) sech1: just check in any calculator with historical data - $500 ASIC doing 220 kh/s would ROI very quickly
(06:51:42 AM) sech1: Current situation is different. If what GPUHoarder says is true, CNv2 ASICs didn't ROI and were not meant to ROI at all
(06:52:11 AM) sech1: He claimed there were "some buyers of CNv2 hashpower" who didn't care about ROI, only hashpower and efficiency
(06:52:31 AM) sech1: And if he's right, we will see CN/R ASICs this summer
(06:53:00 AM) sech1: what were their motives remains unclear
(06:54:11 AM) sech1: if we go deep into conspiracy theory territory, it could be a push for ASIC-friendly algo on Monero
(06:54:27 AM) sech1: create ASICs, spread FUD in community, make them fork, then rinse and repeat
(06:54:40 AM) dEBRUYNE: Did he mean ASIC manufacturers are mining at a loss to influence the debate?
(06:54:44 AM) sech1: recent discussions on Github kind of align with it
(06:54:57 AM) sech1: He did mean it, yes
(06:55:03 AM) sech1: But no actual proof
(06:55:05 AM) dEBRUYNE: Ok, wasn't entirely sure
(06:56:17 AM) sech1: It could be conspiracy, or just some rich investor who didn't know how Monero works and just put numbers in calculator
(06:56:25 AM) sech1: Never underestimate people's stupidity
(06:56:44 AM) cjd: Oh stupid rich guy sounds way more plausible to me
(06:56:46 AM) dEBRUYNE: Right
(06:57:31 AM) dEBRUYNE: Btw sech1, I don't think some people have done an absolute 180 degree turn. It's more like that *if* RandomX fails, we shouldn't further try to fight this battle (as we've basically exhausted our options) and switch to an ASIC friendly algorithm
(06:57:47 AM) dEBRUYNE: And I think you previously agreed with such a course of action too
(06:58:07 AM) cjd: If you want to influence the discussion, you really want to spread FUD that the designers of CN/R / RandomX / etc have tricks up their sleeves which is allowing them to mine faster, it's way cheaper to buy github comments than unprofitable ASICs
(06:58:38 AM) dEBRUYNE: cjd: Right, and I've not yet seen any of such comments
(06:58:55 AM) sech1: I totally agree that we should go with RandomX and officially stop tweak-schedule and emergency forks
(06:59:00 AM) sech1: If it fails then it fails
(06:59:17 AM) moneromooo: It could also be an entity wanting to fuck monero up. Plenty of those are enemies of privacy.
(06:59:27 AM) sech1: But I don't think it'll fail entirely, it'll be more like current ETH situation worst case
(06:59:30 AM) cjd: ehhh, cheaper methods IMO
(07:00:04 AM) dEBRUYNE: sech1: Do you think we should switch to SHA3 if it fails entirely?
(07:00:41 AM) cjd: Why not ProgPoW ?   It's GPU-friendly and there are tons of GPUs in circulation already...
(07:01:18 AM) dEBRUYNE: ProgPoW would also put us at risk of getting attacked by ETH GPU miners
(07:01:26 AM) dEBRUYNE: Though I guess that is currently applicable too
(07:01:38 AM) cjd: GPUs are GPUs
(07:03:02 AM) sech1: It can't fail "entirely". 2x more efficient ASICs for RandomX - this is possible. But to do something like 10x you need more R&D than AMD and Intel do and develop entirely different architecture.
(07:03:55 AM) dEBRUYNE: Assume it fails entirely for a moment
(07:03:59 AM) sech1: and I'm talking about power efficiency. It's even harder to get better $/hash efficiency because ASICs don't have such economies of scale as CPU vendors do.
(07:04:39 AM) dEBRUYNE: I am trying to get your opinion on a situation where your assumptions don't hold and it fails entirely
(07:04:46 AM) dEBRUYNE: on a course of action*
(07:05:18 AM) cjd: What are the failure modes ?
(07:05:23 AM) sech1: Why switch then? Declare officially than PoW is fixed, then other ASIC manufacturers will announce their ASICs.
(07:05:30 AM) sech1: *that PoW is fixed
(07:05:51 AM) cjd: If the failure mode is that it's ASIC friendly, indeed why bother switching to something that is "asic friendly" :)
(07:06:13 AM) sech1: RandomX is not that hard to implement, it's basically many CPU pipelines + memory controller. Well known building blocks for ASIC designers.
(07:06:31 AM) moneromooo: The hope is that this will mean more ASIC manufacturers competing.
(07:06:44 AM) dEBRUYNE: sech1: I posted why on Github:
(07:06:46 AM) dEBRUYNE: "If you are going to allow ASICs, you'd want to adopt a simple algorithm that has the least possible amount of optimizations. This levels the playing ground and closes the gap between ASIC manufacturers. If you leave room for a lot of optimizations, you will probably end up with a single dominating manufacturer, which is potentially dangerous for the network."
(07:07:13 AM) dEBRUYNE: Also there would be verification performance improvements from switching
(07:07:25 AM) cjd: How many serious players are there in sha256 space ?
(07:09:05 AM) cjd: If everybody's just using bitmain because bitmain has the 7nm process then what's the difference ?    (I don't know if this is true or not)
(07:09:26 AM) sech1: SHA256 was simple too yet it took many years before everyone got roughly the same performance. Optimizations are not only in the algorithm, but chip technology itself/supplier chains etc.
(07:10:03 AM) cjd: Ok so if I understand you well, there are a lot of players but for a long time it was a monopoly
(07:10:12 AM) cjd: or oligopoly, whatever
(07:10:35 AM) dEBRUYNE: sech1: That point is more related to the ASIC resistance vs pro ASICs debate. Arguably it does not apply to RandomX ASICs vs SHA3 ASICs
(07:13:36 AM) sech1: even if RandomX fails, it'll fail to less degree than CPU vs SHA3 ASIC
(07:13:52 AM) sech1: 10x gap is not 1000000x gap
(07:13:57 AM) cjd: So if it's better to make something that's "easy" for ASIC manufacturers to implement, yet remain incompatible with bitcoin in order to avoid raids, wouldn't the best thing be to take sha256 and make a tiny change which means ASIC manufacturers just need to change a few wires in their design and tape out ?
(07:14:02 AM) dEBRUYNE: I don't consider 2x a failure, 10x is a definitive failure
(07:14:06 AM) dEBRUYNE: Because it will drive out all other miners
(07:14:06 AM) sech1: It will be beneficial to still be able to mine with CPU even with ASIC-dominated network
(07:14:42 AM) sech1: not mine at a profit, but simple when there is no other way to get some XMR and no access to an ASIC
(07:15:06 AM) dEBRUYNE: Whether that is worth the trade-off of the network being at risk is another question
(07:15:32 AM) sech1: definitely better for adoption
(07:16:19 AM) moneromooo: cjd: a small tweak means that there is a high risk of next miner gen being able to do both.
(07:16:39 AM) cjd: I see
(07:18:07 AM) dEBRUYNE: Adoption means little if there's a single entity with 80-90% of the hashrate
(07:18:16 AM) dEBRUYNE: Which happens if you have a stance of asic resistance and someone manages to build an efficient asic
(07:18:23 AM) dEBRUYNE: As we've seen twice now
(07:34:16 AM) stoffu: I don’t understand why so many people put so much trust on someone like sech1 who sounds very unprofessional. If the majority of the community trust him more than fluffypony/smooth, it’s not the same community I knew, and I no longer find it cool.
(07:34:44 AM) midipoet [uid316937@gateway/web/irccloud.com/x-pvuqysgrumxhlohg] entered the room.
(07:36:44 AM) moneromooo: The code seems to make sense...
(07:37:30 AM) moneromooo: If you think the code does not do what it purports to do, please point it out.
(07:39:05 AM) moneromooo: In the end, it's back to "whoever does, does". It's the best we've got at the moment.
(07:39:39 AM) moneromooo: You only think it's not the best because your assumptions have changed, but not everyone's has yet.
(07:40:27 AM) moneromooo: Do you think the above is incorrect ?
(07:44:56 AM) linzhi-sonia: cjd: thanks a lot for the link! takes time to read and learn but that's great
(07:45:28 AM) linzhi-sonia: amazing conversation again. asicmakers mining at a loss to influence monero to become pro-asic! woah
(07:45:40 AM) linzhi-sonia: if that is possible, then many other things are also possible
(07:45:50 AM) stoffu: RandomX is already a failure when it requires dataset which needs to grow over time.
(07:46:39 AM) moneromooo: Ah, I have no arguments about that one, I did not look at it yet.
(07:46:50 AM) stoffu: It's Ethereum's way, and incidentally ArticMine and some others seem to consider it as a successful mode.
(07:46:53 AM) stoffu: *model.
(07:47:15 AM) cjd: growing dataset to mine or to validate ?
(07:47:20 AM) stoffu: Both
(07:47:40 AM) linzhi-sonia: the Ethash growth of ca. 50 MB / month has been quite stable for a few years
(07:47:42 AM) cjd: I understand ethereum escaped the issue of growing dataset to validate via their cache
(07:49:21 AM) stoffu: I really don't care anymore, there already exist two choices: Monero=RandomX vs Aeon=Keccak, reasonable and interesting way to diverge.
(07:49:54 AM) cjd: What is your ideal way forward ?
(07:51:01 AM) stoffu: SHA-3
(07:52:32 AM) cjd: And what are the most important requirements in your opinion (which lead you to think sha3 is the best solution)
(07:54:42 AM) stoffu: Low cost to verify, simple to easily create ASICs
(07:56:59 AM) cjd: ok, and can you explain objectives which lead to wanting it to be simple to create ASICs ?     sorry for the pedantic questions, I'm not trying to be patronizing, I just have not heard what I think are root objectives coming from either the SHA camp or the RandomX camp 
(07:57:21 AM) cjd: I suspect that the root objectives, once identified, are quite similar to both
(07:58:00 AM) stoffu: SHA3 will be a blessing for exchanges and merchants. Also for pools
(07:58:53 AM) moneromooo: They are similar. I don't think we disagree on anything except the weights we give all arguments.
(07:59:15 AM) cjd: Ease of validation is clearly a root objective, there's no need to ask why we want that
(07:59:25 AM) moneromooo: And those different weights bring us to those two incompatible paths.
(07:59:36 AM) stoffu: Yes, hence two different approaches: Monero and Aeon
(08:00:14 AM) stoffu: Both are legitimate ideas, though I support the latter
(08:00:39 AM) cjd: Maybe yes, maybe no, but at least if there was a bullet-list being proposed of the exact objectives (things which are obvious enough that there is no reason to ask why) and a ranking of importance, it might lead some people to change their minds
(08:00:39 AM) moneromooo: Another root objective is to maximize the minimum cost for a hash rate based attack on the network.
(08:00:49 AM) cjd: indeed
(08:00:53 AM) dEBRUYNE: sech1: "stoffu the cost to run full node is mainly disk space, not RAM" <= If disk space is the predominant cost than running an Ethereum node should still be fine
(08:01:04 AM) moneromooo: A larger objective is to maximize the minimum cost for an attack, but this is a subset looking only at PoW.
(08:01:10 AM) dEBRUYNE: The fact that no one can realistically run a node on his normal PC anymore tells us disk space is not the main cost
(08:01:20 AM) dEBRUYNE: Cost of running a node is mainly verification performance imo
(08:01:47 AM) cjd: moneromooo: that objective has a large fanout because you have to look at all of the easy attack models, but that is clearly the root
(08:02:58 AM) cjd: I suppose a third is a smooth adoption curve and forth is no secret unfair advantage for anyone
(08:03:07 AM) stoffu: I already said this is subjective, so I genuinely see no other way than
(08:03:19 AM) stoffu: Monero adopting RandomX
(08:04:20 AM) cjd: So RandomX is very cool for adoption curve, at least in principle, secret unfair advantage is something that requires code review
(08:04:41 AM) cjd: I think it's completely fair to insist that validation speed should increase and not decrease
(08:04:49 AM) cjd: and that validation memory must not increase over time
(08:05:18 AM) cjd: should increase and not decrease <-- with any change of PoW, including RandomX
(08:05:19 AM) moneromooo: I don't think "no secret unfair advantage for anyone" is a root objective.
(08:05:31 AM) moneromooo: Nor is "smooth adoption curve".
(08:05:57 AM) cjd: Because they're not that important to you or because they're just not valid objectives at all ?
(08:06:18 AM) moneromooo: They're not important to the network's health.
(08:06:42 AM) cjd: They are important to legitimacy
(08:06:45 AM) moneromooo: Well, only indirectly: "no secret unfair advantage for anyone" is derived from "maximize the min cost".
(08:07:08 AM) moneromooo: Maybe, but that's subjective.
(08:07:20 AM) moneromooo: You'll always have people who were there first.
(08:07:58 AM) moneromooo: Though things like constant emission are interesting. Like Grin.
(08:08:10 AM) moneromooo: Cryptonite also did mostly that. So much win in that coin.
(08:08:42 AM) cjd: Suppose I was creating RandomX and I had a secret trick which allowed me to mine 100x as fast as everyone else but if I mine too much I'll blow my cover so I will naturally keep my hashrate down... If anyone finds out that I did this they're going to be very angry at me and at the whole community for allowing it.
(08:09:10 AM) cjd: That can cause people to say "boohoo centralized" and jump ship to other projects
(08:10:03 AM) cjd: So while it's perhaps not as important as the chain being difficult to 51% attack, it is still something I would consider important to the longevity of the project
(08:10:52 AM) moneromooo: It is secondary, as a derived property:
(08:11:40 AM) moneromooo: If your assumnption is "I had a secret trick which allowed me to mine 100x as fast", then you can deduce "I'll probably get 50% of the hash rate", and from that "the attack cost will be 0 to me". So it implies the min cost to attack is minimized.
(08:11:58 AM) moneromooo: Therefore it is derived from the goal of maximizing the min cost to attack.
(08:12:11 AM) moneromooo: Therefore it's not a root goal.
(08:12:48 AM) moneromooo: It may seem pedantic, but it simplifies things.
(08:13:02 AM) cjd: You can imagine a central authority signing blocks, cost of attack is rather high because they're well protected and have lots of internal checks... but it will have an impact on community
(08:13:34 AM) cjd: JPMorganCoin for example, is very probably quite difficult to 51% attack
(08:14:23 AM) cjd: In any case, since in decentralized systems, cost of cheapest attack is almost always corrulated with "secret way to get rich", I will concur and accept it as a sub-objective
(08:14:27 AM) moneromooo: No. Cost of attack is 0 in that case.
(08:14:45 AM) moneromooo: If a central authority signs blocks, it can attack the network with 0 cost.
(08:16:15 AM) moneromooo: I do not have merge authority. Despite sometimes wishing I had because it takes too damn long to merge sometimes, I would have close to 0 cost to attack monero if I had.
(08:17:28 AM) moneromooo: Attacks can come from the entity that's notionally supposed to protect the network. Whether on purpose or not.
(08:17:38 AM) moneromooo: I (or JPMorgan) could turn evil, or get pwned.
(08:17:38 AM) cjd: So on the "difficult to attack" side, it is indeed attractive to require some kind of initial investment, such as that which asic makers do, because something which is purely CPU-hard is going to be the domain of botnet operators
(08:18:09 AM) moneromooo: That would require modelling I think. It's not immediately obvious.
(08:18:23 AM) cjd: Fair point
(08:19:01 AM) moneromooo: If you look at ASICs with this "maximize min cost to attack" in mind, you get:
(08:19:32 AM) moneromooo: - One (or very few) ASIC makers mean one is very likely to have 50% of the network -> 0 attack cost
(08:19:55 AM) cjd: 0 attack cost  <-- if they invested 0 R&D
(08:19:59 AM) moneromooo: - One (or very few) ASIC makers also mean great security against ASIC-less attackers
(08:20:26 AM) moneromooo: Not really. You can't count that, because it's already sunk.
(08:20:50 AM) moneromooo: Basically, ASICs increase security if they're not the attacker, decrease it if they are.
(08:21:29 AM) cjd: You can't count that, because it's already sunk   <-- already as of today ?
(08:21:41 AM) moneromooo: So the only way to not get the "decrease it if they are" part is to ensure there are many such makers. Which is what stoffu wants to do by using hte simplest possible PoW.
(08:22:22 AM) moneromooo: No, what I mean is in general: imagine ASIC maker A has made ASICs. That's in the past, and unchangeable by then. Then a few things can occur:
(08:23:33 AM) moneromooo: That company changes its mind and decides to attack (fairly easy, t's a company, they're predisposed to evil :P), it can be forced by its govt to backdoor things, or a hw backdoor can be placed at the fab without its knowledge.
(08:23:38 AM) cjd: IMO every dollar of R&D spend specifically on *monero* ASICs is a dollar which the ASIC maker needs to either earn back by mining/selling to a monero chain which containues to be trusted and hold value, OR it's part of the cost of the attack which they eventually carry out, thus destroying the value of the chain
(08:23:52 AM) moneromooo: Now, some of those things can also happen *without* ASICs, but less so since we have several miners.
(08:24:42 AM) moneromooo: Think about all htese companies that say "we get your info, we won't sell it, share it, etc". Then they get bought, and you're fucked.
(08:25:02 AM) moneromooo: Same thing here. A company might get bought by another which happens to have an interest in, say, Grin, and decides to attack monero.
(08:25:15 AM) moneromooo: I'm not saying it's likely, merely plausible.
(08:25:26 AM) cjd: Do you think they'll sell their ASIC IP for less than they spent to R&D it ?
(08:25:41 AM) moneromooo: Bankrupt companies don't sell for much.
(08:26:23 AM) moneromooo: And that's still only one of the ways. Pwned or forced by govt are still there.
(08:26:42 AM) cjd: I could also spend 10mn on CPUs and then go bankrupt and sell it to some guy who uses them to attack Monero, if you don't count that 10mn in the cost of the attack you're going to get weird conclusions
(08:26:46 AM) moneromooo: The point is that, regardless of motive, the possibility exists.
(08:27:12 AM) moneromooo: You can count it in some cases, but not in others. Depends what you want to try to defend against.
(08:27:31 AM) moneromooo: If you're trying to maximize the min cost to attack, counting it does not make sense.
(08:27:44 AM) moneromooo: Because of the "min" part.
(08:27:56 AM) moneromooo: You're trying to find the lowest hanging branch here.
(08:28:13 AM) cjd: Then you also won't count it if the NSA decides to use their supercomputer to 51% the crap out of Monero because it "wasn't busy that day"
(08:28:22 AM) cjd: that's 0 cost because it wasn't busy
(08:28:45 AM) moneromooo: Right.
(08:28:53 AM) moneromooo: If I understand your point/
(08:29:09 AM) cjd: Count the R&D, the analysis becomes more interesting
(08:29:13 AM) moneromooo: If you're saying "if the NSA has enough computing power to 51% monero, its attack cost is 0", then yes.
(08:29:53 AM) moneromooo: Well, it's electricity usage, but that's negligible and probably equivalent to CN ASICs.
(08:30:02 AM) cjd: I'm sure China can attack bitcoin for essentially no cost, they just have to go around to all of the miners and tell them "no policy"
(08:30:09 AM) cjd: *new policy
(08:30:37 AM) cjd: But that's not no cost, it's only no cost if you pretend all of the R&D and all of the cost those miners paid is onexistant
(08:30:40 AM) cjd: *nonexistant
(08:30:51 AM) moneromooo: You're just not getting it :)
(08:31:12 AM) moneromooo: It is a fair goal in itself, mind. Just not the one I'm describing.
(08:31:37 AM) moneromooo: You seem to be saying "maximize the economically worthwhile cost of an attack".
(08:31:55 AM) moneromooo: Which is a good one too. It's just not the goal I'm describing.
(08:32:52 AM) moneromooo: Your goal probably works most of the time too. But it's not enough.
(08:33:13 AM) moneromooo: It's enough against most attackers. Just not against the ones you're ignoring.
(08:33:27 AM) moneromooo: Am I making sense here ?
(08:34:15 AM) cjd: This argument in fact goes back to the origin of blockchains, it was well known that there is no way to solve Zookoo's Triangle in a cryptographically secure way, but Satoshi found a loophole which allowed it to be solved under the assumption that participants are economically rational
(08:35:21 AM) cjd: I claim that the difference between my objective and yours is that I'm allowing satoshi's relaxation of the requirements, because without that relaxation nothing in this space can work
(08:35:43 AM) moneromooo: Yes, I agree with your claim.
(08:35:57 AM) moneromooo: Well, except maybe the end.
(08:36:18 AM) moneromooo: It depends on what "work" means. Since it's maximization of a parameter, it's subjective.
(08:36:37 AM) moneromooo: How high is high enough ? :)
(08:37:08 AM) moneromooo: But OK, finding a compromise between maximizing those two costs is probably a better objective.
(08:37:53 AM) cjd: I would say that nomatter what design you come up with, there will always be a "silly/trivial" example such as the NSA supercomputer which was not busy, or the CPU magistrate who just went bankrupt and sold everything for a song, etc
(08:38:40 AM) cjd: What's the cost of stealing a truckload of ASICs ?
(08:39:16 AM) moneromooo: You're then purposefully ignoring attack vectors because they're inconvenient.
(08:39:47 AM) cjd: Yes and because I can get away with it, if I couldn't then there would be no blockchains at all
(08:40:15 AM) moneromooo: I claim this is reckless.
(08:40:36 AM) cjd: I understand Satoshi was told something similar
(08:40:48 AM) moneromooo: I claim this is appeal to authority.
(08:41:05 AM) sech1: stoffu "I don’t understand why so many people put so much trust on someone like sech1 who sounds very unprofessional. If the majority of the community trust him more than fluffypony/smooth, it’s not the same community I knew, and I no longer find it cool." <- you're joking right? We're here to create trustless decentralized currency and you start talking about trust
(08:41:09 AM) sech1: TRUST NO ONE
(08:41:33 AM) stoffu: You’ve been saying “trust me”
(08:42:13 AM) stoffu: Maybe not literally, but effectively
(08:42:28 AM) moneromooo: I mean, it's expedient and pragmatic to ignore those threats, but at some point if you start pushing too much value into it, those attack vectors will get exploited.
(08:42:29 AM) sech1: or maybe I wasn't saying it at all and you're imagining things?
(08:42:53 AM) sech1: ok, I can repeat one more time: trust no one
(08:42:58 AM) moneromooo: ("it" being the blockchain in question here)
(08:43:10 AM) cjd: 12:40 < moneromooo> I claim this is appeal to authority.   <-- I'm not 100% sure on this but I think it's different because what I'm appealing to is the known track record of bitcoin, not Satoshi's knowledge in some other domain
(08:43:29 AM) moneromooo: You could appeal to the known track record, but you did not :)
(08:43:59 AM) moneromooo: About the track record: wasn't there a backdoor in a large amount of bitmain miners at some point ?
(08:44:33 AM) moneromooo: I don't think it got exploited, but that's one of those inconvenient attack vectors right there.
(08:44:46 AM) cjd: Tesla was told that alternating current was no more useful than static electricity...  That's pointing out an error, not an appeal to Tesla (who ended up going insane and should not be treated as an authority on anything)
(08:45:11 AM) sech1: regarding verification time in RandomX: no one has actually tried to optimize it yet, it's very basic reference code
(08:45:20 AM) sech1: It won't be slower than current Cryptonight
(08:45:26 AM) moneromooo: If you have an argument, give the argument, rather than saying someone gave the argument to someone.
(08:45:28 AM) cjd: sech1: does memory requirement for verification grow over time ?
(08:46:03 AM) sech1: It's configuration parameter. 4 GB dataset growth and 256 MB "small" dataset growth are different things
(08:46:28 AM) cjd: ok so dataset to mine grows but dataset to verify stays static ?
(08:46:47 AM) cjd: moneromooo: so to get somewhat back on track, I see the value in ASICs not so much in making it easy to make them as making it hard, because ASIC makers become stakeholders in the monero project.
(08:47:19 AM) sech1: cjd right now verification dataset (256 MB) doesn't grow
(08:47:24 AM) sech1: https://github.com/tevador/RandomX/blob/dev/src/configuration.h[1]
(08:47:34 AM) cjd: ok so that answers one question
(08:47:40 AM) sech1: "#define RANDOMX_ARGON_GROWTH       0"
(08:48:15 AM) dEBRUYNE: The memory requirement grows though
(08:48:23 AM) sech1: for mining
(08:48:29 AM) dEBRUYNE: Which impacts verification time
(08:48:36 AM) sech1: No
(08:49:17 AM) sech1: It's still the same amount of memory accesses for verification
(08:49:33 AM) cjd: So basically the community needs to accept that verification memory goes from like 4MB to 256MB, but it will not grow over time, and the verification *time* should decrease by a little bit
(08:51:49 AM) cjd: Secondly, the community needs to accept that it will be easier to mine with a CPU than with anything else, which may carry risks because CPUs intended for other things can be repurposed (the same risk as using ProgPoW and being raided by ETH miners)...  But this is nothing new to Monero, it's already best mined on a CPU
(08:52:06 AM) cjd: Am I correct ?
(08:52:50 AM) dEBRUYNE: sech1: If the memory requirement eventually grows to 8 GB, does that not mean you basically need 8 GB of RAM to verify (unless slow verification mode is enabled)?
(08:53:06 AM) sech1: No, you need 256 MB to verify
(08:53:08 AM) dEBRUYNE: cjd: No, GPU miners have an advantage currently
(08:53:22 AM) dEBRUYNE: I am talking about verification speeds
(08:53:29 AM) dEBRUYNE: Not the minimum amount of RAM required
(08:53:35 AM) sech1: For fast verification - yes
(08:53:45 AM) sech1: But it'll take 8 years to grow to 8 GB
(08:53:55 AM) sech1: Do you thinkg 8 GB will be a problem in 2027?
(08:54:10 AM) cjd: Is "slow verification" faster or slower than current CN ?
(08:54:24 AM) sech1: right now it's slower
(08:54:24 AM) dEBRUYNE: Right, but a device with 4 GB will thus slowly need more time to perform verification, all else equal
(08:55:14 AM) cjd: Ok, IMO we should ignore fast verification as a distraction and consider all verification to be slow verification. It ought to be faster than CN because "things should get better and not worse"
(08:55:43 AM) moneromooo: (ceteris paribus)
(08:55:46 AM) sech1: We can easily make it faster than CN by tweaking algorithm parameters if that's the target
(08:56:05 AM) cjd: IMO for convincing the community to accept it, it should be
(08:56:18 AM) dEBRUYNE: moneromooo: :-P
(08:56:51 AM) cjd: Imagine I'm running an exchange, I have VM for monero and I want to know "how long to sync the chain, how much memory", if the answer to  "how much memory" is "well it depends", that's less good
(08:56:54 AM) sech1: I think we should get final version of RandomX first, with optimized verification code
(08:56:58 AM) moneromooo: I don't think it's pedantic. You usually can't have something that's better in all respects.
(08:57:04 AM) sech1: then tweak parameters to suit everyone's needs
(08:57:38 AM) cjd: +1
(08:58:27 AM) sech1: Right now we're discussing performance of constantly changing implementation and specification
(08:59:20 AM) cjd: Yeah, it's fine not to have all of the answers yet, but IMO what is important is to know how it will be measured
(09:02:35 AM) dEBRUYNE: Imo we should optimize for verification performance, even if that means somewhat weakening the algo
(09:03:25 AM) fort3hlulz [~setsimmo@2001:420:c0c4:1008::201] entered the room.
(09:03:46 AM) cjd: There's a tradeoff and at one extreme that is not at all contravercial
(09:05:56 AM) cjd: I personally have an additional objective which has nothing to do with Monero per se, I want better processors to begin to exist, so I would like to see a wide variety of program-like PoWs begin to exist which encourages development of processors like the Mill or the Rex Computing Neo, but I understand this is probably not anybody else's objective here
(09:06:21 AM) moneromooo: After thinking, I kinda agree that it is pragmatic to ignore non economical attack vectors which are deemed unlikely or too hard to counter. Like NSA using massive computing resources. Until we can do something about it.
(09:06:47 AM) moneromooo: But it's really because it's "nothing we can do right now", not because "it's not economical".
(09:07:53 AM) sech1: dEBRUYNE Different dataset generation algorithm can require even 0 additional memory for verification
(09:08:03 AM) sech1: Choosing Argon2D and 256 MB was pretty arbitrary
(09:08:13 AM) moneromooo: And with that example, you still can consider "what if it's google ? Or Pixar ? Or some decreasing amount of hash rate". You have to start considering it at some point.
(09:08:16 AM) sech1: it's a separate/independent part of RandomX
(09:08:41 AM) cjd: moneromooo: Then we are in agreement, believe me if I could find a hard cryptographic solution to this problem then I would implement it immediately (and dispatch with PoW entirely)
(09:14:49 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:44:26 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:52:26 AM) dEBRUYNE: sech1: I see, thanks for the information
(09:57:01 AM) sech1: Github discussion went off rails, I'm out of there
(09:58:55 AM) dEBRUYNE: We have the meeting on Sunday, that will probably be more productive
(09:59:20 AM) dEBRUYNE: Most has been said by now and currently it's basically a few people (which may be related) arguing for some insane tactics
(09:59:44 AM) moneromooo: Like what ?
(10:00:09 AM) hyc: I'm surprised we got over 400 comments with mostly actual arguments before it degenerated
(10:00:53 AM) needmoney90: If we just say we will fork when asics happen, they wont happen
(10:00:59 AM) needmoney90: Ez
(10:01:08 AM) hyc: ^^ game theory again?
(10:01:18 AM) needmoney90: Lol
(10:01:27 AM) needmoney90: I wasn't serious 
(10:01:43 AM) hyc: yeah, got that
(10:02:56 AM) hyc: feels like github is sending out emails out of order
(10:03:34 AM) moneromooo: Thinking against about the "NSA could swat monero" argument. It could probably swat the entire world banking system. It does not because it's not in its interests. We need to get NSA (and everyone else) to want monero ^_^
(10:04:09 AM) moneromooo: But technically, we storew billions in the banking system, and it's likely fragile against such adversaries.
(10:04:34 AM) moneromooo: Possibly billions of billions, too nany zeroes.
(10:05:04 AM) moneromooo: That looks like a possible attack point when war threatens.
(10:05:19 AM) hyc: the banking system runs on its own network, afaik
(10:05:25 AM) hyc: private lines, no public internet
(10:05:34 AM) moneromooo: The only way it can avoid this is by having advantageous to all parties.
(10:06:01 AM) moneromooo: I have a feeling that won't stop the NSA. They plug into plenty of places.
(10:06:53 AM) hyc: good point. I was thinking about arbitrary attackers
(10:08:12 AM) moneromooo: The point I was making is the difference between "amount of money in the banking system" vs "minimum amount of money required to fuck it up". Similar to the monero argument above.
(10:08:39 AM) moneromooo: It's probably very very cheap to destroy for *some* adversaries, compared to the amount of money in it.
(10:08:42 AM) hyc: it is certainly a fact that, whatever the best device for mining is, the big miners will buy it in bulk, at volume discounts that smaller players can't get.
(10:09:52 AM) hyc: but while SHA3 ASICs might be giving them 1000:1 advantage vs ordinary CPUs, RandmOX ASICs at 2-5x means regular miners aren't totally shut out
(10:10:21 AM) hyc: and instead of being the only ones in the world with mining-capable equipment, they're still competing against the hundreds of millions of already deployed CPUs in the world
(10:10:50 AM) hyc: On that basis, I believe adopting RandomX *and sticking with it* makes more sense than adopting any other ASIC algorithm
(10:11:57 AM) hyc: this is independent of whether SHA3-or-whatever ASICs ever become commoditized. The CPUs are already out there. That's a tremendous advantage for CPUs.
(10:12:23 AM) sech1: "adopting RandomX *and sticking with it*" Only if everything possible is done to reduce ASIC advantage
(10:12:39 AM) hyc: well, yes of course.
(10:12:42 AM) moneromooo: Your belief is about equivalent to stoffu's. It's based on estimating what's the likelihood of different future scenarii. And we can't really know :/
(10:12:54 AM) midipoet [uid316937@gateway/web/irccloud.com/x-aotjouagwsevqcjy] entered the room.
(10:13:09 AM) hyc: we know the number of deployed CPUs totally dwarfs the number of deployed ASICs of any kind
(10:13:17 AM) hyc: and that will remain true for decades, at least
(10:13:41 AM) moneromooo: Actually, thinking about it, if we can't know what scenario is more likely, then using the ease of verificaion as tie breaker seems sensible. Hmm.
(10:14:17 AM) sech1: hyc tevador we need to think how to change dataset generation
(10:14:33 AM) sech1: we need fast verification too and possibly reduce 256 MB requirement
(10:18:10 AM) hyc: reduce how much? I think 2MB would be too small; that was ok for 5 years ago, but tech has advanced.
(10:22:48 AM) sech1: I'm talking about changing dataset generation algorithm to something else
(10:23:33 AM) sech1: Why don't we just make it entirely compute bound? Something like dataset block N = AES repeated 100 times on "N ^ seed"
(10:23:56 AM) sech1: it'll be faster to read from DRAM than calculate 100 consecutive AES, even on ASIC
(10:24:38 AM) sech1: and verification won't require additional memory, it'll just be slower than mining, but still < 10 ms
(10:27:53 AM) sech1: and I'm not even talking power needed to do 100 AES calculations, it will be much higher than reading from DRAM
(10:29:02 AM) hyc: indeed
(10:47:21 AM) dEBRUYNE: <hyc> On that basis, I believe adopting RandomX *and sticking with it* makes more sense than adopting any other ASIC algorithm <= What if the advantage they gain is sufficiently large to drive out all other miners?
(10:47:31 AM) dEBRUYNE: Then you'd want to have a more asic friendly algorithm no?
(10:48:21 AM) hyc: I'm skeptical
(10:48:41 AM) dEBRUYNE: Of them gaining a sufficiently large advantage to drive other miners out I presume?
(10:48:49 AM) hyc: that, yes
(10:49:07 AM) hyc: but in terms of overall decentralization, there's still nothing on earth more decentralized than all of the already deployed CPUs
(10:49:30 AM) hyc: every ASIC-based solution will be inferior for decentralization.
(10:49:49 AM) dEBRUYNE: I agree as long as asics cannot reach a large efficiency advantage
(10:50:02 AM) dEBRUYNE: The argument becomes moot if you have an asic that is ten times more efficient
(10:50:39 AM) moneromooo: If randomx cannot keep ASICs at bay, I agree that a simple hash is better.
(10:50:59 AM) moneromooo: But then my agreement probably isn't worth much, I don't know a lot about hw.
(10:52:43 AM) hyc: it just strikes me as bad to say "well, we got beaten by 50%, so let's throw in the towel and use a 10000% ASIC"
(10:53:28 AM) dEBRUYNE: hyc: I don't think any classifies 50% as failure
(10:54:23 AM) hyc: ok. so again the argument is one of degrees.
(10:55:19 AM) dEBRUYNE: Right
(10:55:28 AM) sech1: When the argument "doesn't become moot"? 9x, 8x, 7x, 6x, 5x, 4x, 3x or 2x?
(10:55:30 AM) dEBRUYNE: Though I think we previously agreed that x5-x10 advantage would be classified as failure
(10:55:51 AM) dEBRUYNE: sech1: The argument becomes moot if asics drive out almos tall other miners
(10:56:01 AM) dEBRUYNE: At which efficiency advantage point that is, only practice can tell
(10:57:19 AM) hyc: ETH is still mostly GPU mined, but they seem unhappy, otherwise they wouldn't have bothered with ProgPow
(10:57:33 AM) moneromooo: hyc: it's only bad if you have a fair chance at another try.
(11:00:13 AM) hyc: I guess I'll just have to wait and see what happens. can't judge my perspective of then from here and now
(11:00:17 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:01:49 AM) dEBRUYNE: hyc: Do you agree though that we should have a backup plan set in advance in case RandomX fails?
(11:03:16 AM) hyc: yeah, that's just prudent
(12:10:51 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(12:20:58 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:29:07 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 255 seconds).
(12:38:36 PM) kopite7 left the room (quit: Quit: Leaving.).
(12:43:06 PM) linzhi-sonia: hyc: "there's nothing on earth more decentralized than already deployed CPUs". we've learnt something else: cost advantage drives centralization. if I can get that same CPU at half the cost, that's like a 2x performance asic. and since cpus (or gpus) are very expensive chips that simultaneously target many use cases, you will quickly have a situation where a cpu or gpu maker has a few million of 
(12:43:12 PM) linzhi-sonia: them they don't want to sell on the open market, and will give to a crypto partner at rock bottom price for revenue sharing.
(01:01:13 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:01:16 PM) hyc: I find that hard to believe. E.g. AMD already has thousands or millions of EPYC2 pre-sold already, to supercomputer installations around the world
(01:01:35 PM) hyc: they're not going to suddenly divert some new chips to a cryptominer
(01:42:12 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:52:45 PM) midipoet: linzhi-sonia: that halved capital outlay for the CPU is not equal to a 2x performance gain, due mainly to the cost being amortised over the lifetime of the chip. 
(01:53:06 PM) midipoet: That's basic cost accounting. 
(01:55:28 PM) kopite7 [~kmaneshni@32.97.110.50] entered the room.
(02:26:40 PM) spaced0ut left the room (quit: Ping timeout: 268 seconds).
(02:33:33 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:37:07 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:38:42 PM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(02:48:59 PM) tevador: sech1: the memory parameters are not arbitrary, you have to satisfy RANDOMX_DATASET_SIZE <= RANDOMX_ARGON_MEMORY * RANDOMX_CACHE_ACCESSES * 1024 otherwise tradeoffs are efficient
(02:49:30 PM) tevador: Argon2d was chosen because it's tradeoff resistant and peer reviewed
(02:50:34 PM) tevador: compute-bound dataset initialization is not ASIC resistant, I tried this before, but the math simply fails
(02:51:52 PM) tevador: see this: https://github.com/altASIC/Open-CryptoNight-ASIC/issues/2[1]
(02:52:09 PM) tevador: <10 uJ to encrypt 1 GB with AES in ASIC
(02:57:25 PM) cjd: Interesting question IMO is what is the fastest memory hard function possible within a given bound for time/memory tradeoff
(02:59:18 PM) tevador: if want to make verification requirements as low as possible (even at the cost of reduced ASIC resistance), we could go for 1 GiB dataset, 64 MiB cache and 8 accesses per Dataset block
(03:00:35 PM) tevador: this would make verification time (with JIT) slightly faster than CN
(03:01:03 PM) tevador: with 66 MiB required to verify a hash
(03:05:40 PM) cjd: That might be more effective for selling the idea to the community
(03:11:44 PM) hyc: reducing ASIC resistance ... by how much? 
(04:04:08 PM) kopite7 left the room (quit: Ping timeout: 246 seconds).
(04:08:52 PM) tevador: memory hardness would be reduced and ASICs would be cheaper to make
(04:10:19 PM) dEBRUYNE: Seems like a worthwhile point to discuss in the meeting
(04:15:13 PM) kopite7 [~kmaneshni@32.97.110.50] entered the room.
(04:20:15 PM) dEBRUYNE left the room ("Leaving").
(04:27:33 PM) wowario left the room (quit: Remote host closed the connection).
(04:31:16 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(04:53:11 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(05:35:50 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:51:30 PM) tevador: sech1: since we are doing branches, we could add some that require an actual branch predictor, even the simplest one
(06:52:20 PM) tevador: patterns like 00110011 and 00010001 should be 100% predictable for any CPU
(06:53:32 PM) tevador: these can be done easily with test ebx, 2 and test ebx, 3
(06:53:54 PM) sech1: ebx goes through fixed pattern?
(06:54:01 PM) tevador: it's the loop counter
(06:54:08 PM) tevador: counts from 2048 to zero
(06:55:04 PM) tevador: since our random branches technically don't use the branch predictor at all
(06:55:22 PM) tevador: only the rollback logic of the speculative CPU
(07:00:58 PM) sech1: two different types of branches is harder to support for sure
(07:01:26 PM) sech1: it still won't need an actual branch predictor
(07:03:17 PM) tevador: yes since it's a fixed register, but whatever if it's free for CPUs
(07:14:11 PM) sech1 left the room (quit: Quit: Leaving).
(07:29:02 PM) kopite7 left the room (quit: Quit: Leaving.).
(07:54:29 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(08:28:02 PM) parasew[m] left the room (quit: Remote host closed the connection).
(08:35:32 PM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-pcqizptthebspvuw] entered the room.
(09:38:40 PM) vtnerd_ [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(09:39:12 PM) vtnerd left the room (quit: Ping timeout: 245 seconds).
(09:42:21 PM) kico left the room (quit: Quit: Leaving).
(09:55:48 PM) kico [~kico@unaffiliated/kico] entered the room.
(09:56:53 PM) kico left the room (quit: Remote host closed the connection).
(10:02:13 PM) fort3hlulz_ [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(10:11:00 PM) kico [~kico@unaffiliated/kico] entered the room.
(10:12:30 PM) kico left the room (quit: Remote host closed the connection).
(10:45:29 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:54:00 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(11:12:42 PM) kopite7 left the room (quit: Quit: Leaving.).
(11:42:26 PM) wowario_ [~wowario@gateway/tor-sasl/wowario] entered the room.
(11:43:47 PM) wowario left the room (quit: Ping timeout: 256 seconds).
(11:52:09 PM) fort3hlulz_ left the room (quit: Ping timeout: 268 seconds).
(12:15:58 AM) investanto left the room (quit: Quit: Changing servers).
(12:16:09 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:17:58 AM) LSDog left the room (quit: Ping timeout: 245 seconds).
(01:24:29 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(01:31:13 AM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(01:42:12 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:03:42 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:26:31 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:42:51 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(03:35:46 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(03:36:33 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(03:42:03 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:45:17 AM) sech1 left the room (quit: Quit: Leaving).
(04:05:55 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:08:09 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:31:59 AM) midipoet [uid316937@gateway/web/irccloud.com/x-nvucqagafodhmpwr] entered the room.
(06:13:39 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:15:53 AM) LSDog left the room (quit: Ping timeout: 245 seconds).
(06:20:37 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:42:06 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(07:07:28 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(07:11:47 AM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(07:13:24 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(07:16:29 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(07:18:49 AM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(07:19:20 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(07:22:40 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 255 seconds).
(07:23:42 AM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(07:24:09 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(07:25:24 AM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(07:29:13 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(07:29:38 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(07:55:13 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(07:58:41 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(08:02:24 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(08:04:15 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(08:06:06 AM) el00ruobuob left the room (quit: Ping timeout: 244 seconds).
(08:10:40 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(08:13:59 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(08:15:03 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(08:24:50 AM) spaced0ut left the room (quit: Ping timeout: 246 seconds).
(08:54:46 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(08:58:46 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:04:59 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(09:08:06 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(09:12:59 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:25:03 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(10:21:23 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(10:35:14 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(10:39:50 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(10:50:29 AM) kico left the room (quit: Remote host closed the connection).
(10:50:53 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:59:26 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:42:00 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(11:45:26 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(11:57:51 AM) sech1 left the room (quit: Quit: Leaving).
(12:10:06 PM) fort3hlulz left the room (quit: Ping timeout: 252 seconds).
(12:10:31 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(12:16:44 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:17:08 PM) vtnerd_ left the room (quit: Ping timeout: 245 seconds).
(12:27:06 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(12:28:13 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:29:25 PM) el00ruobuob left the room (quit: Ping timeout: 268 seconds).
(12:36:32 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(12:39:54 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(12:41:41 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(12:44:50 PM) el00ruobuob left the room (quit: Ping timeout: 268 seconds).
(12:44:57 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(12:46:16 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1007::280] entered the room.
(12:46:26 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(12:49:45 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(12:49:49 PM) fort3hlulz left the room (quit: Ping timeout: 255 seconds).
(12:50:21 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(12:52:20 PM) el00ruobuob left the room (quit: Ping timeout: 244 seconds).
(12:59:56 PM) LSDog left the room (quit: Ping timeout: 246 seconds).
(01:14:01 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(01:27:27 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:28:53 PM) fort3hlulz_ left the room (quit: Quit: Leaving).
(02:29:17 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1007::280] entered the room.
(03:52:07 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(03:52:17 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(03:57:20 PM) jwinterm left the room (quit: Quit: No Ping reply in 180 seconds.).
(04:01:41 PM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(04:11:52 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:25:31 PM) dEBRUYNE left the room ("Leaving").
(04:26:45 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1004::360] entered the room.
(04:30:38 PM) fort3hlulz left the room (quit: Ping timeout: 272 seconds).
(04:49:48 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(04:50:00 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:04:30 PM) el00ruobuob_[m] left the room (quit: Remote host closed the connection).
(05:05:19 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-132-98.adsl.proxad.net] entered the room.
(05:52:31 PM) fort3hlulz_ left the room (quit: Ping timeout: 250 seconds).
(06:44:00 PM) sech1 left the room (quit: Quit: Leaving).
(08:21:24 PM) vp11 left the room (quit: Quit: nossa vitória não será por acidente).
(09:44:52 PM) needmoney90: https://steemit.com/mining/@felixxx/gpu-mining-equihash-undervolt-is-where-it-s-at[1]
(09:45:13 PM) needmoney90: Talking in another chat about undervolting GPUs to stay competitive with CPUs once RandomX drops
(09:45:21 PM) needmoney90: Found that article from a couple years back 
(09:45:43 PM) needmoney90: Is this still the case? Power consumption can be dropped dramatically with non-linear decreases in hashrate? 
(09:45:59 PM) needmoney90: And would it be plausible with randomX still? 
(09:49:12 PM) needmoney90: And how long does that non-linear relation hold? 
(09:59:44 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:23:47 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(10:45:52 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(10:55:04 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:28:36 AM) kopite7 left the room (quit: Quit: Leaving.).
(12:53:14 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:07:03 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:30:33 AM) spaced0ut left the room (quit: Ping timeout: 268 seconds).
(03:18:47 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(03:56:01 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:56:31 AM) sech1 left the room (quit: Quit: Leaving).
(04:06:22 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:25:02 AM) ferretinjapan left the room (quit: Ping timeout: 272 seconds).
(04:32:39 AM) midipoet [uid316937@gateway/web/irccloud.com/x-ilozbaxwahjneihx] entered the room.
(04:36:08 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:21:25 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(05:21:37 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:26:12 AM) el00ruobuob_[m] [~el00ruobu@195.68.27.41] entered the room.
(05:49:46 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(05:49:54 AM) sech1: tevador any news from Tim Olson? Did he finish his RandomX review?
(07:23:29 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(08:21:51 AM) el00ruobuob_[m] [~el00ruobu@195.68.27.41] entered the room.
(08:39:37 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(08:40:53 AM) OsrsNeedsF2P left the room (quit: Ping timeout: 245 seconds).
(08:45:25 AM) fort3hlulz left the room (quit: Quit: Leaving).
(08:47:59 AM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(08:59:46 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:30:10 AM) investanto left the room (quit: Quit: Changing servers).
(09:30:22 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:39:22 AM) hyc: undervolting has no effect on a GPU's hashrate. underclocking would have an effect.
(09:39:35 AM) hyc: both would typically be done together
(09:39:46 AM) hyc: but you can undervolt a chip without touching the clock rate.
(09:46:40 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(09:57:01 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:03:05 AM) crCr62U0 left the room (quit: Quit: leaving).
(10:06:15 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(10:21:31 AM) cjd: undervolting because you don't care if it crashes every now and then ?
(10:25:49 AM) OsrsNeedsF2P left the room (quit: Ping timeout: 255 seconds).
(10:28:54 AM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(10:28:55 AM) hyc: you presumably try to dial it in so it doesn't crash. but mining is all about power efficiency, so you undervolt as much as you can
(10:41:26 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(10:44:21 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(10:48:12 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(10:48:41 AM) cjd: I see, absorbing the margin of error which GPU makers build in
(11:00:01 AM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(11:00:19 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:43:09 AM) sech1 left the room (quit: Quit: Leaving).
(11:43:55 AM) wowario_ left the room (quit: Ping timeout: 256 seconds).
(11:45:41 AM) wowario_ [~wowario@gateway/tor-sasl/wowario] entered the room.
(11:47:22 AM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(11:54:29 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:07:31 PM) fort3hlulz left the room (quit: Remote host closed the connection).
(12:07:52 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(12:45:43 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(01:34:24 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(01:50:17 PM) hyc: Samsung HBM2e https://www.reddit.com/r/Amd/comments/b3egm5/samsung_hbm2e_flashbolt_memory_for_gpus_16_gb_per/
(02:27:51 PM) vp11 [curumim@gateway/shell/elitebnc/x-ysavuwdbqcfbbaip] entered the room.
(02:31:32 PM) Isthmus left the room (quit: Ping timeout: 252 seconds).
(02:31:41 PM) midipoet_ [uid316937@gateway/web/irccloud.com/x-fsmdhlifeyugupsr] entered the room.
(02:31:50 PM) rodolfo912_ [sid307427@gateway/web/irccloud.com/x-nilaownehlhqijsw] entered the room.
(02:31:54 PM) midipoet left the room (quit: Ping timeout: 252 seconds).
(02:31:54 PM) xmrdc left the room (quit: Ping timeout: 252 seconds).
(02:31:55 PM) midipoet_ is now known as midipoet
(02:31:56 PM) Isthmus_ [sid302307@gateway/web/irccloud.com/x-xxahormpzuucsbpl] entered the room.
(02:32:16 PM) luigi1111 left the room (quit: Ping timeout: 252 seconds).
(02:32:16 PM) johnhmay left the room (quit: Ping timeout: 252 seconds).
(02:32:17 PM) rodolfo912 left the room (quit: Ping timeout: 252 seconds).
(02:34:56 PM) johnhmay [sid110431@gateway/web/irccloud.com/x-aawdjonsenrmtywh] entered the room.
(02:34:58 PM) xmrdc [sid218083@gateway/web/irccloud.com/x-bqdejrdwdhrsxepz] entered the room.
(02:41:18 PM) luigi1111 [sid85934@gateway/web/irccloud.com/x-vrcmstabhaqvrepp] entered the room.
(02:49:34 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(02:52:40 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(03:11:13 PM) tevador: sech1: still no response from Tim
(03:11:25 PM) sech1: We need it before Sunday
(03:11:56 PM) sech1: I mean we can go without it, but he can come up with some nice ideas for further improvements
(03:14:40 PM) tevador: yes, he said 'early this week'
(03:21:43 PM) tevador: I'd like to implement JIT verification before Sunday, so we have the numbers
(03:22:32 PM) tevador: after the branching change, interpreter got 30% slower, so now it's needed more than ever
(04:11:29 PM) kico left the room (quit: Remote host closed the connection).
(04:11:51 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(04:17:54 PM) fort3hlulz left the room (quit: Ping timeout: 264 seconds).
(04:18:19 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(04:20:38 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(04:26:07 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(04:37:20 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(07:34:16 PM) sech1 left the room (quit: Quit: Leaving).
(08:19:13 PM) investanto left the room (quit: Quit: Changing servers).
(08:19:26 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(08:42:20 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(08:44:10 PM) LSDog left the room (quit: Ping timeout: 272 seconds).
(08:56:34 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(09:51:25 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(10:25:52 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(02:48:23 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:49:56 AM) dEBRUYNE left the room ("Leaving").
(03:10:53 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(03:12:56 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:23:35 AM) sech1 left the room (quit: Quit: Leaving).
(03:24:47 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:33:26 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:41:35 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(03:53:30 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:58:55 AM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(03:59:14 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(04:13:44 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(04:36:23 AM) midipoet [uid316937@gateway/web/irccloud.com/x-wrdcibjwnxxtquwq] entered the room.
(04:59:36 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(05:01:38 AM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(05:03:13 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(05:08:57 AM) crCr62U0 left the room (quit: Quit: leaving).
(05:13:53 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:39:47 AM) dossier left the room (quit: Ping timeout: 268 seconds).
(06:12:09 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(08:28:47 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(08:30:43 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(08:42:24 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(10:25:49 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(10:35:39 AM) el00ruobuob_[m] left the room (quit: Read error: Connection reset by peer).
(10:36:08 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(10:58:07 AM) kinghat left the room (quit: Quit: The Lounge - https://thelounge.chat).
(10:58:36 AM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(11:04:40 AM) kinghat_ [uid86015@gateway/web/irccloud.com/x-knkjdvptdkfrhjzs] entered the room.
(11:06:04 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:09:14 AM) kinghat_ left the room (quit: Client Quit).
(11:27:26 AM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(11:28:37 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(12:05:08 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(12:10:57 PM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(12:13:12 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(12:13:29 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(12:15:34 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:17:21 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(12:58:22 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(12:59:49 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:09:12 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(01:10:46 PM) el00ruobuob left the room (quit: Ping timeout: 252 seconds).
(01:25:36 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:44:37 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(01:45:04 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:47:31 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(03:06:28 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(03:08:38 PM) el00ruobuob left the room (quit: Ping timeout: 244 seconds).
(03:25:50 PM) gethh [uid264798@gateway/web/irccloud.com/x-mpslrztpnrmyrowr] entered the room.
(03:36:43 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(03:49:13 PM) tevador: I think I have found parameters that may be acceptable: 18.5 ms RandomX light verification, 17.2 ms CNv2 on the same computer
(03:49:37 PM) tevador: with JIT
(03:50:28 PM) dEBRUYNE: CNv2 does not differ that much from original CN with respect to verificaiton right?
(03:50:34 PM) dEBRUYNE: As it does not include random code generation yet
(04:02:33 PM) tevador: tested on another laptop: CN/R (xmrig) max. 13.8 ms per hash, RandomX: 10.6 ms per hash
(04:02:40 PM) tevador: here RandomX is even faster
(04:03:11 PM) tevador: the 13.8 ms was calculated from the max hashrate, so it's probably optimistic
(04:03:40 PM) dEBRUYNE: tevador: Did you lower the memory requirement to obtain these statistics?
(04:03:44 PM) dEBRUYNE: Or what parameters did you change
(04:04:03 PM) tevador: yes, Dataset size decreased to 2 GiB, cache still 256 MiB
(04:04:32 PM) dEBRUYNE: Sounds reasonable, especially given those verification numbers
(04:04:35 PM) tevador: this allows the light verification to use just 2048/256 = 8 accesses per item
(04:04:48 PM) tevador: instead of 16
(04:05:14 PM) tevador: I think this is a good compromise
(04:05:37 PM) dEBRUYNE: Yeah
(04:05:47 PM) dEBRUYNE: Would be nice if some people could independently verify the performance numbers
(04:06:12 PM) tevador: I will try to push the code tomorrow
(04:06:24 PM) tevador: at the moment I have just the Windows version
(04:06:29 PM) tevador: of JIT compiler
(04:07:19 PM) tevador: also I have to merge the new branching tweak
(04:07:46 PM) tevador: we will have more performance numbers before the meeting, but it looks promising to me
(04:08:07 PM) dEBRUYNE: Ok cool, hopefully some review by tim olsen as well
(04:08:24 PM) dEBRUYNE: With those verification numbers, I think a lot of concerns will be mitigated
(04:08:39 PM) tevador: so the only 'controversial' thing is the 256 MB requires for verification, but I don't recommend to decrease it
(04:08:46 PM) tevador: required*
(04:09:29 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(04:09:30 PM) dEBRUYNE: The '' are well placed there :-P
(04:09:37 PM) dEBRUYNE: I wouldn't consider that particularly controversial
(04:10:09 PM) tevador: me neither, even phones have 2 GB nowadays
(04:10:38 PM) tevador: but some people complained in the github discussion about it
(04:13:16 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(04:14:30 PM) dEBRUYNE: Think it was mostly due to the significant increase of verification time
(04:14:32 PM) sech1: 256 MB is just ridicilously low today IMHO
(04:14:40 PM) dEBRUYNE: RAM itself is not really a problem
(04:14:42 PM) sech1: we're creating algo for the future, not for the past
(04:15:21 PM) sech1: But verification time comparable to CNv2 is very good
(04:15:33 PM) kicoo [~kico@gateway/tor-sasl/kico] entered the room.
(04:16:02 PM) dEBRUYNE: Yep agree
(04:16:35 PM) dEBRUYNE: I wonder if a capable GPU miner dev can bring the CPU:GPU gap to 1:1
(04:16:40 PM) dEBRUYNE: Doesn't sound particularly infeasible
(04:18:05 PM) kico left the room (quit: Ping timeout: 256 seconds).
(04:20:18 PM) tevador: sech1: any ideas how the branching will affect your GPU algorithm?
(04:20:58 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:21:46 PM) sech1: Probably it will make it 25-30% slower because different programs will have different number of instructions
(04:21:51 PM) sech1: so there will be divergence
(04:22:22 PM) sech1: branches themselves won't affect it because this GPU algorithm is basically interpreter
(04:22:31 PM) tevador: right
(04:23:01 PM) tevador: the number of additional instructions is quite low
(04:23:23 PM) tevador: about 30000 out of 4M
(04:23:39 PM) sech1: then it will be 1% slowdown
(04:23:54 PM) tevador: so about the same as CPUs
(04:24:03 PM) tevador: so no difference
(04:25:56 PM) tevador: also we will probably have to abandon the growing dataset... but I'm planning to use a fixed 2 GiB + 64 MiB size so ASIC has to use a base pointer per program like a CPU
(04:39:32 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(04:46:07 PM) sech1: 2 GB + 64 MB also makes it very inconvenient for ASICs (not power of 2), they'll have to use more memory chips
(04:49:12 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:56:03 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:01:04 PM) dEBRUYNE left the room ("Leaving").
(05:41:22 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:18:52 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(06:22:30 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 272 seconds).
(06:46:13 PM) gingeropolous: y abandon the growing dataset?
(06:50:23 PM) tevador: a lot of people opposed the idea and it has negative impact on performance
(06:54:32 PM) gingeropolous: on that github thread? I tuned out after monerocrusher went on his tirade
(06:56:35 PM) gingeropolous: keeping it static just means we'll have this discussion again in n years
(07:00:17 PM) tevador: some people didn't like the idea of increasing verification memory requirements
(07:00:47 PM) tevador: yes, the github discussion, but it's buried deep in there somewhere
(07:05:04 PM) gingeropolous: but surely computers get better over time, right? hell a phone could come standard with 64 GB ram in 5 years
(07:13:51 PM) luigi1111: probably 10
(07:17:17 PM) hyc: Well.... assuming we're still using some version of randomX in a couple years, we can basically assume that CPUs and ASICs will both improve at about the same rate
(07:17:37 PM) hyc: since they're still constrained by the same fabrication technology limits
(07:18:33 PM) hyc: if the ASICs start using more high speed RAM than CPUs typically include on-chip though, we probably still need to revisit this
(07:19:48 PM) hyc: the only thing I dislike about the whole march of progress is, if we don't change anything else, our hash rates and difficulty numbers will keep getting larger, which is just mental clutter
(07:52:25 PM) sech1 left the room (quit: Quit: Leaving).
(08:00:03 PM) midipoet: It's definitely not an efficient march, that's for sure. 
(08:00:16 PM) kicoo is now known as kico
(09:32:41 PM) investanto left the room (quit: Quit: Changing servers).
(09:32:56 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:37:30 PM) ferretinjapan left the room (quit: Ping timeout: 252 seconds).
(10:56:06 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:34:09 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:50:42 PM) spaced0ut left the room (quit: Ping timeout: 252 seconds).
(12:23:58 AM) investanto left the room (quit: Quit: Changing servers).
(12:24:16 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(12:31:54 AM) sgp_ left the room (quit: Ping timeout: 268 seconds).
(12:32:25 AM) kensheng left the room (quit: Ping timeout: 250 seconds).
(12:32:31 AM) endogenic left the room (quit: Ping timeout: 268 seconds).
(12:33:07 AM) luigi1111 left the room (quit: Ping timeout: 240 seconds).
(12:33:08 AM) infinitejest_ left the room (quit: Ping timeout: 268 seconds).
(12:33:43 AM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(12:33:45 AM) OhGodAGirl left the room (quit: Ping timeout: 268 seconds).
(12:33:46 AM) infinitejest_ [sid203393@gateway/web/irccloud.com/x-xqcllpujtrtxetao] entered the room.
(12:33:55 AM) OhGodAGirl_ [sid164689@gateway/web/irccloud.com/x-duqgbhaauwfarbhl] entered the room.
(12:33:56 AM) luigi1111 [sid85934@gateway/web/irccloud.com/x-bytpnxmifvyrbcfy] entered the room.
(12:37:18 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:39:15 AM) sgp_ [sid329439@gateway/web/irccloud.com/x-epjtwacitjcbzoku] entered the room.
(12:39:43 AM) kensheng [uid346884@gateway/web/irccloud.com/x-umramstjefmmwmir] entered the room.
(12:39:45 AM) endogenic [sid145991@gateway/web/irccloud.com/x-ozrdibtwnzvynlra] entered the room.
(01:48:22 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(02:01:57 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:29:24 AM) sech1 left the room (quit: Read error: Connection reset by peer).
(02:30:07 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:48:36 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:08:14 AM) investanto left the room (quit: Quit: Changing servers).
(03:08:26 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(03:53:40 AM) sech1 left the room (quit: Quit: Leaving).
(04:05:18 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(06:36:50 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:59:14 AM) sgp_ left the room (quit: Ping timeout: 252 seconds).
(06:59:40 AM) sgp_ [sid329439@gateway/web/irccloud.com/x-wonyafmyugqdsbiy] entered the room.
(07:00:20 AM) infinitejest_ left the room (quit: Ping timeout: 252 seconds).
(07:00:54 AM) infinitejest_ [sid203393@gateway/web/irccloud.com/x-ulaohltczoxiasll] entered the room.
(07:29:33 AM) midipoet [uid316937@gateway/web/irccloud.com/x-gtofzlzahlkmddgk] entered the room.
(08:00:04 AM) tevador: testing CN/R on Raspberry Pi 3: 1.0 H/s
(08:00:56 AM) tevador: RandomX about 2.2 H/s
(08:06:39 AM) stoffu_ [sid260213@gateway/web/irccloud.com/x-fspzsjjymylblngd] entered the room.
(08:07:11 AM) selsta_ [sid124829@gateway/web/irccloud.com/x-tdfuogueutihkoqb] entered the room.
(08:07:15 AM) scoobybejesus_ [sid271506@gateway/web/irccloud.com/x-mtcaezwewmcvxvtw] entered the room.
(08:14:36 AM) scoobybejesus left the room (quit: *.net *.split).
(08:14:37 AM) stoffu left the room (quit: *.net *.split).
(08:14:37 AM) selsta left the room (quit: *.net *.split).
(08:14:38 AM) scoobybejesus_ is now known as scoobybejesus
(08:14:39 AM) stoffu_ is now known as stoffu
(08:14:39 AM) selsta_ is now known as selsta
(08:48:03 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:54:49 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(09:06:36 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:58:09 AM) tevador: correction: 3.25 H/s per core on Raspberry
(09:58:25 AM) tevador: (RandomX)
(10:06:02 AM) kico left the room (quit: Remote host closed the connection).
(10:06:19 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:23:54 AM) spaced0ut left the room (quit: Ping timeout: 244 seconds).
(10:24:06 AM) sech1: so we should compare RandomX verification speed vs xmrig? Or mining in monerod with JIT?
(10:28:22 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(10:42:01 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(10:45:42 AM) tevador: I will post my results shortly
(10:53:53 AM) tevador: https://github.com/monero-project/meta/issues/316#issuecomment-475651654[1]
(11:01:08 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:03:27 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(11:05:41 AM) dEBRUYNE: tevador: If possible, could you perhaps also add a column with CN original or CNv2 figures?
(11:07:47 AM) sech1: It makes more sense to compare with monerod
(11:07:52 AM) sech1: it's slower than xmrig
(11:08:21 AM) sech1: and it's monerod code which is used for chain synchronization
(11:11:16 AM) sech1: So if RandomX verification is faster than xmrig then it'll be even more faster compared to actual CN/R verification code in monerod
(11:19:17 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:21:08 AM) dEBRUYNE: sech1: Was that referring to my comment?
(11:21:24 AM) sech1: no, to github comment
(11:21:40 AM) dEBRUYNE: Oh
(11:21:56 AM) dEBRUYNE: tevador: One more question, when you ran those tests, was JIT enabled for CN/R?
(11:22:05 AM) sech1: if it was xmrig then yes
(11:22:20 AM) sech1: everywhere except Raspberry Pi
(11:22:21 AM) dEBRUYNE: Ah I overread
(11:22:24 AM) dEBRUYNE: "For CN/R, I used xmrig version 2.14.1: https://github.com/xmrig/xmrig[1]
(11:22:24 AM) dEBRUYNE: "
(11:22:28 AM) dEBRUYNE: Didn't see that at first
(11:22:33 AM) dEBRUYNE: Thanks for clarifying
(11:23:00 AM) dEBRUYNE: Anyway, numbers look good imo
(11:25:51 AM) sech1: tevador still nothing from Tim Olson?
(11:29:57 AM) tevador: no word from Tim Olson
(11:30:15 AM) tevador: how can I test CNv0 and CNv2 with xmrig?
(11:30:39 AM) tevador: does it have some benchmark mode?
(11:32:39 AM) sech1: No benchmark mode
(11:32:51 AM) sech1: you could set "variant": 0 in config.json and point it to some ETN pool
(11:32:54 AM) sech1: ETN uses CNv0
(11:36:41 AM) midipoet [uid316937@gateway/web/irccloud.com/x-fcqkswuhpellopbh] entered the room.
(11:38:36 AM) fort3hlulz left the room (quit: Ping timeout: 252 seconds).
(11:44:10 AM) tevador: so, Raspberry pull 3.1 H/s in CNv0
(11:44:27 AM) tevador: 1 thread
(11:45:31 AM) tevador: I guess I could test also CNv2 there, no hope to submit an invalid share with 250000 difficulty...
(11:58:32 AM) dossier [49e955be@gateway/web/cgi-irc/kiwiirc.com/ip.73.233.85.190] entered the room.
(12:19:26 PM) sech1: So RandomX verification is even faster than CNv0 on Raspberry Pi (3.2 vs 3.1 H/s)
(12:19:39 PM) sech1: CNv0 was the fastest algo across all CPUs
(12:23:43 PM) wowario_ left the room (quit: Quit: WeeChat 1.4).
(12:26:29 PM) tevador: yes, CNv0 is faster than CN/R in all cases except on the i3 without AES
(12:27:10 PM) sech1: "Intel Core i3-3220 29 H/s 26 H/s"
(12:27:20 PM) sech1: CNv0 is faster there too if I'm reading it right
(12:27:33 PM) tevador: I mean the multithreaded result
(12:28:14 PM) sech1: Why did you run 4 threads on Core i3-3220? It has only 3 MB cache
(12:28:28 PM) tevador: because it runs faster than 1 thread
(12:28:38 PM) sech1: 2 threads will be probably faster than 4
(12:28:56 PM) tevador: ok, I will test 2 threads
(12:29:05 PM) sech1: anyway, it gets limited by memory, this is why it gets identical speed with CNv0 and CN/R and 4 threads
(12:29:57 PM) tevador: I tested CN/R with 2 threads
(12:30:00 PM) tevador: 31 H/s
(12:30:20 PM) tevador: but forgot to test CNv0
(12:31:06 PM) sech1: It doesn't matter, RandomX is clearly faster or on par with CNv0 verification speed
(12:31:10 PM) sech1: in all cases
(12:32:07 PM) tevador: the i3 is limited by AES
(12:32:12 PM) tevador: not memory
(12:32:37 PM) hyc: probably should have kept that comparison chart issue open and pasted your results there
(12:32:51 PM) hyc: everything in the POW discussion thread is going to get lost
(12:33:43 PM) tevador: sech1: 36 H/s with 2 threads
(12:36:50 PM) lithium_pt [~lithiumpt@195.242.213.150] entered the room.
(12:37:07 PM) dEBRUYNE: hyc: I'll create a new discussion thread after the meeting
(12:38:10 PM) lithiumpt left the room (quit: Ping timeout: 272 seconds).
(12:38:33 PM) dEBRUYNE: tevador: We can coordinate so you can post your comment first
(12:38:41 PM) dEBRUYNE: Or I can add your comment to the OP if you provide the source
(12:38:51 PM) sech1 left the room (quit: Quit: Leaving).
(12:40:30 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(12:42:48 PM) tevador: the command is linked from here: https://github.com/tevador/RandomX/issues/28[1]
(12:42:52 PM) tevador: so it will not get lost
(12:42:55 PM) tevador: comment*
(12:43:14 PM) tevador: I can repost it if you make a new issue dEBRUYNE
(12:45:41 PM) dEBRUYNE: Sure
(12:48:04 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:52:31 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(01:25:25 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(01:33:50 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(01:46:51 PM) fort3hlulz left the room (quit: Quit: Leaving).
(01:49:08 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(01:50:10 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1005::ab] entered the room.
(03:04:01 PM) el00ruobuob left the room (quit: Remote host closed the connection).
(03:04:42 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(03:26:17 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(03:46:36 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:08:35 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:11:59 PM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(04:15:03 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(05:32:29 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(06:21:04 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(07:07:20 PM) fort3hlulz [~setsimmo@173.38.117.93] entered the room.
(07:21:04 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(07:24:40 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(07:28:29 PM) fort3hlulz [~setsimmo@173.38.117.93] entered the room.
(07:29:00 PM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(07:33:02 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(07:45:16 PM) fort3hlulz [~setsimmo@173.38.117.93] entered the room.
(07:49:58 PM) fort3hlulz left the room (quit: Ping timeout: 246 seconds).
(08:06:48 PM) sech1 left the room (quit: Quit: Leaving).
(08:26:40 PM) [-mugatu-] is now known as XxX_1337_sn1p3r_
(08:26:53 PM) XxX_1337_sn1p3r_ is now known as [-mugatu-]
(08:49:41 PM) kopite7 left the room (quit: Ping timeout: 246 seconds).
(09:09:19 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(09:19:10 PM) fort3hlulz [~setsimmo@173.38.117.74] entered the room.
(09:26:26 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(10:29:17 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:28:13 PM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(11:32:14 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(11:47:47 PM) cryptodonkey left the room (quit: Remote host closed the connection).
(11:55:27 PM) cryptodonkey [~cryptodon@yunohost-arm64-6c.11c8.cloud] entered the room.
(02:19:56 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:30:43 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(02:31:44 AM) kopite7 left the room (quit: Client Quit).
(02:40:41 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:41:37 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:01:44 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:28:39 AM) investanto left the room (quit: Quit: Changing servers).
(03:28:52 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(03:28:57 AM) dEBRUYNE left the room ("Leaving").
(04:04:42 AM) investanto left the room (quit: Quit: Changing servers).
(04:04:54 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(04:49:30 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:06:03 AM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:09:37 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(05:29:37 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:37:07 AM) tevador: Grin ASIC will have 512 MiB of on-chip memory
(05:37:08 AM) tevador: https://www.grin-forum.org/t/obelisk-grn1-chip-details/4571[1]
(05:50:09 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:50:43 AM) sech1: How does it impact light verification mode of RandomX?
(05:51:01 AM) midipoet [uid316937@gateway/web/irccloud.com/x-zlmudmenizkgvtew] entered the room.
(05:55:54 AM) tevador: I'm assuming ASIC manufacturers would first try a single chip ASIC for RandomX
(05:56:03 AM) tevador: the preference is clear for single-chip designs
(05:56:58 AM) tevador: this ASIC would mine in verification mode
(06:08:14 AM) bearretinjapan is now known as ferretinjapan
(08:14:37 AM) LSDog left the room (quit: Ping timeout: 245 seconds).
(09:29:56 AM) sech1: But verification mode requires 8 dataset accesses, each dependent on previous one, right?
(09:30:11 AM) sech1: and 42*8 multiplications, so fast SRAM won't help here
(09:43:53 AM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(09:56:43 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(10:03:33 AM) tevador: yes, it will be slow, but it may still be more power efficient or cheaper to design than a multi chip solution
(10:40:21 AM) sech1: 336 64-bit multiplications is quite a bit of power, probably more than reading 64 bytes from DRAM. This is one of questions we should ask ASIC designers about.
(10:53:49 AM) tevador: 64 bytes read from DRAM takes about 100 nJ
(11:13:17 AM) tevador: at 7nm, 1 DP FLOP takes about 20 pJ, so 336 multiplication may still use less energy than DRAM
(11:51:40 AM) sech1: Where did you get these numbers from?
(11:52:58 AM) sech1: by assuming that GTX 1080 Ti can do 11.5 TFLOPS at 250 watts?
(11:53:15 AM) sech1: but these are 32-bit FLOPS
(11:56:15 AM) tevador: yes, but 1080 Ti is 14 nm, so 7 nm can do the same with double precision
(11:57:01 AM) tevador: even if it was 30 pJ, that's still less than the DRAM read
(12:02:00 PM) tevador: here is some source: https://books.google.cz/books?id=fZsXBgAAQBAJ&pg=PA6&lpg=PA6&source=bl&ots=MI2qfIEv90&sig=ACfU3U22rFGSWBSoIBTkALq9I5wh8LL0wQ&hl=cs&sa=X&ved=2ahUKEwjbneH30JjhAhUEKVAKHde4Cp44ChDoATACegQIBxAB#v=onepage[1]
(12:02:30 PM) tevador: reading DRAM take 2 orders of magnitude more energy
(12:05:22 PM) tevador: that is data from 2010, but the ratios will not be much different in 2019, could be actually worse for DRAM now
(12:07:10 PM) sech1: Why don't we increase N in SquareHash? It's not time-critical part in the algorithm
(12:07:25 PM) sech1: Not 42, but 142 multiplications for example
(12:21:34 PM) sech1: Oh, forget it
(12:21:52 PM) sech1: Verification time will be too high
(12:25:11 PM) tevador: yes exactly
(12:25:36 PM) tevador: this is the maximum we can do and still keep faster verification than CN
(12:31:36 PM) tevador: I did a ballpark estimate and got 15200 H/s from a 800 mm2 chip with 95 W power consumption
(12:31:59 PM) tevador: that's 3.2x more efficient than a CPU
(12:32:16 PM) tevador: but the chip is HUGE
(12:32:32 PM) tevador: this was at 16 nm 
(12:32:56 PM) tevador: 7 nm doesn't have the yield for such chip
(12:34:24 PM) tevador: this chip has 754 MiB of SRAM btw
(12:58:31 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(01:05:09 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1006::f1] entered the room.
(01:08:22 PM) fort3hlulz left the room (quit: Ping timeout: 245 seconds).
(01:24:46 PM) sech1: 256 MB SRAM can fit in 160 mm^2, how did you get 800 mm^2?
(01:25:07 PM) fort3hlulz_ left the room (quit: Ping timeout: 240 seconds).
(01:25:17 PM) sech1: https://en.wikichip.org/wiki/16_nm_lithography_process[1]
(01:25:22 PM) sech1: Bit cell size 0.07 µm²
(01:25:36 PM) sech1: if you do the math, you'll get ~160 mm^2
(01:26:30 PM) sech1: or I looked at the wrong number
(01:27:24 PM) sech1: TSMC 128 Mib SRAM demo 16 nm wafer = 42.6 mm^2, so 2048 Mib (256 MB) will be 681.6 mm^2
(01:30:15 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(01:32:41 PM) midipoet [uid316937@gateway/web/irccloud.com/x-zwlbtofmuhmafyik] entered the room.
(01:49:43 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(02:02:38 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:07:04 PM) tevador: my estimate is based on the grin discussion
(02:07:15 PM) tevador: they have 512 MiB on a single 16 nm die
(02:26:45 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(03:08:40 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(03:12:30 PM) tevador: sech1: https://github.com/tevador/RandomX/issues/31[1]
(03:21:40 PM) sech1: "All RandomX instructions have a 1-cycle latency." I don't think it's possible for 64-bit FP DIV and SQRT
(03:21:51 PM) sech1: they're more like 3 cycles at 1 GHz
(03:23:31 PM) sech1: "311 cycles for the program execution 704 cycles to calculate the dataset item" but they can run in parallel because of prefetch, right?
(03:23:33 PM) tevador: yes, I'm being overly optimistic here
(03:24:34 PM) tevador: right, they could run in parallel, but then you would need more cores
(03:24:57 PM) tevador: also I didn't include the SquareHash cores at all in the calculation
(03:25:19 PM) sech1: Not really, SquareHash can be fully pipelined into a single 336-stage pipeline
(03:25:30 PM) sech1: and used by all cores, producing results every cycle
(03:25:50 PM) sech1: 336 multipliers and adders, smallers than full CPU cores
(03:25:56 PM) tevador: not sure if all 8 can be pipelines, but 1 sure can be
(03:26:05 PM) tevador: you have SRAM accesses in between
(03:26:31 PM) sech1: 42-stage pipeline then
(03:27:13 PM) sech1: But I think it makes more sense to still use existing CPU cores for SquareHash in case RandomX changes in the future
(03:27:52 PM) tevador: yes, we could change it to 41 or 43 rounds and it'd be bricked
(03:28:11 PM) sech1: not bricked, they would have to switch to CPU cores for this
(03:28:29 PM) tevador: assuming the cores are capable of this
(03:28:47 PM) tevador: for example if there is spare ROM for additional code
(03:29:06 PM) sech1: yes, if they just use existing ARM design
(03:29:42 PM) tevador: I don't think they can, ARM expects real RAM and has caches, not scratchpads
(03:30:01 PM) tevador: it must be some custom CPU, possibly with some ARM IP
(03:34:51 PM) tevador: so if the SquareHashes run in parallel, the numbers slightly change to 20 KH/s at 100 W
(03:34:58 PM) tevador: so about 4x more efficient
(03:37:37 PM) tevador: the bandwidth for Cache accesses is over 1 TB/s
(03:38:14 PM) tevador: no, wait, just 120 GB/s, which is nothing
(03:39:21 PM) sech1: 120 GB/s of SRAM accesses, do they add something to 0.1W/mm^2 or is it 0.1W/mm^2 always?
(03:39:37 PM) tevador: I estimate 0.1 for all SRAM
(03:39:45 PM) tevador: Cache + scratchpads
(03:43:52 PM) sech1: How did you count CPU power? Only CPU or CPU + DRAM + motherboard?
(03:44:11 PM) sech1: I think this single-chip ASIC is getting into dangerously-efficient territory
(03:44:23 PM) sech1: 8 accesses to 256 MB dataset is too little
(03:59:02 PM) tevador: I measured my laptop, 1660 H/s, 33 W at the wall
(03:59:14 PM) tevador: with screen off
(03:59:27 PM) tevador: I think a server could have higher efficiency than this
(04:00:18 PM) tevador: the CPU itself is only 15 W
(04:02:53 PM) tevador: we cannot do more than 8 accesses
(04:03:40 PM) tevador: the original version with 16 accesses was more resistant to this design, but the verification was too slow
(05:05:59 PM) sech1 left the room (quit: Quit: Leaving).
(05:20:15 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(06:01:25 PM) midipoet [uid316937@gateway/web/irccloud.com/x-hjgefxmxdxbmwjdv] entered the room.
(06:56:36 PM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(07:17:50 PM) jwinterm left the room (quit: Quit: No Ping reply in 180 seconds.).
(07:18:42 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(07:27:07 PM) el00ruobuob_[m] [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(09:03:23 PM) investanto left the room (quit: Quit: Changing servers).
(09:03:35 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:40:15 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:43:22 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(11:37:37 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:47:10 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(12:02:44 AM) kico left the room (quit: Remote host closed the connection).
(12:03:12 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(12:07:51 AM) rottensox left the room (quit: Quit: Leaving).
(12:31:34 AM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(12:33:12 AM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1004::55] entered the room.
(12:36:23 AM) fort3hlulz left the room (quit: Ping timeout: 246 seconds).
(12:53:19 AM) fort3hlulz_ left the room (quit: Ping timeout: 268 seconds).
(02:52:56 AM) investanto left the room (quit: Quit: Changing servers).
(02:53:09 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(03:06:54 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(03:54:00 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(04:14:35 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(04:44:14 AM) midipoet [uid316937@gateway/web/irccloud.com/x-gxfuemckhfujproo] entered the room.
(05:17:27 AM) rottensox left the room (quit: Remote host closed the connection).
(05:17:48 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(05:18:15 AM) rottensox left the room (quit: Max SendQ exceeded).
(05:20:06 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(05:29:13 AM) p0nziph0ne left the room (quit: Quit: Leaving).
(06:05:15 AM) investanto left the room (quit: Quit: Changing servers).
(06:05:28 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(06:08:25 AM) tevador: sech1: I think we could replace SquareHash with a random program of similar latency
(06:33:17 AM) investanto left the room (quit: Quit: Changing servers).
(06:33:30 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(06:53:40 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(07:11:26 AM) rottensox left the room (quit: Remote host closed the connection).
(07:36:45 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(07:49:13 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(08:02:10 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(08:37:22 AM) rottensox left the room (quit: Quit: Leaving).
(09:13:33 AM) investanto left the room (quit: Quit: Changing servers).
(09:13:45 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(10:03:37 AM) investanto left the room (quit: Quit: Changing servers).
(10:19:52 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(11:01:43 AM) hyc: just an idle thought - how about exposing a status flags register, and incorporating that in calculations as well?
(11:01:59 AM) hyc: e.g. Negative / Overflow / Zero / Carry
(11:17:15 AM) tevador: hyc: it's already used by the COND instruction
(11:19:40 AM) hyc: yeah I meant using its bit pattern as an arithmetic operand, not just testing conditions
(11:20:41 AM) hyc: anyway it would be a pain to maintain, and a native RandomX chip would have an advantage there
(11:26:13 AM) tevador: hyc: the problem is that some bits are undefined and the order of flag differs on x86 and ARM
(11:26:39 AM) hyc: yes, understood
(11:32:15 AM) tevador: hyc: have you seen our single chip ASIC estimate?
(11:32:52 AM) hyc: haven't fully caught up yet
(11:33:02 AM) hyc: reading the grin discussion now
(11:33:20 AM) hyc: and yeah, putting 512MB of SRAM on a single die is kind of ludicrous
(11:33:38 AM) tevador: they will put 1024 MiB for C32
(11:33:41 AM) hyc: 6 transistors per SRAM bit, kills your desnity and power budget all at once
(11:34:10 AM) tevador: 1024 MiB is reportedly feasible at 10 nm
(11:34:20 AM) midipoet [uid316937@gateway/web/irccloud.com/x-zbwyhvlvnhfdixiq] entered the room.
(11:34:30 AM) hyc: possible maybe. with tolerable yields? not likely
(11:34:49 AM) tevador: I did some math about the 800 mm2 16nm chip
(11:34:58 AM) tevador: yield are not terrible because it's a mature process
(11:35:03 AM) tevador: yields*
(11:35:30 AM) sech1: But how much would it cost per chip? 800 mm^2 is a lot
(11:35:34 AM) tevador: I calculated that around 61% of chips are without defects
(11:35:39 AM) midipoet: Is the POW meeting in here at 17:00 UTC?
(11:35:44 AM) tevador: 66 dies per wafer
(11:35:53 AM) sech1: midipoet Not here, in #monero-dev
(11:36:00 AM) midipoet: Kk. Thanks 
(11:36:05 AM) tevador: so 41 working dies per wafer
(11:36:17 AM) tevador: not sure about the cost per wafer at 16nm
(11:36:25 AM) tevador: probably at least 7k
(11:39:56 AM) tevador: sech1: I'm planning to use something like CN/R code generator instead of SquareHash
(11:40:18 AM) tevador: it can use more power and have the same latency
(11:40:44 AM) tevador: same latency on CPU
(11:55:27 AM) hyc: so what's the conclusion so far, on 16nm you could build an 800mm^2 randomX chip?
(12:26:50 PM) tevador: yes
(12:26:59 PM) tevador: or maybe
(12:27:09 PM) tevador: it seems to be borderline feasible
(12:28:51 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(12:55:22 PM) vtnerd left the room (quit: Ping timeout: 246 seconds).
(01:18:18 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(01:21:51 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(01:27:23 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:30:42 PM) vtnerd left the room (quit: Ping timeout: 250 seconds).
(01:36:32 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(01:39:06 PM) vtnerd left the room (quit: Excess Flood).
(01:42:11 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(01:43:20 PM) vtnerd left the room (quit: Excess Flood).
(01:46:44 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(01:47:06 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:48:30 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(01:48:47 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:52:19 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(02:13:13 PM) vtnerd left the room (quit: Ping timeout: 268 seconds).
(02:19:49 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(02:21:17 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:30:31 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(02:32:17 PM) vtnerd left the room (quit: Excess Flood).
(02:33:08 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(02:56:10 PM) hyc: wondering if linking randomX on hackernews will help or hurt. more eyes, but mostly clowns
(02:56:22 PM) hyc: do people still use slashdot?
(02:56:56 PM) ***moneromooo flashback of bill gates doing something nasty again
(03:23:39 PM) antanst1 [~antanst@62.169.219.213] entered the room.
(03:24:10 PM) antanst left the room (quit: Ping timeout: 255 seconds).
(03:27:52 PM) tevador: hyc: the issue you linked here is outdated: https://www.realworldtech.com/forum/?threadid=183905&curpostid=184026[1]
(03:34:59 PM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(03:35:57 PM) Trick14 [~dabooz@d54C0FA5E.access.telenet.be] entered the room.
(03:46:07 PM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(03:51:17 PM) dr-mike [uid42387@gateway/web/irccloud.com/x-wemsogrbszxtidag] entered the room.
(04:01:19 PM) ProkhorZ [~ProkhorZ@2a02:a451:82ce:1:55b8:576:5bce:7308] entered the room.
(04:01:21 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(04:04:54 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:13:56 PM) antanst1 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(04:14:25 PM) antanst1 [~antanst@62.169.219.213] entered the room.
(04:15:07 PM) antanst1 left the room (quit: Client Quit).
(04:15:16 PM) needmoney90: Hyc: HN isn't clowns from what I've seen
(04:15:28 PM) needmoney90: Their comments section is miles better than other sites 
(04:15:29 PM) antanst1 [~antanst@62.169.219.213] entered the room.
(04:17:30 PM) tevador: hyc any comments on this? https://github.com/tevador/RandomX/issues/31[1]
(04:27:00 PM) vtnerd_ [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(04:27:33 PM) vtnerd left the room (quit: Ping timeout: 245 seconds).
(04:32:41 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:45:51 PM) ProkhorZ left the room (quit: Quit: Leaving).
(05:31:30 PM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(05:42:55 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(06:07:19 PM) glv [~glv@101.ip-54-38-183.eu] entered the room.
(06:13:57 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:36:41 PM) hyc: 256MB of SRAM will soak a lot of power
(06:38:33 PM) hyc: I'll post the new link to the forum and see if anyone bites
(06:40:54 PM) hyc: so 3x for a single-chip design using 256MB cache. meaning the external dataset size doesn't really affect the numbers
(06:44:18 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(07:00:01 PM) tevador: yes, this chip has a total of 754 MiB of SRAM including scratchpads
(07:01:05 PM) tevador: I'd like to still make some changes to kill this single chip design if possible...
(07:03:50 PM) dr-mike left the room (quit: Quit: Connection closed for inactivity).
(07:45:30 PM) OhGodAGirl_: Hi, I missed the dev meeting. However, I had a few pings here:
(07:47:12 PM) OhGodAGirl_: While I don't think one individual can do a full audit, I have given a suggestion to fluffypony which he can share if he chooses. The appropriate way to handle this is to have three verticals engaged - Cryptocurrency ASIC companies that specialize in single-chip designs (Obelisk), large-scale manufacturers of CPUs, (Intel and AMD), and a few fabs (TSMC and Samsung). I believe we'd be able to organize this. 
(07:48:26 PM) OhGodAGirl_: Note that RandomX will need to be tuned every so often, as newer generation hardware comes out and technological advancements happen. Probably every six to nine months. 
(07:51:28 PM) OhGodAGirl_: The above process would allow you to get a multi-party audit by a handful of large corporations and small corporations, allowing for a good sample size. 
(08:02:09 PM) OhGodAGirl_: Also, please do not switch to ProgPoW (saw that in the logs), we don't need major coins sharing algorithms. :) Monero wants CPUs, that's its goal. Let's help it achieve that the correct way. 
(08:11:14 PM) jwinterm: which major coin is using progpow?
(08:17:31 PM) sech1 left the room (quit: Quit: Leaving).
(08:23:22 PM) vp11 left the room (quit: Changing host).
(08:23:22 PM) vp11 [curumim@unaffiliated/vp11] entered the room.
(08:23:23 PM) vp11 left the room (quit: Changing host).
(08:23:23 PM) vp11 [curumim@gateway/shell/elitebnc/x-hwgknlxprkdmvjzb] entered the room.
(08:26:59 PM) kico left the room (quit: Remote host closed the connection).
(08:27:25 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(08:44:03 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:31:07 PM) Trick14 left the room (quit: Ping timeout: 252 seconds).
(09:43:52 PM) Trick14 [~dabooz@d54C0FA5E.access.telenet.be] entered the room.
(10:29:38 PM) kopite7 left the room (quit: Quit: Leaving.).
(10:39:51 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:51:26 PM) rottensox left the room (quit: Ping timeout: 250 seconds).
(11:22:58 PM) ArticMine left the room (quit: Ping timeout: 255 seconds).
(11:36:40 PM) ArticMine [~ArticMine@S0106ac202ecaeb73.vn.shawcable.net] entered the room.
(11:49:04 PM) kopite7 left the room (quit: Quit: Leaving.).
(11:58:36 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(01:51:17 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:25:57 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:51:51 AM) el00ruobuob [~el00ruobu@lns-bzn-59-82-252-131-206.adsl.proxad.net] entered the room.
(02:55:17 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 244 seconds).
(02:55:51 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(02:57:32 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(03:01:04 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:26:14 AM) sech1 left the room (quit: Quit: Leaving).
(03:37:44 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:38:51 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(03:44:37 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(04:23:15 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(05:00:03 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:18:35 AM) midipoet [uid316937@gateway/web/irccloud.com/x-kseemqfgxulkjgqp] entered the room.
(05:19:20 AM) midipoet: OhGodAGirl_: that's pretty neat! exciting times...
(07:16:38 AM) sech1 left the room (quit: Quit: Leaving).
(07:33:36 AM) lithium_pt left the room (quit: Ping timeout: 250 seconds).
(07:34:59 AM) lithiumpt [~lithiumpt@195.242.213.150] entered the room.
(08:41:38 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(08:52:14 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(08:54:03 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:02:39 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(09:06:26 AM) fort3hlulz [~setsimmo@173.38.117.82] entered the room.
(09:14:03 AM) fort3hlulz left the room (quit: Quit: Leaving).
(09:20:51 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:37:52 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(09:41:42 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:56:22 AM) spaced0ut_ [~spaced0ut@198.211.112.88] entered the room.
(09:56:54 AM) spaced0ut_ left the room (quit: Client Quit).
(09:58:46 AM) spaced0ut left the room (quit: Ping timeout: 250 seconds).
(10:00:27 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:13:06 AM) spaced0ut left the room (quit: Ping timeout: 272 seconds).
(10:19:52 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:20:41 AM) wowario left the room (quit: Ping timeout: 256 seconds).
(10:21:08 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(10:58:56 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:15:11 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(11:15:27 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(11:15:46 AM) spaced0ut left the room (quit: Ping timeout: 250 seconds).
(11:15:54 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:24:26 AM) LSDog left the room (quit: Ping timeout: 250 seconds).
(11:32:54 AM) vtnerd_ left the room (quit: Ping timeout: 272 seconds).
(11:38:19 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(11:42:38 AM) vtnerd left the room (quit: Ping timeout: 250 seconds).
(11:46:56 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(11:47:29 AM) vtnerd left the room (quit: Excess Flood).
(11:51:38 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(11:57:08 AM) vtnerd left the room (quit: Ping timeout: 245 seconds).
(12:00:24 PM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(12:00:28 PM) dEBRUYNE: Fyi, I opened -> https://github.com/monero-project/meta/issues/321[1]
(12:00:45 PM) dEBRUYNE: tevador: Could you post the new verification times of RandomX as comment?
(12:09:15 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:18:10 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(12:23:53 PM) sech1 left the room (quit: Quit: Leaving).
(12:38:47 PM) vtnerd left the room (quit: Ping timeout: 268 seconds).
(12:40:27 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:45:19 PM) vtnerd_ [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:45:56 PM) hyc: for the newer audience, here's a nice discussion on accelerating processing with specialized hardware http://yosefk.com/blog/its-done-in-hardware-so-its-cheap.html
(12:46:18 PM) vtnerd left the room (quit: Ping timeout: 245 seconds).
(12:47:47 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(12:48:34 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(12:55:59 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:57:15 PM) antanst1: Some nice info about Cuckatoo ASICs that may or may not apply generally here https://www.grin-forum.org/t/obelisk-grn1-chip-details/4571[1]
(12:57:46 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(12:59:19 PM) hyc: yes tevador already linked that discussion
(01:00:21 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:14:30 PM) LSDog_ [~LSDog@unaffiliated/lsdog] entered the room.
(01:17:53 PM) LSDog left the room (quit: Ping timeout: 246 seconds).
(01:39:06 PM) sech1 left the room (quit: Quit: Leaving).
(01:40:52 PM) vtnerd_ left the room (quit: Ping timeout: 245 seconds).
(01:44:36 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(01:46:40 PM) tevador: OhGodAGirl_: there are no major technological advances in CPU technology every 6-9 months
(01:47:09 PM) tevador: RandomX runs pretty much with the same per core performance on 2011 Sandy Bridge, just uses a lot more power than a recent chip
(01:48:26 PM) tevador: and IIRC ProgPow was suggested after Ethereum goes POS
(02:03:00 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:09:14 PM) hyc: another nonsense suggestion... Moore's Law is dead, CPU evolution is going to parallelism
(02:10:34 PM) hyc: clock rates are at their ceiling. there are no major performance breakthroughs on any horizon
(02:11:11 PM) hyc: which is another reason random code is a viable approach
(02:15:32 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:16:34 PM) tevador: the only possible major change I see in the next 2-5 years is when AVX-512 is common in x86 CPUs
(02:16:40 PM) p0nziph0ne left the room (quit: Ping timeout: 255 seconds).
(02:16:56 PM) hyc: closer to 5 years than 2 ;)
(02:17:08 PM) tevador: or when core:cache ratio changes significantly
(02:17:56 PM) hyc: also, you can't just adopt those improvements immediately, majority of deployed base will be older generation
(02:18:28 PM) tevador: yes, it would be at least 5 years I think
(02:18:40 PM) hyc: not sure we ever need to adopt AVX512 - there will be no power advantage
(02:19:26 PM) tevador: actually, there will be advantage because we want to use as many execution units as possible
(02:19:33 PM) hyc: as it is, chip slows 50% to run AVX512
(02:19:48 PM) tevador: the CPU has a high overhead power consumption compared to an ASIC
(02:20:13 PM) tevador: hyc: is it so with Skylake-X?
(02:20:29 PM) hyc: is that the newest? not sure
(02:21:22 PM) tevador: it's one of the few archs that support it at the moment
(02:21:47 PM) hyc: seems to still be true, and unavoidable 
(02:21:49 PM) hyc: https://www.reddit.com/r/hardware/comments/6mt6nx/why_does_skylake_sp_throttle_when_doing_avx/
(02:21:54 PM) dEBRUYNE: I noted yesterday that this should be seen as a natural evolvement which doesn't require tweaking the algorithm
(02:21:56 PM) tevador: but even if clock drops say 25%, you still benefit from fewer instructions being decoded
(02:21:59 PM) hyc: fixed chip TDP budget
(02:22:16 PM) tevador: dEBRUYNE: it does, because RandomX doesn't benefit from AVX-512
(02:22:43 PM) dEBRUYNE: So new CPUs would have an advantage right?
(02:22:53 PM) tevador: no advantage at all
(02:23:00 PM) tevador: just more silicon sitting idle
(02:23:30 PM) dEBRUYNE: Can you explain how that would be a problem for RandomX?
(02:23:51 PM) tevador: it decreases ASIC resistance
(02:24:07 PM) tevador: because CPUs would contain parts that ASIC doesn't need to mine
(02:24:17 PM) luigi1111: skylake is 3 gens old by now?
(02:24:30 PM) luigi1111: although gens aren't what they used to be
(02:24:32 PM) tevador: skylake-x, not skylake
(02:24:43 PM) gethh: the last major speed up was AES 
(02:24:49 PM) tevador: it's the enthusiast platform
(02:25:02 PM) gethh: and ability to perform SBOX kinda in hardware
(02:25:14 PM) dEBRUYNE: tevador: I see, thanks for explaining
(02:25:18 PM) luigi1111: oh well still a gen old
(02:25:27 PM) luigi1111: hey that's what I have 
(02:25:36 PM) tevador: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512[1]
(02:25:56 PM) tevador: I would say less than 1% of CPUs today support it
(02:26:28 PM) sech1: I have one at work that supports it
(02:26:31 PM) tevador: Xeon Phi is now obsolete
(02:28:03 PM) tevador: dEBRUYNE: but we are talking about perhaps 5 years before such tweak would be needed
(02:28:30 PM) tevador: so it's not really relevant for the discussion at the moment
(02:29:11 PM) sech1: On the other hand, proper AVX support will be a common thing on x86 processors when new Ryzens release
(02:29:17 PM) sech1: Why don't we switch to AVX?
(02:29:26 PM) sech1: AVX256
(02:30:01 PM) tevador: I was thinking about it, but haven't found a good way to fill the registers with data
(02:30:41 PM) sech1: 4xAES to get next 64 bytes out of dataset line? Doesn't work?
(02:30:42 PM) tevador: if there is some way to use it that doesn't impact performance, I'm for it
(02:30:49 PM) luigi1111: yay I'm the 1%
(02:30:52 PM) hyc: and I think current ARM NEON is still only 128bit
(02:31:00 PM) luigi1111: also forgot the new x is still skylake... 
(02:31:32 PM) sech1: hyc ARM NEON has bad performance on RandomX anyway, it doesn't have big cache
(02:34:36 PM) dEBRUYNE: tevador: I see, thanks for clarifying
(02:34:41 PM) hyc: it really doesn't make sense for AMD to adopt AVX512. big vectors are where GPUs shine, and AMD has GPUs in spades
(02:40:12 PM) LSDog_ left the room (quit: Quit: MONERO NUMBA 1).
(02:47:59 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(02:52:43 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(02:54:13 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(02:55:58 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(02:57:46 PM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(03:13:35 PM) tevador: since there is a lot of opposition to tweaking, we should make all changes we can think of before RandomX is deployed
(03:14:22 PM) hyc: within reason. we need the reference impl to be stable so we can start building the other impls - daemon, miners, etc.
(03:14:53 PM) tevador: yes, we should set a code freeze date
(03:15:10 PM) tevador: first level date just for RandomX
(03:16:03 PM) hyc: how much time do we think needs to be reserved for 2 audits?
(03:16:53 PM) moneromooo: When were the BP audits started (as in, RFQ) ?
(03:17:36 PM) hyc: might have to ask sarang or suraeNoether
(03:17:44 PM) dEBRUYNE: I vaguely remember May/June
(03:17:59 PM) dEBRUYNE: oh RFQ may have been earlier
(03:18:06 PM) dEBRUYNE: I think that was April already
(03:37:15 PM) suraeNoether: sarang should have the actual dates in his email
(03:55:02 PM) LSDog left the room (quit: Ping timeout: 245 seconds).
(04:03:51 PM) lurkinandlearnin [~lurkinand@2a02:c7d:b7d8:4100:d4e0:eeb1:e899:aa2c] entered the room.
(04:03:55 PM) learninandlurkin [~lurkinand@2a02:c7d:b7d8:4100:d4e0:eeb1:e899:aa2c] entered the room.
(04:04:10 PM) learninandlurkin left the room (quit: Client Quit).
(04:08:23 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(04:12:27 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(04:15:54 PM) crCr62U0 left the room (quit: Quit: leaving).
(04:16:13 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:16:33 PM) tevador: so 30th April should be a reasonable freeze date
(04:18:40 PM) lurkinandlearnin left the room (quit: Quit: Leaving).
(04:19:54 PM) hyc: sounds ok
(04:34:12 PM) LSDog left the room (quit: Ping timeout: 245 seconds).
(04:37:23 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(04:42:10 PM) hyc: btw, some key takeaways from articles like this http://yosefk.com/blog/its-done-in-hardware-so-its-cheap.html
(04:42:35 PM) hyc: specialization lets you gain efficiency because you remove the overhead of generic control flow
(04:42:46 PM) hyc: parallelization lets you gain performance - but not efficiency
(04:43:45 PM) hyc: for an ASIC developer - or any miner developer - to come up with dramatic secret optimizations to randomX is pretty unlikely, because the ops themselves are already simple
(04:44:12 PM) hyc: typically execute in 1 cycle on a CPU and cannot be optimized further in hardware
(04:44:43 PM) hyc: if the ops themselves cannot be accelerated, then the only avenue is optimizing the control flow
(04:45:37 PM) needmoney90: It may be possible to find particular common series of instructions that crop up more often than others, and optimize those to get incremental (10% level) improvements on efficiency/speed
(04:46:18 PM) hyc: well... you could build a custom CPU that natively implements the randomX instruction set, sure
(04:46:36 PM) hyc: that is essentially what you would need, to optimize a common sequence of instructions
(04:47:21 PM) hyc: but if each instruction executes in 1 cycle, you're unlikely th be able to compress 10 instructions into 9 cycles
(04:47:41 PM) hyc: anyway...
(04:48:28 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(04:48:32 PM) hyc: the control flow is also sufficiently simple that there's not a lot to optimize there either. I mean, barring the recently added branches, it was a straight line from first to last instruction
(04:49:29 PM) hyc: the one factor you can play with is frequency vs power, power is typically quadratic with frequency
(04:49:49 PM) hyc: although there's a lower threshold where that relationship becomes more linear
(04:50:21 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:50:39 PM) hyc: so if all else were equal, your best bet would be a slew of ARM Cortex A-35 cores attached to a big hunk of RAM
(04:51:03 PM) hyc: running at a few hundred MHz or something ridiculously slow, sipping power
(04:51:37 PM) hyc: of course all else is not equal, and using huge numbers of cores brings new costs in terms of inter-core communication and synchronization
(04:52:11 PM) hyc: if this were a viable approach, Xeon Phi would be a mainstream product already, but instead it's discontinued
(04:53:08 PM) hyc: tradeoffs everywhere.
(04:55:53 PM) dEBRUYNE left the room ("Leaving").
(05:10:09 PM) crCr62U0 left the room (quit: Quit: leaving).
(05:10:30 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:38:16 PM) ferretinjapan left the room (quit: Ping timeout: 244 seconds).
(06:18:35 PM) tevador: damned big endian
(06:30:07 PM) sech1 left the room (quit: Quit: Leaving).
(06:36:50 PM) needmoney90: https://old.reddit.com/r/Monero/comments/b50mfy/logs_from_the_25_hr_dev_meeting_on_moneros_pow/ejdh2sn/[1]
(06:36:52 PM) needmoney90: tevador hyc
(06:45:22 PM) linzhi-sonia: hello everybody. I try to keep up with the careful thoughts and decisions here, which is great. As I said earlier I cannot contribute that much right now because you are having a consistent approach that needs to grow carefully and with time to adapt, not shock-like. All is good!
(06:45:55 PM) linzhi-sonia: just one small thing. the meeting notes quote tevador saying "Linzhi refused to make comments about RandomX because they clearly don't want it adopted"
(06:46:30 PM) linzhi-sonia: it's great to think about motivation, conflicts of interest etc - but if you get carried away and you are just SURE to know why someone says something, that's risky
(06:46:38 PM) linzhi-sonia: Linzhi doesn't want RandomX adopted? why?
(06:46:42 PM) linzhi-sonia: it doesn't even matter
(06:46:55 PM) linzhi-sonia: *unfortunately* I cannot provide more info and feedback about RandomX, I wish I could
(06:47:08 PM) linzhi-sonia: I said it looks like progpow for cpus, from a high level view
(06:48:03 PM) linzhi-sonia: if we would ever make a chip for randomx, we would probably try to target ethash, progpow and randomx in one solution. but that's a very high-level "first thought" only. we have no such plans at all, if we would have them I would share and ask here first.
(06:48:54 PM) linzhi-sonia: "refused" and "doesn't want it" is not fair. Cannot help much! that's the truth
(06:49:14 PM) linzhi-sonia: I personally definitely like randomx better than cn
(06:50:38 PM) needmoney90: linzhi-sonia: I encourage you to look at these comments as being made by individuals, and not the project as a whole.
(06:50:52 PM) linzhi-sonia: it looks like the CNv4 fork was successful and led to the expected outcome. that is great! I am not sure you have until October for RandomX, but who knows. You are definitely preparing well!
(06:51:00 PM) linzhi-sonia: oh yes, sure. all is good.
(06:51:05 PM) linzhi-sonia: I am picking out some details.
(06:51:16 PM) linzhi-sonia: everyone has the right to be emotional, angry even
(06:51:25 PM) linzhi-sonia: I'm just surprised reading about "refusal" and "doesn't want"
(06:51:26 PM) linzhi-sonia: :)
(06:51:33 PM) linzhi-sonia: we cannot! big difference
(06:51:40 PM) needmoney90: Tevador (and hyc, and the other RandomX developers) are the strongest proponents/cheerleaders for the algorithm's adoption, and are perhaps diametrically opposed to your own interests. Some conflict will happen there, unfortunately
(06:51:53 PM) linzhi-sonia: oh I like this a lot here
(06:51:57 PM) linzhi-sonia: huge difference from progpow
(06:52:09 PM) needmoney90: and in an environment like IRC where there's no filtering by moderators, offhand comments from community members can skew the view of the community as a whole
(06:52:25 PM) linzhi-sonia: I wish progpow would be driven by people that truly care about fair GPU mining, because I can clearly tell those people - they are truly driven by fair CPU mining!
(06:52:40 PM) needmoney90: I just want to make it clear that you are not unwanted, and not everyone is questioning your motives (well, to be fair, I suspect everyone is questioning them - but not everyone is assuming bad faith)
(06:52:43 PM) linzhi-sonia: you guys are doing great
(06:52:50 PM) linzhi-sonia: yes that is good!
(06:52:57 PM) linzhi-sonia: we should think about that! crypto is grown up now
(06:53:09 PM) linzhi-sonia: everyone gets carried away, right? eventually you really believe what you say :)
(06:53:19 PM) linzhi-sonia: it just *HAS TO* be that way :)
(06:53:20 PM) linzhi-sonia: ha ha
(06:53:33 PM) needmoney90: I like the phrase "Strong opinions held weakly" myself
(06:54:00 PM) linzhi-sonia: for our team, I can guarantee for sure whatever we do we will do openly
(06:54:09 PM) linzhi-sonia: that doesn't help much in the big picture, because more secretive asic teams are still around
(06:54:14 PM) linzhi-sonia: and that is also good
(06:54:24 PM) linzhi-sonia: but if we do ANYTHING about randomx, I will bring it up here first
(06:54:41 PM) linzhi-sonia: right not we are just watching
(06:54:50 PM) linzhi-sonia: I already said I like it because it's memory-hard
(06:54:52 PM) linzhi-sonia: I'm sure I said that
(06:54:55 PM) needmoney90: Forgive the majority of the community for being skeptical and always questioning your motivations, especially in the long term :)
(06:54:58 PM) linzhi-sonia: I wish someone would work on "io-hard"
(06:55:10 PM) linzhi-sonia: of course, we are equal
(06:55:16 PM) linzhi-sonia: I get things wrong all the time too.
(06:55:42 PM) linzhi-sonia: there is a guy, Chris Ziomkowski. We like him a lot. He is working on a nice chip architecture called xtend.online
(06:55:46 PM) linzhi-sonia: have you ever heard of Chris?
(06:56:07 PM) linzhi-sonia: I am not sure how much funding he has, and he is not in China so supply chain is an issue for him. But he is a cool guy.
(06:56:32 PM) linzhi-sonia: https://blog.usejournal.com/inside-the-new-crypto-mining-technology-that-will-redefine-the-industry-196529547c88[1]
(06:56:45 PM) linzhi-sonia: is not an endorsement, nothing. no affiliation, no nothing. we just like him.
(06:57:05 PM) linzhi-sonia: his chip, if he can pull it off, could also succesfully mine randomx
(06:58:02 PM) linzhi-sonia: in my thinking, Chris is not an "enemy", nothing wrong with it, just a chipmaker. Better Chris than some weird megacorp or even government institutions like NSA, CIA, who knows.
(06:58:35 PM) linzhi-sonia: I don't think Chris would like to review RandomX either though, he will just laugh and say his chip can mine it :)
(06:58:56 PM) linzhi-sonia: you guys also need to forgive us chipmakers, we are always just focused on our chips...
(06:59:03 PM) linzhi-sonia: that's the only thing we have
(07:09:36 PM) midipoet: Sometimes I think "ASIC resistance POW" is just a proxy for an much deeper social and economic ideology, which funnily enough is actually often shared by the ASIC makers themselves. 
(07:11:07 PM) linzhi-sonia: midipoet: he he. there is some darkness in your thought, but if you imagine that the whole world would have never started with "asic resistance" and everyone would happily use sha256, that would be pretty bad for us :)
(07:11:30 PM) linzhi-sonia: maybe "asic resistance" is our ultimate marketing trick
(07:11:36 PM) linzhi-sonia: is that evil enough? :)
(07:13:16 PM) needmoney90: Breaking news: Monero secretly in bed with ASIC manufacturers to keep them in business with a constantly shifting product line
(07:13:52 PM) linzhi-sonia: yes! we are even improving the forecasting together now!
(07:14:46 PM) midipoet: Can't we all just come together and try and make the world a better place instead? 
(07:14:55 PM) needmoney90: Only if it makes me money
(07:16:13 PM) linzhi-sonia: normally "planned obsolescence" is a bad thing, no?
(07:17:46 PM) linzhi-sonia: midipoet: we could more seriously consider whether PoW is waste and there are better ways. I think that is the motivation of EVERYONE serious since the early days. The original Ripple (by Jed) was already started from the deep realization that PoW is wrong.
(07:18:16 PM) linzhi-sonia: if we do PoW, if we payout rewards for work, then this work will be performed
(07:19:01 PM) linzhi-sonia: I still don't like the idea that "usefulness" is an attack vector. Some people insist on that, and are blocking any sort of attempt for more useful work in PoW
(07:19:59 PM) linzhi-sonia: it looks like Monero is moving towards RandomX in October, and from my side I think that's a big step forward from CN
(07:20:18 PM) linzhi-sonia: and it also looks like you can keep the community more or less coming along
(07:20:45 PM) linzhi-sonia: Ethash was and is stable for 4 years now, no reason to believe that RandomX won't be stable for years
(07:21:16 PM) linzhi-sonia: of course ASICs will slowly (!) appear. I would think that's a good sign, but who knows. The "asic resistance" discussion will never go away I guess.
(07:21:45 PM) linzhi-sonia: you start with a CPU, which is also an ASIC. then you try to predict which technologies will appear in years to come, which is extremely difficult.
(07:22:21 PM) linzhi-sonia: I think if it's stable without sudden shocks, and asics appear slowly, and on the community and software side there is work towards more useful asics, then all is good.
(07:28:21 PM) linzhi-sonia: needmoney90: oh, another community comment, and again that is totally fine, 100% understandable, but it's worth bringing it up. from the log:
(07:28:49 PM) linzhi-sonia: it says about linzhi "just 'we can 10x this, I swear'"
(07:28:52 PM) linzhi-sonia: well
(07:28:55 PM) needmoney90: you are free to defend yourself, of course
(07:28:59 PM) linzhi-sonia: that's why most hardware people prefer to not talk
(07:29:12 PM) linzhi-sonia: in software, you can chat about something, and a day later you have a commit in github
(07:29:18 PM) linzhi-sonia: so it all connects together
(07:29:25 PM) linzhi-sonia: someone who would only talk, and never commit - you would ignore that person soon
(07:29:38 PM) linzhi-sonia: in hardware, I can make 1 chip / year, maybe
(07:29:41 PM) linzhi-sonia: but you want me talking
(07:29:52 PM) linzhi-sonia: so naturally, the more I talk, the more I shuffle my own reputation grave
(07:29:57 PM) linzhi-sonia: "ah, the talker again"
(07:30:03 PM) needmoney90: Have you taken a look at the current randomx implementation?
(07:30:11 PM) moneromooo: You're paranoid, aren't you.
(07:30:23 PM) linzhi-sonia: me? explaining my side
(07:30:33 PM) linzhi-sonia: why chip people don't talk
(07:30:53 PM) moneromooo: It seems most of what you say is not about PoW but about how it would be nice to talk. Talk about PoW then :)
(07:31:01 PM) linzhi-sonia: everyone knows: great people talk about what they have done. good people talk about what they are doing. bad people talk about what they will do.
(07:31:10 PM) linzhi-sonia: but for a chipmaker, that's super hard
(07:31:11 PM) moneromooo: We're on a channel about PoW. You're free to talk about PoW.
(07:31:15 PM) linzhi-sonia: that basically means secret chips
(07:31:33 PM) linzhi-sonia: yeah, PoW: RandomX is great!
(07:31:37 PM) linzhi-sonia: let's do it. october. looks good
(07:31:44 PM) linzhi-sonia: that's all. we love memory-hard.
(07:31:47 PM) moneromooo: I dunno, it feels too early.
(07:33:18 PM) moneromooo: Can you expand a bit about "io-hard" btw ? What kinda of I/O exactly do you think is needed ?
(07:33:33 PM) linzhi-sonia: moneromooo: you mention "a party" a lot, "a party" gaining >50%. how can you identify what is a party?
(07:33:41 PM) tevador: linzhi-sonia: I didn't mean to sound hostile, it was just my interpretation of your silence
(07:34:00 PM) linzhi-sonia: all good, this is the best, friendliest, most problem-solving group anywhere
(07:34:07 PM) linzhi-sonia: if anything I worry because I cannot contribute much/anything
(07:34:10 PM) moneromooo: By "a party" I mean a person or set of persons with a coordinator.
(07:34:13 PM) linzhi-sonia: silence = less noise :)
(07:34:24 PM) linzhi-sonia: moneromooo: in the context of PoW, how do you identify them?
(07:34:36 PM) linzhi-sonia: you mean a chipmaker? or a large miner? a pool?
(07:34:48 PM) moneromooo: I do not use the term in in a PoW specific concept.
(07:34:53 PM) moneromooo: Those would be, yes.
(07:34:54 PM) linzhi-sonia: can you tell the difference between a large miner that hosts machines for others, or one that owns all their machines?
(07:35:11 PM) linzhi-sonia: ah ok
(07:35:19 PM) linzhi-sonia: you want <50% for anyone anywhere
(07:35:22 PM) moneromooo: Both would be parties here, in my usage:
(07:35:32 PM) tevador: linzhi-sonia: how about a paid review?
(07:35:34 PM) moneromooo: - a large miner can decide to switch all miners at once -> one party
(07:35:50 PM) moneromooo: - one that owns can direct the hoster to swiutch at once -> one party
(07:35:53 PM) linzhi-sonia: ah, so hard. It's not about money. What kind of feedback do you want?
(07:36:00 PM) linzhi-sonia: Do you have a list of questions somewhere?
(07:36:31 PM) needmoney90: I believe it centers around how many people it would take to subvert the network
(07:37:05 PM) needmoney90: one 51% hashpower mining pool, even if it was comprised of 100 equally distributed unrelated miners, would be dangerous
(07:37:24 PM) needmoney90: one center colocating the hashrate of a bunch of people as a business having 51% is also dangerous
(07:37:28 PM) needmoney90: both have a single point of failure
(07:37:36 PM) moneromooo: I use party in the sense of "how much hash rate do I have potential control over". ie, if one single person decides to change to double spend monero, what's hte total hash rate they can command for it.
(07:38:20 PM) moneromooo: The commandeering here may or may not be "legal" in this case.
(07:39:12 PM) tevador: linzhi-sonia: for example if this is an accurate estimate: https://github.com/tevador/RandomX/issues/31[1]
(07:43:40 PM) linzhi-sonia: tevador: OK! that looks interesting, very detailed. Please give me 1 day or so then I can tell you whether I have something interesting to say about that, or not.
(07:43:59 PM) linzhi-sonia: this is not really on-topic, because you are already ahead, but we write this post a few weeks ago: https://medium.com/@Linzhi/studying-the-feasibility-of-an-asic-82634ac77d61[1]
(07:44:18 PM) linzhi-sonia: it's more high-level though, you are already much further, which is great
(07:45:32 PM) linzhi-sonia: moneromooo: needmoney90 OK great, understand now about meaning of "party", and it makes sense. The concept is not purely mathematical, it's more real-life. Looking at all the real parts of the network.
(07:46:06 PM) linzhi-sonia: In that case 50% sounds far too high! The goal should be, eventually, for no party to control more then 10%, even less
(07:46:24 PM) needmoney90: Perhaps one day, but that may be infeasible with pools
(07:46:32 PM) needmoney90: people want low variance in payouts
(07:46:39 PM) linzhi-sonia: yes!
(07:46:59 PM) linzhi-sonia: the variance together with 10-min blocks is what keeps the number of viable pools in the 10-20 range
(07:47:23 PM) linzhi-sonia: Monero has 2-min blocks, that's better, but the variance problem remains
(07:47:37 PM) linzhi-sonia: and i guess you cannot make a "variance free" algo, it's impossible
(07:47:49 PM) linzhi-sonia: or maybe some software could redistribute the rewards?
(07:47:49 PM) needmoney90: I suspect a pool existing with 20-30% of the hashrate is unavoidable
(07:48:10 PM) needmoney90: its up to the miners to self-distribute if it gets too big
(07:48:13 PM) linzhi-sonia: the variance is a big issue, we know that first-hand from btc
(07:49:13 PM) linzhi-sonia: well. many problems to solve, cannot solve them all at once.
(07:52:27 PM) linzhi-sonia: ok gotta run. two homework items for me: explain io-hard for moneromoo, and randomx issue 31 for tevador. will be back! this is a happy group here which is great.
(07:52:50 PM) moneromooo: See ya :)
(08:13:39 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(08:39:12 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(09:21:47 PM) rottensox left the room (quit: Read error: Connection reset by peer).
(09:30:28 PM) LSDog left the room (quit: Ping timeout: 255 seconds).
(09:31:50 PM) hyc: linzhi has talked about I/O hard before. meaning to use the interfaces on the chip to talk to something else.
(09:32:05 PM) hyc: which AFAICS can't really be done since we don't know what peripherals are available
(09:32:58 PM) hyc: As another spin, AMD is pushing their HSA concept, CPU+GPU working in tandem, with OS scheduling threads to each dynamically
(09:33:29 PM) hyc: it would be "cool" to come up with an algorithm that has portions of both CPU-centric and GPU-centric work
(09:33:55 PM) hyc: but I think the HSA software ecosystem still isn't mature enough to make that work very smoothly
(09:34:05 PM) hyc: (Could be wrong about that, haven't kept up with it)
(09:34:48 PM) hyc: This Chris Ziomkowski sure likes to talk, about Caltech, MIT, JPL ...
(09:35:42 PM) hyc: his mention of in-memory computing is interesting though. This was the concept HP was going after with their memristors
(09:36:18 PM) hyc: and it definitely makes a lot of sense. since code is typically much smaller than the dataset being operated on, it makes more sense to move the code to where the data resides,
(09:36:21 PM) hyc: than vice versa
(09:36:51 PM) hyc: it's a well established principle in distributed computing already. I've designed quite a few systems that work this way
(09:37:37 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:38:56 PM) hyc: his discussion about getting away from shared memory bus architecture looks like a distraction though
(09:39:46 PM) hyc: there are very few real world embarrassingly parallel workloads out there, and those are the only kind that lend themselves well to massively partitioned tiny work cells
(09:40:14 PM) hyc: and when you massively partition like that, you blow your power budget in communication networks instead
(09:41:08 PM) hyc: for his point about running at threshold voltage and tolerating a small % of errors, tevador has already commented on the cascading effect of tiny computational errors in randomX. it wouldn't be pretty.
(09:42:09 PM) hyc: anyway, he only claims that his XTend Online Hyperminer will be better than GPUs, he doesn't claim that it will beat mining ASICs.
(09:42:33 PM) hyc: that's probably a reasonable claim
(09:42:52 PM) hyc: but I don't think that will make it any better at RandomX. the compute errors will kill that.
(09:57:03 PM) kopite7 left the room (quit: Quit: Leaving.).
(09:57:17 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(10:45:33 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(10:53:13 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(11:14:24 PM) rottensox left the room (quit: Remote host closed the connection).
(11:14:50 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:15:22 PM) rottensox left the room (quit: Max SendQ exceeded).
(11:54:47 PM) rottensox_ [~rottensox@unaffiliated/rottensox] entered the room.
(11:55:23 PM) rottensox_ is now known as rottensox
(12:38:50 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(12:58:24 AM) rottensox left the room (quit: Remote host closed the connection).
(02:08:57 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:22:36 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:33:18 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:01:18 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(03:10:48 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:47:41 AM) sech1 left the room (quit: Quit: Leaving).
(04:06:33 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:24:01 AM) midipoet [uid316937@gateway/web/irccloud.com/x-hqbblpiwzgxuvjmx] entered the room.
(05:05:47 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:13:56 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(07:27:47 AM) tromp [~tromp@ip-217-103-3-94.ip.prioritytelecom.net] entered the room.
(07:37:57 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(07:56:27 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(08:02:16 AM) linzhi-sonia: moneromooo: hyc yes, I think we want to walk back on the "io-hard" a little. It's not a good term. We are already not really sure about "memory-hard" and we shouldn't make fun of things. I will retire this term.
(08:02:35 AM) linzhi-sonia: we do think that including blockchain data in the PoW might be an interesting direction, but it creates a verification problem
(08:03:00 AM) linzhi-sonia: tevador: here is something more valuable - our feedback for the design proposed in issue 31:
(08:03:03 AM) linzhi-sonia: https://github.com/tevador/RandomX/issues/31#issuecomment-476594599[1]
(08:07:01 AM) linzhi-sonia: hope it helps, we are really happy to provide feedback of this nature, but we cannot do a deep back-and-forth because that's just too time consuming. eventually we are designing a chip together :)
(08:07:37 AM) hyc: thanks for that feedback. yes, I've already noted that.
(08:07:48 AM) hyc: asking for a simple audit probably isn't going to convince anyone
(08:08:00 AM) hyc: we would have to walk through a complete design
(08:08:44 AM) linzhi-sonia: tevador sounds really eager and ambitious to learn, maybe some of our feedback is helpful for him. we believe in learning and getting stronger.
(08:08:44 AM) hyc: not all the way to production, but complete enough to run simulations so we can see power use
(08:08:44 AM) LSDog left the room (quit: Ping timeout: 246 seconds).
(08:09:27 AM) linzhi-sonia: chipmakers make as many mistakes as software devs. many times our thoughts don't work out in reality... :)
(08:09:58 AM) linzhi-sonia: I keep saying: our biggest risk is chip failure, never forking risk or those things.
(08:10:21 AM) hyc: the devil's in the details. you can't estimate just from isolated components, you have to see how everything fits together
(08:10:27 AM) linzhi-sonia: yes
(08:12:11 AM) linzhi-sonia: I can repeat: I find this discussion atmosphere here very relaxing and productive. If we would do this kind of feedback about progpow, dozens of aggressive accounts would attack us in many ways.
(08:12:42 AM) hyc: I've pointed out before that randomX may be too simple, and a simple statemachine could handle it
(08:13:08 AM) hyc: but by now we have to balance complexity against auditability
(08:14:50 AM) hyc: we're only here to attack weaknesses in the design ;)
(08:15:10 AM) linzhi-sonia: of course! if you spot something wrong in my reply, please let me know
(08:16:43 AM) hyc: your reply has some useful info but is still talking about things in isolation. yes, it is possible for "some generic ASIC" to operate at 3 GHz. It is unlikely that a randomX ASIC could do so. heat would be a problem.
(08:16:59 AM) kico left the room (quit: Remote host closed the connection).
(08:16:59 AM) hyc: end-to-end timing would be a problem
(08:17:02 AM) hyc: etc...
(08:17:22 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(08:18:54 AM) linzhi-sonia: I pointed to the medium post yesterday, right? that's our, rough, normal process, how to move from isolated things to entire design.
(08:19:17 AM) hyc: yes...
(08:19:46 AM) hyc: I would think a lot of those factors already have common default choices in the industry
(08:19:52 AM) hyc: operating temperature range
(08:19:59 AM) hyc: etc
(08:20:22 AM) linzhi-sonia: we are planning to write something about the history of BTC asics, but it's a lot of work
(08:21:18 AM) linzhi-sonia: I'll talk about it if/when we finally release something.
(08:22:19 AM) linzhi-sonia: we started with 8000 W/T, now it's ca. 40 W/T
(08:22:32 AM) hyc: "Optimization target" for a miner this should be easy - high throughput, low power, low cost
(08:25:28 AM) moneromooo: Choose any two.
(08:27:17 AM) hyc: by "easy" I meant that all miners probably target these 3
(08:27:33 AM) hyc: you might be able to juggle priority between them a little bit
(08:28:21 AM) hyc: and higher up front cost could be accepted if the mining rewards ROI fast enough
(08:29:55 AM) hyc: curious though - assuming you've got a chip design agreed on, who designs and builds the motherboard?
(08:36:06 AM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(08:39:19 AM) linzhi-sonia: I think in many cases the chipdesigner will just do that as well. We need a bunch of boards for chip bringup and testing anyway.
(08:39:46 AM) linzhi-sonia: sometimes later in volume production there may be a reference design and multiple boardmakers
(08:40:34 AM) linzhi-sonia: the problem with reference designs is always the quality of the partner, just for economic reasons. a chipmaker needs to find a board partner with equally long-term investment horizon, enough margin, etc.
(08:40:46 AM) linzhi-sonia: otherwise you have 5 board partners but the boards destroy the chip
(08:41:04 AM) linzhi-sonia: first step: chipmaker makes the whole thing
(08:41:51 AM) sech1: linzhi-sonia were you talking about pipelining only AES or the whole RandomX in your github post?
(08:43:30 AM) linzhi-sonia: sech1: both. aes and whole randomx
(08:44:07 AM) sech1: randomx pipeline would be huge. It's 256 instructions and you still need to handle branches somehow.
(08:45:40 AM) sech1: branches don't overlap currently, so theoretically they could be handled by repeating instructions and predicating them, but this effectively doubles pipeline length
(08:48:57 AM) testing12345 [55d452c5@gateway/web/freenode/ip.85.212.82.197] entered the room.
(08:49:07 AM) testing12345 left the room (quit: Client Quit).
(08:50:21 AM) eatingnow [daff8a1a@gateway/web/freenode/ip.218.255.138.26] entered the room.
(08:54:21 AM) linzhi-sonia: instruction only means selecting different mux port on the pipeline
(08:54:32 AM) linzhi-sonia: a ROM based state machine can easily decode those
(08:55:51 AM) sech1: No one here told that it's impossible or hard to decode instructions
(08:57:47 AM) sech1: I just don't think that 256-stage pipeline is feasible. Such chip would need all instructions at every stage of pipeline and pass 8*64+12*128=2048 bits of registers through it
(08:58:00 AM) sech1: Plus scratchpad accesses and branches possible at every stage
(08:58:30 AM) sech1: It would be a waste of silicon, too large area
(09:00:45 AM) eatingnow left the room (quit: Ping timeout: 256 seconds).
(09:05:14 AM) linzhi-sonia: a bitcoin hash core has 128-stage pipeline (2x64 round SHA256) and 768 bit register per stage. one chip has hundreds such pipelines.
(09:07:23 AM) eatingnow [1b7a0d99@gateway/web/freenode/ip.27.122.13.153] entered the room.
(09:09:47 AM) sech1: A bitcoin hash core doesn't need to do 64-bit FP operations, including complex ones like DIV and SQRT
(09:09:59 AM) sech1: And it doesn't have to access 2 MB scratchpad and 2 GB dataset
(09:10:12 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:10:49 AM) sech1: Pipelining is a form of parallelization, so it will also require proportionally more memory for scratchpads
(09:10:58 AM) sech1: 256-stage pipeline = 512 MB for scratchpads
(09:14:38 AM) sech1: and branches destroy pipelining anyway
(10:35:19 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(10:35:27 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(10:39:50 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(10:46:19 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(10:46:31 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(11:00:30 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:01:25 AM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(11:23:10 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:37:31 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(11:44:33 AM) sech1 left the room (quit: Quit: Leaving).
(12:01:09 PM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(12:03:37 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:36:52 PM) dEBRUYNE: sech1: You online?
(12:37:02 PM) sech1: yes
(12:38:44 PM) dEBRUYNE: will you be working on a GPU mining implementation once RandomX "code freezes"?
(12:39:01 PM) sech1: yes, I can do CUDA version
(12:39:22 PM) sech1: AMD version will require GCN assembly level magic, it's a new area to me
(12:40:06 PM) dEBRUYNE: All right, thanks for the information
(12:40:12 PM) dEBRUYNE: That should provide us some more concrete numbers then on advantages
(12:41:25 PM) sech1: I'm pretty certain I can do CUDA version, and at least I can try to do AMD GCN assembly version
(12:43:28 PM) dEBRUYNE: You currently estimate the advantage at about 2:1 right?
(12:43:29 PM) dEBRUYNE: For cpus
(12:44:51 PM) sech1: It wasn't my estimate
(12:45:05 PM) sech1: and it was for AMD Vega
(12:45:16 PM) sech1: It can be totally different for NVIDIA - maybe better, maybe worse
(12:46:45 PM) dEBRUYNE: Hmm, I vaguely remember hyc stating you estimated that :P
(12:47:18 PM) hyc: no
(12:47:25 PM) sech1: https://github.com/tevador/RandomX/issues/24[1]
(12:47:25 PM) hyc: the estimate comes from issue #24
(12:47:32 PM) hyc: ^^
(12:47:32 PM) sech1: it was @enerc
(12:47:54 PM) hyc: and no one has heard from him since ;)
(12:57:24 PM) dEBRUYNE: Thanks, I stand corrected :-P
(01:01:36 PM) crCr62U0: Can someone share logs of the last 24hours? 
(01:01:56 PM) sech1: http://highlandsun.com/hyc/monero-pow.txt[1]
(01:02:10 PM) crCr62U0: thx
(01:02:42 PM) crCr62U0: It's exactly what i need.
(01:03:36 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(01:05:34 PM) spaced0ut left the room (quit: Ping timeout: 255 seconds).
(01:07:15 PM) sech1 left the room (quit: Quit: Leaving).
(01:07:51 PM) Masoch_Von_Sade [~Masoch@187.64.171.76] entered the room.
(01:37:56 PM) midipoet [uid316937@gateway/web/irccloud.com/x-xxdpbifjnnnyhmxe] entered the room.
(01:47:39 PM) rottensox is now known as pedrottensox
(01:47:46 PM) fort3hlulz left the room (quit: Quit: Leaving).
(01:50:21 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(01:55:42 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(02:31:21 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1008::31a] entered the room.
(02:36:46 PM) pedrottensox is now known as rottensox
(03:30:42 PM) dEBRUYNE left the room ("Leaving").
(03:32:19 PM) rottensox left the room (quit: Quit: Leaving).
(03:34:24 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(04:01:05 PM) rottensox left the room (quit: Quit: Leaving).
(04:18:46 PM) fort3hlulz_ left the room (quit: Ping timeout: 268 seconds).
(04:23:02 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1008::31a] entered the room.
(04:36:01 PM) fort3hlulz_ left the room (quit: Ping timeout: 250 seconds).
(04:54:44 PM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(05:35:13 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:30:33 PM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(06:31:29 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(07:30:25 PM) tromp left the room (quit: Remote host closed the connection).
(08:19:15 PM) gethh [uid264798@gateway/web/irccloud.com/x-bpaspmyvsduuitao] entered the room.
(09:53:38 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:57:34 PM) OsrsNeedsF2P: Noob question about RandomX: The overview says each RandomX loop is repeated 2048 times. Doesn't dedicated hardware have an advantage by unraveling the loops on the circuit, or using some forms of lookahead?
(11:22:10 PM) jwinterm left the room (quit: Remote host closed the connection).
(11:23:05 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:04:35 AM) Trick14 left the room (quit: Read error: Connection reset by peer).
(12:07:19 AM) Trick14 [~dabooz@d54C0FA5E.access.telenet.be] entered the room.
(01:14:34 AM) ArticMine left the room (quit: Ping timeout: 255 seconds).
(01:28:15 AM) ArticMine [~ArticMine@S0106ac202ecaeb73.vn.shawcable.net] entered the room.
(02:17:00 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:21:26 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:49:42 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 272 seconds).
(03:57:24 AM) sech1 left the room (quit: Quit: Leaving).
(04:15:51 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:16:12 AM) midipoet [uid316937@gateway/web/irccloud.com/x-brwwzhezidipphpy] entered the room.
(04:25:14 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(06:37:32 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:44:35 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(06:52:56 AM) hyc: OsrsNeedsF2P: unrolling a loop 2048 times would eat up a ton of chip area
(06:53:17 AM) hyc: lookahead will eat power
(06:54:29 AM) hyc: loop unrolling is only a benefit if the loop is short, and checking the loop termination condition is expensive
(06:54:59 AM) hyc: the loop body here is large, and checking the end condition is insignificant in comparsion
(07:40:28 AM) rottensox left the room (quit: Ping timeout: 250 seconds).
(07:57:42 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(08:07:33 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(08:17:55 AM) kico left the room (quit: Remote host closed the connection).
(08:18:13 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(08:44:02 AM) spaced0ut left the room (quit: Ping timeout: 250 seconds).
(08:56:07 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:00:03 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(11:00:46 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:34:12 AM) antanst12 [~antanst@62.169.219.213] entered the room.
(11:34:13 AM) antanst1 left the room (quit: Ping timeout: 245 seconds).
(11:57:30 AM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(11:59:46 AM) fort3hlulz left the room (quit: Client Quit).
(12:11:20 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1002::d5] entered the room.
(12:12:28 PM) wowario left the room (quit: Remote host closed the connection).
(12:12:56 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(12:19:34 PM) sech1 left the room (quit: Quit: Leaving).
(12:30:17 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:39:54 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(12:44:42 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(12:51:07 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:22:56 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:46:45 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(01:51:27 PM) sech1: An interesting thought occurred to me: RandomX incorporates everything from all versions of Cryptonight + adds more ASIC killer features
(01:51:33 PM) sech1: 2 MB scratchpad from CNv0 - check
(01:51:51 PM) sech1: 64 byte access width, DIV+SQRT from CNv2 - check
(01:51:57 PM) sech1: Random code from CN/R - check
(01:53:26 PM) sech1: plus 2 GB dataset, random code changing 8 times per nonce, more accesses to scratchpad, higher precision for DIV/SQRT
(01:53:29 PM) sech1: and branches
(01:54:44 PM) hyc: which leads you to what conclusion?
(01:54:58 PM) sech1: it will be a hard nut to crack for ASICs
(01:55:34 PM) hyc: heh
(01:55:50 PM) hyc: at this point, I don't think we can expect any useful information from any ASIC developer.
(01:56:09 PM) hyc: either they know they can beat the efficiency gap, in which case htey will silently build them
(01:56:21 PM) hyc: or they know they can't, in which case they just keep their mouth shut
(02:01:59 PM) hyc: ... one other possibility is they still don't know, haven't spent enough time studying it yet
(02:22:23 PM) sech1: Considering that CNv2 ASICs were only 20x more power efficient I think CN/R ASICs won't be more than 10x and RandomX ASICs will be much closer to our 2x goal
(02:25:04 PM) hyc: how do we know 20x? also I think we need to refine our target a bit. it has to account ROI, not just power efficiency. i.e., initial cost is also a factor.
(02:25:19 PM) hyc: in fact it was probably the overriding factor for a 6-month fork schedule
(02:26:23 PM) hyc: for randomX I would assume it must net profit within 18 months. 
(02:26:56 PM) hyc: that's roughly the lifetime before a new generation design can beat the existing designs
(02:27:16 PM) hyc: based on Moore's Law (which of course is already dead) i.e., transistor density doubling every 18 months
(02:29:45 PM) sech1: CNv2 ASICs were 128 KH/s @ 670 watts
(02:30:50 PM) sech1: not 100% reliable data (from anon tip), but it's the best we have
(02:46:43 PM) hyc: was that also Innosilicon, or no info?
(02:51:37 PM) sech1: No reliable info
(02:53:52 PM) LSDog left the room (quit: Ping timeout: 244 seconds).
(02:54:57 PM) Isthmus_ left the room (quit: Quit: Updating details, brb).
(02:55:21 PM) Isthmus [sid302307@gateway/web/irccloud.com/x-mevantlxtgbhlzak] entered the room.
(03:06:37 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(03:10:31 PM) needmoney90: hyc we're currently spitting out $112k/day
(03:11:04 PM) needmoney90: 3xmr/block, 30 blocks an hour, 24 hours a day, ~$50/xmr = 108k
(03:11:36 PM) needmoney90: for a million dollars R&D+fab, if you snag 50% of the hashrate, you can ROI (electricity costs ignored) in 20 days
(03:12:13 PM) needmoney90: If its a 2-month period from fork to fabrication, that means 3 months before ROI from initial outlay (assuming outlay is paid as a lump sum initially)
(03:12:51 PM) hyc: ok
(03:13:20 PM) hyc: I'm assuming CNV0-CNV2 had minimal design costs since it was still CN overall
(03:13:36 PM) hyc: but $1M is too cheap for 1st version of RandomX miner
(03:16:08 PM) hyc: https://www.quora.com/How-much-does-it-cost-to-tapeout-a-28-nm-14-nm-and-10-nm-chip
(03:16:17 PM) hyc: $2-3M for tapeout on 16nm
(03:17:38 PM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(03:20:15 PM) needmoney90: what about 65nm?
(03:20:20 PM) needmoney90: some old process
(03:20:42 PM) needmoney90: lets discuss on air
(03:20:43 PM) needmoney90: actually
(03:21:13 PM) hyc: old process that large will suck power down
(03:21:57 PM) hyc: typically 50% power reduction with each new node, so from 65nm to 7nm will be at least 8x power diff
(03:22:41 PM) hyc: it would be pointless. 22nm is probably the oldest that would be viable today, 16nm is probably most common for ASICs
(03:23:09 PM) hyc: bitmain has advertised 7nm ASICs, afaik they're the only ASIC maker to do so. 7nm is still expensive and exclusive, larger customers get priority
(03:23:59 PM) hyc: AMD's own 7nm chips have only become available this year, with desktop chips not even released yet
(03:24:35 PM) hyc: Intel still on 14nm since their 10nm line failed miserably
(03:25:20 PM) needmoney90: is 7nm marketing?
(03:25:35 PM) hyc: meaning not real?
(03:25:36 PM) needmoney90: I've heard stuff about it just being numbers and not representative of actual process size
(03:25:49 PM) hyc: people say TSMC 7nm is equivalent to Intel 10nm
(03:26:01 PM) hyc: but fact is, TSMC 7nm works, Intel 10nm doesn't ...
(03:27:32 PM) sech1: everything below 65 nm is marketing and doesn't represent actual transistor sizes
(03:27:52 PM) sech1: they use metrics like density per mm^2 for nodes < 65 nm
(03:28:58 PM) hyc: true. certainly chip area no longer shrinks by half on each new node progression
(03:29:48 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(03:31:56 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(03:57:45 PM) hyc: process costs from 2016 https://anysilicon.com/semiconductor-wafer-mask-costs/
(03:57:54 PM) hyc: $1.5M on 28nm
(03:58:19 PM) hyc: can assume the curve continues its ramp for smaller processes
(03:58:47 PM) tevador: the guy from Obelisk quoted $5 million for mask at 16 nm
(03:59:14 PM) tevador: plus about a million for the physical design
(03:59:43 PM) hyc: seems to fit that curve, yeah
(03:59:43 PM) tevador: source: https://www.grin-forum.org/t/obelisk-grn1-chip-details/4571/18[1]
(04:27:12 PM) sech1: Which means 7 nm CPUs may even be on par with 16 nm ASICs due to better process node
(04:27:37 PM) sech1: And more efficient ASICs will have to use smaller nodes and thus have much longer ROI time
(04:38:40 PM) hyc: off-the-wall idea: implement AES in RandomX machine language
(04:40:55 PM) hyc: sech1: how/why did you get into working on the PoW?
(04:41:55 PM) sech1: I just happened to mine XMR during the first ASIC wave in 2018
(04:43:57 PM) kico: tevador, the sound on your mike is very low
(04:44:36 PM) hyc: except when he speaks 'p' plosives :P
(04:45:01 PM) kico: true lol
(05:04:25 PM) xcsd [45293c18@gateway/web/cgi-irc/kiwiirc.com/ip.69.41.60.24] entered the room.
(05:04:56 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(05:05:13 PM) xcsd: good interview guys :)
(05:06:02 PM) hyc: cool, glad you thought so
(05:07:16 PM) moneromooo: Probably my favourite quote from Yes, Minister.
(05:07:40 PM) hyc: which quote?
(05:08:54 PM) moneromooo: Sir Humphrey claims his job is to not answer MP's questions. Hacker (who was a PM) says with glee "Ah, but you answered mine!". Sir Humphrey laughs politely and says "Ah, I'm glad you thought so, minister".
(05:09:11 PM) Iasonm [4d0b3e7f@gateway/web/cgi-irc/kiwiirc.com/ip.77.11.62.127] entered the room.
(05:09:31 PM) hyc: lol
(05:10:45 PM) geonic: moneromooo: are you willing to continue to work on Monero with 6-month fork schedule?
(05:11:09 PM) moneromooo: I have not decided yet. It will of course depend on whether someone wants to continue tweaking.
(05:11:22 PM) hyc: are you talking general fork or PoW fork?
(05:11:30 PM) moneromooo: I was assuming PoW.
(05:11:44 PM) hyc: there's talk of scaling back to 12 month general fork too
(05:12:07 PM) geonic: Any kind of fork. needmoney90 was unambiguous that there are no developers working on Monero currently who are willing to continue with a 6-month fork schedule. Wanted to see if that is true or not.
(05:12:17 PM) moneromooo: This is not true :)
(05:12:17 PM) needmoney90: I meant PoW fork*
(05:12:31 PM) needmoney90: network upgrades are different
(05:12:37 PM) geonic: needmoney90: can you adjust that talking point in the future?
(05:12:38 PM) needmoney90: the PoW tweaks were what I was referring to specifically
(05:12:39 PM) needmoney90: yeah
(05:12:40 PM) needmoney90: can do
(05:12:42 PM) needmoney90: my apologies
(05:13:11 PM) moneromooo: In fact, my preference is to tweak CNv4 and release that 5 months after the march fork date.
(05:13:21 PM) needmoney90: really?
(05:13:22 PM) needmoney90: hm
(05:13:27 PM) moneromooo: After that, likely randomx, and I guess we'll see how it works out.
(05:13:41 PM) needmoney90: I've been chatting with lots of people, and I haven't gotten any sense that people want 6-month PoW tweaks
(05:13:45 PM) needmoney90: developerwise
(05:13:54 PM) moneromooo: Unless there's widespread agreement random is ready in time for september/october. Scares me a bit though.
(05:14:03 PM) moneromooo: No they don't. I do.
(05:14:06 PM) needmoney90: Yeah, thats my feeling too. It needs audits and stuff.
(05:14:10 PM) moneromooo: Well, for now.
(05:14:29 PM) hyc: it's undeniable that continued poking and prodding at CN keeps magnifying the chance of a fatal fuckup
(05:14:32 PM) moneromooo: The question was "are you willing to continue", I took that to mean me, not people as a whole.
(05:14:36 PM) needmoney90: I've been saying its probably one more tweak and randomX, but randomX is like, our last shot
(05:14:58 PM) needmoney90: before this tweak schedule is untenable
(05:15:02 PM) needmoney90: unless you're feeling differently
(05:15:09 PM) geonic: Yes I was asking you personally. Last time I checked I think you contributed the most to the monero codebase out of anyone.
(05:15:11 PM) moneromooo: OK, I can agree with that, with the caveat that if something else pops up later with a good prima facie chance, I'd go for it.
(05:15:32 PM) moneromooo: Probably still second to Nicholas van Saberhagen :P
(05:15:37 PM) geonic: Haha
(05:15:41 PM) moneromooo: Wait. amjuarez.
(05:15:46 PM) moneromooo: If it's not the same person.
(05:15:50 PM) hyc: lol
(05:15:54 PM) needmoney90: Basically, its in opposition to the portion of the community who think constant 6-month tweaks are a sustainable fix
(05:16:16 PM) needmoney90: with no concept that they need to end, and that time is coming sooner rather than later
(05:16:29 PM) moneromooo: Well, I agree with the sustainability point. But I think the other side is likely worse.
(05:16:39 PM) hyc: frying pan, fire ?
(05:16:43 PM) moneromooo: Right.
(05:16:54 PM) geonic: It seems to me that those who are most strongly opposed to 6-month forks are the Reddit moderators, who unfortunately have to deal with support tickets coming from users who send funds on the wrong chain, notifying exchanges, other “ecosystem participants”, etc, etc.
(05:17:14 PM) hyc: wrong chain stuff happens with general fork anyway
(05:17:17 PM) needmoney90: so, actually, the reddit mods are gauging consensus
(05:17:25 PM) needmoney90: for the most part
(05:17:33 PM) geonic: Not with this last discussion.
(05:17:36 PM) needmoney90: we've been talking to the devs/exchange reps/wallet providers/etc
(05:17:39 PM) needmoney90: over the past month
(05:17:43 PM) geonic: Post some of those discussions.
(05:18:13 PM) needmoney90: Many were had in private, but I can chat with debruyne to see if people are willing to release the logs
(05:18:36 PM) geonic: Yeah do that. Otherwise you’re blamed for being the messenger.
(05:18:48 PM) needmoney90: I don't care what I'm blamed for, mods get shit no matter what we do
(05:19:04 PM) moneromooo: You did care about being blamed for the relays :P
(05:19:26 PM) needmoney90: I was more mad that if he had that attitude towards me, he would probably blow up and have that attitude towards many others
(05:19:28 PM) moneromooo: OK, in fairness, you did not say you don't care about being blamed, just what for.
(05:19:31 PM) needmoney90: which, in hindsight, was correct
(05:19:53 PM) needmoney90: anonimal was all about burning bridges
(05:20:21 PM) geonic: I think the Reddit moderators have been less objective than usual so far on this PoW discussion. I hope that improves.
(05:20:48 PM) needmoney90: Who's views are we not taking into account?
(05:21:10 PM) geonic: It is one thing to moderate. It is another to be the mouthpiece of a “community”.
(05:21:32 PM) hyc: there's plenty else of us being mouthpieces :P
(05:21:39 PM) needmoney90: I don't believe I've said anything misrepresentative, and I am a voice like any other
(05:21:47 PM) geonic: You did.
(05:22:01 PM) geonic: You repeatedly claimed there are no developers willing to work on a 6-month fork schedule.
(05:22:05 PM) geonic: That’s false.
(05:22:10 PM) needmoney90: sigh
(05:22:17 PM) geonic: sigh is rght. It doesn’t fix it.
(05:22:41 PM) needmoney90: The 6-month PoW cycle forever isn't even supported by mooo
(05:22:43 PM) moneromooo: Well, at least one more. After that we'll see.
(05:22:43 PM) hyc: 6-month pow forks can't go on forever
(05:22:50 PM) needmoney90: that isnt in contention man
(05:23:04 PM) geonic: Sorry if I’m coming off confrontational. But this discussion is being steered by you and dEBRUYNE towards a predetermined end.
(05:23:31 PM) needmoney90: we're kind of in the middle of all the discussions by necessity
(05:23:33 PM) hyc: ... what if hashrate still looks normal 6 months from now? do we let CN/R keep going for another 6 months?
(05:23:37 PM) geonic: Where did you get your SHA3 consensus information from? Who fed you that?
(05:23:39 PM) needmoney90: I wouldnt be opposed, hyc
(05:23:51 PM) moneromooo: In fact, my preference used to be "keep 6 months, but be ready at 4, and as soon as evidence of hash rate wonkiness, release".
(05:24:07 PM) needmoney90: fed me?
(05:24:09 PM) geonic: I’d love to see those private chat logs.
(05:24:14 PM) hyc: ^ that would be nice moneromooo
(05:24:19 PM) moneromooo: Which could easily be changed to... aim for 8 months, but be ready at 4.
(05:24:20 PM) hyc: don't think "ready at 4" has worked so far
(05:24:33 PM) moneromooo: That's because we did not aim at being ready at 4.
(05:24:45 PM) hyc: ok
(05:24:58 PM) moneromooo: < hyc> ... what if hashrate still looks normal 6 months from now? do we let CN/R keep going for another 6 months?
(05:25:16 PM) moneromooo: What I'd do is fork 5 months after march with a CNv4 tweak first.
(05:25:23 PM) moneromooo: So august I think.
(05:25:38 PM) moneromooo: Others disagree.
(05:25:46 PM) needmoney90: geonic: I think your insinuations are pretty insulting tbh
(05:25:50 PM) geonic: Didn’t you just say that all the information you are relaying is coming from “other developers/exchanges/etc”?
(05:26:00 PM) hyc: moneromooo: even if there's no evidence of ASICs?
(05:26:15 PM) moneromooo: I think so.
(05:26:18 PM) needmoney90: geonic: I'll look into what I can release. I can't promise more than that.
(05:26:34 PM) hyc: ok. I guess we did CNv1 -> CNv2 without hashrate spike
(05:26:39 PM) moneromooo: Yes. Took 3 months between first evidence and fork.
(05:27:00 PM) moneromooo: First evidence is typically ambiguous.
(05:27:12 PM) hyc: true
(05:28:22 PM) moneromooo: 5 months after august is january -> randomx then.
(05:28:29 PM) geonic: needmoney90: thanks. It’s just a little painful to watch this Monero Talk interview not knowing who your sources are. I appreciate your contributions.
(05:28:47 PM) needmoney90: The nature of moderation is really complicated.
(05:28:50 PM) moneromooo: And then, assuming the CPU/ASIC gap is really diminished, we can safely move to 8 months or more.
(05:29:07 PM) needmoney90: A lot of discussions I have are often done with implicit confidence that they aren't released
(05:29:29 PM) needmoney90: Its not as easy as just copy-pasting logs, unfortunately. I wish it was.
(05:29:45 PM) geonic: How is the community supposed to weigh that information though?
(05:29:49 PM) hyc: moneromooo: not sure anyone is going to like these changing schedules. one point about 6 month was that you could expect them in the same month every year
(05:29:51 PM) moneromooo: FWIW, I support the right to have private conversations. If you don't want to trust someone without proof, then don't trust.
(05:29:58 PM) hyc: even though that hasn't really worked out either
(05:30:16 PM) moneromooo: Turns out nobody really expects them. The mailing list announce is better than a fixed schedule for this.
(05:30:26 PM) needmoney90: geonic: However they want to weight it. You'll notice I haven't flaired any of my comments relating to this discussion with mod flair, its all been done as my own voice
(05:30:35 PM) needmoney90: or stickied any comments saying this is reality
(05:30:39 PM) needmoney90: or stickied any posts with an agenda
(05:30:49 PM) hyc: ok, I guess the mailing list is more explicit anyway
(05:30:53 PM) needmoney90: im not really sure how you expect me to improve on this situation, but I really would like to if possible
(05:31:20 PM) geonic: Let both sides talk it out and moderate, instead of tipping the scales of the discussion?
(05:31:29 PM) needmoney90: should I be using an alt account that doesn't have any association with my main to voice opinions? Would that not provoke its own questions/issues?
(05:31:36 PM) needmoney90: Am I not allowed to have a voice myself?
(05:31:37 PM) hyc: who are both sides here geonic?
(05:32:14 PM) needmoney90: Should I just sit silent when I deal with support requests/concerns/issues literally all day every day about this stuff?
(05:32:17 PM) geonic: hyc: those who are for ASIC-resistance and those who are against
(05:32:32 PM) hyc: everybody is for ASIC-resistance
(05:32:46 PM) geonic: needmoney90: I’m sorry you decided to take on the mantle of moderator. But it requires objectivity.
(05:32:51 PM) moneromooo: No. At least stoffu thinks it's best to stop now.
(05:32:54 PM) hyc: but some people have weaker conviction than others
(05:33:04 PM) needmoney90: I *am* being objective.
(05:33:12 PM) needmoney90: I think I'm representing both sides fairly
(05:33:13 PM) moneromooo: (well, doing it for aeon)
(05:34:48 PM) hyc: stoffu hasn't offered any actual technical arguments for his position
(05:34:55 PM) geonic: <needmoney90> Yeah, If RandomX pans out I'm all in, but I'm being realistic that this is basically our last shot
(05:34:55 PM) geonic: <needmoney90> and the community needs to realize that
(05:35:05 PM) needmoney90: mhm?
(05:35:13 PM) needmoney90: Is that in contention?
(05:35:18 PM) xcsd: idk how seriously ASIC supporters should be taken considering they do not give good arguments as to why they support ASIC
(05:35:23 PM) geonic: Is that an observable fact?
(05:35:32 PM) needmoney90: ....yes?
(05:35:40 PM) geonic: Can you see the future?
(05:35:45 PM) needmoney90: :/
(05:35:56 PM) needmoney90: im done with this conversation, you're not really arguing in good faith here
(05:36:44 PM) hyc: geonic: I think there's a genuine concern that 2 years from now (or whenever) the community will be too big to organize these forks
(05:37:08 PM) hyc: so carving commitments in stone today is an attempt to head off massive conflict down the road
(05:37:22 PM) moneromooo: I kinda agree with geonic. Before hyc and tevador had this random program idea, we thought the tweaks were the last shot, did we not ? Then this came out.
(05:37:41 PM) xcsd: i think geonic is trying to argue that we can not really know if nothing else can be done and thus embracing ASIC as a solution is just a fast way to failure.
(05:37:44 PM) moneromooo: So maybe someone will have a eureka moment in good time :) Sure, it's not very likely.
(05:37:49 PM) hyc: I started talking about randprog *before* we release CNV1
(05:38:25 PM) moneromooo: OK, the point still stands that progress progresses.
(05:38:27 PM) hyc: at least in my mind, it was clear when CNv1 was being developed that we needed a long-term algo, not just endless tweaks
(05:38:48 PM) hyc: if I failed to communicate that to the rest of the dev community at that time, mea culpa
(05:39:40 PM) xcsd: long-term updatable algo :) As nothing is perfect
(05:39:47 PM) geonic: ^^
(05:40:57 PM) hyc: (but I'm pretty sure I stated that in dev meetings at the time)
(05:41:29 PM) moneromooo: Could be. I'm not claiming otherwise. I just did not realize it was that old an idea :)
(05:41:31 PM) xcsd: fear not, RandomX will be the new algo to use for new coins, so it will be improved by many teams
(05:42:06 PM) moneromooo: I'm partial to randomx tweaks in the future, though of course maybe facts down the line will change my mind/.
(05:42:12 PM) hyc: the datestamp on my radprog PoC is a month or so before CNv1 release
(05:42:23 PM) hyc: and this writeup is right around that time https://www.reddit.com/r/Monero/comments/8bshrx/what_we_need_to_know_about_proof_of_work_pow/
(05:44:25 PM) hyc: randomX tweaks will be on the order of 8086 -> 80286. not small.
(05:44:57 PM) moneromooo: One argument (not claiming it's the strongest or weakest or anything) is that it is centralization of decision, even though (1) non PoW stuff is the same and (2) PoW changes are done by non core team and non me (sech1, tevador, vtnerd).
(05:45:03 PM) xcsd: As i noted in the future of pow github talk, the tweaks need to fix issues or close the gap between CPU and ASIC. I do not want the tweaks to brake ASIC
(05:45:43 PM) moneromooo: So possible fix for this: several people propose tweaks, the monero team shortlists, they're all added to the release, and voting by hash rate goes on.
(05:46:13 PM) moneromooo: Of course, if there are ASICs, they'll vote for the worst option, but shortlisting mostly fixes the damage they can do.
(05:47:01 PM) hyc: especially if they're the majority hash power that seems risky
(05:47:21 PM) moneromooo: Well, they can only choose one of the shortlist.
(05:47:25 PM) xcsd: the beauty of this algo in my opinion is that ASIC can coexist with normal miners as the gap will be small
(05:47:26 PM) hyc: ah
(05:48:07 PM) hyc: xcsd: of course, nothing is actually ASIC-proof. anyone sufficiently determined can always build custom hardware for any procedure.
(05:48:09 PM) moneromooo: The code for the other candidate tweaks can be removed next fork.
(05:48:58 PM) hyc: xcsd: but it may *appear* to be ASIC-proof because the efficiency gap is small enough and economic incentive small enough at a point in time
(05:50:51 PM) hyc: AFAICS there will never be coexistence in practice. if they build an ASIC and it has no clear advantage, they won't bother mass producing it.
(05:51:14 PM) xcsd: that is also true
(05:51:14 PM) hyc: so the only reason you will see ASICs on the network is because they're far enough ahead to kill everything else.
(05:52:32 PM) xcsd: if by see you mean massive hash then yes
(05:52:46 PM) xcsd: but i am pretty sure they will test the wathers
(06:00:57 PM) xcsd: and regarding the change to RX, i think that we should give CN4 a fair shot and continue perfecting and auditing RX
(06:01:37 PM) xcsd: not sure if an CN4 update will be necesary unless RX is not done yet and the network is "attacked"
(06:02:04 PM) moneromooo: I think it is prudent to have a tweak.
(06:02:08 PM) hyc: yeah, I tend to think if the audits are done and randomX is ready we should just deploy it
(06:02:55 PM) needmoney90: but then the clock is ticking for asic development
(06:03:26 PM) hyc: the clock is ticking right now. the code is available for anyone to pull
(06:04:49 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(06:05:33 PM) xcsd left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
(06:11:20 PM) xcsd [45293c18@gateway/web/cgi-irc/kiwiirc.com/ip.69.41.60.24] entered the room.
(06:12:05 PM) xcsd: did i miss anything? :D
(06:13:00 PM) moneromooo: Yes, someone just left, with the same nick as you. An impersonator most likely.
(06:13:21 PM) xcsd: for sure :D
(06:13:22 PM) hyc: yeah, couldn't have been him, made too much sense.
(06:14:16 PM) moneromooo: Even the IP was the same. Pretty good schtick.
(06:14:30 PM) xcsd: oh my
(06:14:49 PM) moneromooo: Check your network card for virus I guess.
(06:16:13 PM) xcsd: should i look inside the RJ45 hole?
(06:16:29 PM) moneromooo: If you wear a surgical mask. It might be APT virus.
(06:17:11 PM) xcsd: oh man, i`m all out of surgical masks :( i`l just burn it with fire
(06:19:27 PM) hyc: tevador: that GRN1 ASIC thread seems to have imploded https://www.grin-forum.org/t/obelisk-grn1-chip-details/4571/27
(06:19:40 PM) hyc: Obelisk accused of scamming its pre-order customers
(06:20:07 PM) xcsd: oh no, ASIC scammers?
(06:20:09 PM) moneromooo: Call it "upholding tradition".
(06:20:19 PM) hyc: lol
(06:20:44 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(06:21:48 PM) xcsd: lets see how many RandomX ASIC pre orders will popup :))
(06:24:04 PM) xcsd: see ya, i`m off to burn my RJ45 port.
(06:24:20 PM) xcsd left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
(06:24:24 PM) LSDog left the room (quit: Ping timeout: 250 seconds).
(06:32:18 PM) midipoet: people
(06:32:30 PM) midipoet: I just want to say
(06:32:48 PM) midipoet: this stuff is what dreams are made of
(06:33:46 PM) moneromooo: Delusion ?
(06:34:13 PM) midipoet: that's another step of meta moneromooo 
(06:34:30 PM) midipoet: why oh why oh why
(06:37:08 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(06:37:20 PM) midipoet: can you imagine the lingering regret we would all have if we didn't try RandomX? We all know it's a proxy for something larger. Would be good to have a concrete backup plan though...
(06:38:03 PM) hyc: I already proposed CRC32 as a backup. it's already accelerated in modern CPU instruction sets.
(06:38:06 PM) hyc:  /s
(06:46:30 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1002::d5] entered the room.
(06:48:52 PM) midipoet: I know I am in a pow channel asking this, so maybe it's a stupid question, but if you were to start "Monero" from new; blank slate. Would you pick PoW as the consensus mechanism?
(06:55:41 PM) Inge-: what viable alternatives are there?
(06:57:15 PM) midipoet: I guess that's the question I am asking. 
(06:58:52 PM) Inge-: I'm coming up short
(06:59:18 PM) midipoet: But I do wish we could secure the network without wasting electricity. 
(07:00:08 PM) midipoet: I remember a convo about NP superhard problems and protein folding; verification time being the issue. 
(07:00:47 PM) midipoet: Also some of the IO conversation snippets takes me down that road as well. 
(07:01:50 PM) Inge-: Proof of KYCAML
(07:01:58 PM) midipoet: Doesn't solve the problems at hand of courses, but maybe it frames the horizon a bit better. For me, at least. 
(07:04:13 PM) Iasonm left the room (quit: Ping timeout: 245 seconds).
(07:05:33 PM) hyc: yeah like gridcoin I suppose. verification is centralized
(07:05:38 PM) midipoet: I guess what I am trying to say, is that if one believes that PoW is necessary, then having a mechanism that one day ensure that "background" mining can be default for users (lending CPU cycles on their phone, TV, etc), then we should move towards that goal. As far as I can tell, that is what RandomX is doing. 
(07:06:09 PM) hyc: absolutely
(07:06:49 PM) hyc: though I think needmoney made a good point, it's most realistic to expect that only heaters will do background mining
(07:09:15 PM) hyc: wasn't there a company selling BTC-mining heaters?
(07:09:23 PM) midipoet: Yes
(07:09:30 PM) midipoet: Hang on
(07:10:28 PM) midipoet: https://www.qarnot.com/computing-heater_qh-1/[1]
(07:11:32 PM) ErCiccione[m] [erciccione@gateway/shell/matrix.org/x-kqlwsaportpbrhcd] entered the room.
(07:11:43 PM) hyc: nice. we were going to build one for monero, a year or two ago
(07:12:00 PM) midipoet: They are €3000
(07:12:04 PM) midipoet: I enquired. 
(07:12:16 PM) hyc: this is new, powered by AMD RYzen 7
(07:12:25 PM) midipoet: Wasn't convinced....but in theory it should work
(07:12:52 PM) midipoet: Yes, they only ramped up to production in 2018
(07:12:55 PM) hyc: right. 0 dB noise level - that's cute, it means no fans, all the heat is channeled thru heat sinks and radiated away
(07:12:56 PM) midipoet: Afaiu
(07:13:43 PM) hyc: co-funded by EU, sweet deal
(07:15:12 PM) midipoet: do you think though, hyc, that in the future, with the advent of augmented and virtual reality, that there may be more spare GPU cycles around the place?
(07:15:32 PM) midipoet: As apposed to CPU cycles?
(07:15:52 PM) hyc: mmmm. unlikely
(07:16:19 PM) hyc: if you assume that most computing devices will be mobile, and look at modern smartphone handsets
(07:16:44 PM) hyc: you can only stick one GPU in them, not multiple. these GPUs are quite limited, compared to desktop models.
(07:17:06 PM) midipoet: I assume they will become embedded. In everything, creating an augmented layer on the world - 24h
(07:17:17 PM) hyc: companies are putting AI coprocessors and VR coprocessors into their phone chips now
(07:17:21 PM) hyc: which are not GPUs
(07:17:30 PM) midipoet: Embedded in me even, creating an augmented digital layer over my skin. 
(07:18:01 PM) hyc: like Huawei phone chips https://en.wikichip.org/wiki/hisilicon/kirin/970
(07:18:20 PM) hyc: https://en.wikichip.org/wiki/hisilicon/kirin/980
(07:19:16 PM) hyc: chips embedded in people - running on what, bioenergy?
(07:19:27 PM) hyc: not enough power for a high perf GPU
(07:57:36 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(08:23:07 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(08:27:11 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(09:00:35 PM) minthos [~minthos@85.10.205.19] entered the room.
(09:26:19 PM) wowario left the room (quit: Ping timeout: 256 seconds).
(09:34:27 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(09:46:31 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1002::d5] entered the room.
(09:55:50 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:48:48 PM) ArticMine left the room (quit: Ping timeout: 245 seconds).
(10:48:49 PM) oneiric_: bioenergy + 10 pacemaker batteries ;p
(10:56:36 PM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(11:05:27 PM) ArticMine left the room (quit: Ping timeout: 245 seconds).
(11:18:57 PM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(11:23:19 PM) ArticMine left the room (quit: Ping timeout: 246 seconds).
(11:34:02 PM) smooth [~ubuntu@ec2-54-201-223-245.us-west-2.compute.amazonaws.com] entered the room.
(11:35:33 PM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(11:38:00 PM) vtnerd left the room (quit: Ping timeout: 250 seconds).
(11:42:05 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:11:52 AM) vtnerd left the room (quit: Quit: ZNC 1.7.1 - https://znc.in).
(12:15:22 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(12:35:03 AM) investanto left the room (quit: Quit: Changing servers).
(12:35:16 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(12:37:43 AM) rottensox left the room (quit: Quit: Quit).
(12:38:53 AM) Tom_Cruise [~Tom@37.120.153.227] entered the room.
(12:55:43 AM) ArticMine left the room (quit: Ping timeout: 246 seconds).
(01:08:36 AM) luigi1111w left the room (quit: Read error: Connection reset by peer).
(01:09:02 AM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(01:09:10 AM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(01:37:10 AM) investanto left the room (quit: Quit: Changing servers).
(01:37:22 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(02:16:05 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:56:08 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:07:00 AM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(03:07:53 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(03:15:50 AM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(03:16:47 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(03:17:50 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(03:28:50 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(03:37:12 AM) sech1 left the room (quit: Quit: Leaving).
(03:47:48 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:59:58 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:14:35 AM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(04:21:59 AM) midipoet [uid316937@gateway/web/irccloud.com/x-ockjbymxoifyylht] entered the room.
(04:30:36 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(04:33:13 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(04:49:51 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(04:58:52 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:26:17 AM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(05:32:54 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(05:35:22 AM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(05:39:59 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:03:11 AM) eatingnow left the room (quit: Ping timeout: 256 seconds).
(06:05:14 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(06:08:22 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(06:08:58 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:11:03 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(06:12:57 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(06:17:45 AM) dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] entered the room.
(06:46:11 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:56:05 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:57:53 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(06:58:23 AM) rottensox left the room (quit: Client Quit).
(06:58:31 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(08:20:49 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(09:08:34 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(09:11:34 AM) el00ruobuob left the room (quit: Ping timeout: 255 seconds).
(09:39:33 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:53:45 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(09:56:42 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(11:00:06 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:01:07 AM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(11:14:52 AM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(11:26:37 AM) hyc: pine64 cluster https://twitter.com/thepine64/status/1111243308263751687
(11:26:46 AM) hyc: cute but not competitive
(11:27:30 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:33:36 AM) medusa_ [sid255755@gateway/web/irccloud.com/x-crvqphclsyktvzrx] entered the room.
(11:36:10 AM) oneiric_: so kawaii
(11:36:17 AM) fort3hlulz [~setsimmo@173.38.117.93] entered the room.
(11:39:58 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(11:42:14 AM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(11:42:59 AM) cjd: So tempted to tweet a picture of a Phi
(11:57:13 AM) rottensox left the room (quit: Quit: Quit).
(12:05:34 PM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(12:06:20 PM) sech1 left the room (quit: Quit: Leaving).
(12:08:56 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(12:20:05 PM) ferretinjapan is now known as bearretinjapan
(12:23:11 PM) bearretinjapan is now known as ferretinjapan
(12:29:38 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(12:34:04 PM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(12:37:18 PM) el00ruobuob left the room (quit: Ping timeout: 268 seconds).
(12:38:25 PM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(12:41:04 PM) kico: hyc do we have benchmarks on what one of those makes in randomX ?
(12:41:12 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(12:41:22 PM) kico: I bet they would do a good Watt/Hash racio :P
(12:45:03 PM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(12:49:53 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:04:02 PM) hyc: rockpro64? I don't have one on hand
(01:04:17 PM) hyc: could fire up my hikey960 to get some idea of cortex-a72
(01:06:50 PM) hyc: we still need full ARMv8 port ...
(01:46:50 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(01:50:25 PM) kinghat left the room (quit: Quit: The Lounge - https://thelounge.chat).
(01:51:10 PM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(01:56:37 PM) xcsd [45293c18@gateway/web/cgi-irc/kiwiirc.com/ip.69.41.60.24] entered the room.
(02:16:13 PM) Tom_Cruise [~Tom@37.120.153.227] entered the room.
(02:24:39 PM) Coupe420 left the room (quit: Remote host closed the connection).
(02:34:16 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(02:49:49 PM) sgp_ left the room (quit: Excess Flood).
(02:50:24 PM) sgp_ [sid329439@gateway/web/irccloud.com/x-qxnnziitlzqltpix] entered the room.
(03:06:26 PM) xcsd left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
(03:50:45 PM) dEBRUYNE left the room ("Leaving").
(03:52:08 PM) spaced0ut left the room (quit: Ping timeout: 245 seconds).
(03:54:01 PM) luigi1113 [~luigi1111@unaffiliated/luigi1111] entered the room.
(03:57:36 PM) luigi1111w left the room (quit: Ping timeout: 272 seconds).
(04:15:25 PM) kico: hyc, oh I see I don't have one unfortunately
(04:24:01 PM) kico: would be great if you guys could post benchmarks with W consumption also
(04:40:40 PM) ferretinjapan left the room (quit: Ping timeout: 272 seconds).
(05:04:05 PM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(05:12:33 PM) ArticMine left the room (quit: Ping timeout: 245 seconds).
(05:31:24 PM) Tom_Cruise left the room (quit: Ping timeout: 244 seconds).
(05:44:56 PM) Tom_Cruise [~Tom@37.120.153.227] entered the room.
(05:59:33 PM) Tom_Crui_ [~Tom@185.180.13.45.adsl.inet-telecom.org] entered the room.
(06:01:05 PM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(06:10:02 PM) luigi1113 is now known as luigi1111w
(06:29:02 PM) sech1 left the room (quit: Quit: Leaving).
(06:44:36 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(07:10:18 PM) lithiumpt left the room (quit: Ping timeout: 250 seconds).
(07:25:02 PM) fort3hlulz left the room (quit: Quit: Leaving).
(07:38:38 PM) Tom_Crui_ left the room (quit: Ping timeout: 272 seconds).
(08:01:20 PM) lithiumpt [~lithiumpt@185.236.201.132] entered the room.
(08:39:39 PM) Tom_Cruise [~Tom@185.180.13.45.adsl.inet-telecom.org] entered the room.
(08:44:07 PM) Tom_Cruise left the room (quit: Ping timeout: 255 seconds).
(08:45:57 PM) Tom_Cruise [~Tom@cpe-24-24-133-238.socal.res.rr.com] entered the room.
(08:47:14 PM) Tom_Cruise left the room (quit: Client Quit).
(09:28:58 PM) rottensox left the room (quit: Ping timeout: 250 seconds).
(10:28:15 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(10:31:35 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:50:34 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1001::c4] entered the room.
(11:15:46 PM) Masoch_Von_Sade left the room (quit: Remote host closed the connection).
(12:02:46 AM) luigi1113 [~luigi1111@unaffiliated/luigi1111] entered the room.
(12:05:37 AM) luigi1111w left the room (quit: Ping timeout: 244 seconds).
(12:28:37 AM) rottensox left the room (quit: Remote host closed the connection).
(12:50:52 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:07:24 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:42:02 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:56:16 AM) sech1 left the room (quit: Quit: Leaving).
(04:10:43 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:11:53 AM) el00ruobuob_[m] left the room (quit: Read error: Connection reset by peer).
(04:12:46 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(04:36:14 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(05:39:40 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:09:24 AM) midipoet [uid316937@gateway/web/irccloud.com/x-osvwpczaftzyjrbk] entered the room.
(06:11:18 AM) kico left the room (quit: Remote host closed the connection).
(06:11:33 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(07:27:15 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(08:39:06 AM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(08:55:26 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:02:40 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(09:03:41 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(09:20:09 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:37:02 AM) fort3hlulz_ [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:37:41 AM) fort3hlulz left the room (quit: Quit: Leaving).
(09:40:44 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(09:44:46 AM) rottensox left the room (quit: Ping timeout: 250 seconds).
(09:51:15 AM) fort3hlulz_ left the room (quit: Quit: Leaving).
(09:51:36 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:53:09 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(10:26:47 AM) sech1: Very, very interesting article on ProgPoW: https://medium.com/@Linzhi/eip-1057-progpow-open-chip-design-for-only-1-cost-power-increase-eip-1057-progpow-d106d9baa6eb[1]
(10:27:08 AM) sech1: Random math in ProgPoW is actually very small on chip after all
(10:28:01 AM) tevador: probably due to the lack of floating point ops
(10:28:28 AM) sech1: RandomX has an advantage here because it has complex 128-bit (2xFP64) instructions and it's overall 64-bit, so such design "do everything then go through muxer" would waste a lot of power
(10:29:44 AM) sech1: and if this design is viable it means GPU:ASIC ratio on ProgPoW would be worse than it's currently on ETHash
(10:30:07 AM) sech1: because power cost for ASIC is so low and ProgPoW is so power hungry on GPU
(10:30:31 AM) sech1: Which means not only ProgPoW doesn't achieve it's goal, it achieves completely opposite goal, lol
(10:32:34 AM) sech1: One more reason to get actual feedback from hardware engineers
(10:33:41 AM) tevador: what is the different in power consumption between ethash and progpow?
(10:33:50 AM) tevador: difference*
(10:33:57 AM) tevador: is it more than 50%?
(10:34:02 AM) sech1: ProgPoW consumes much more on GPU
(10:34:12 AM) sech1: because of GPU core load
(10:34:33 AM) tevador: yes, it's expected
(10:34:47 AM) tevador: some people used to dual mine eth with some core heavy algorithms
(10:34:47 AM) sech1: I don't remember exact numbers
(10:35:11 AM) hyc: because ethhash main load was memory?
(10:35:25 AM) sech1: yes, ETHash only used power on memory reads
(10:35:36 AM) sech1: core could be downvolted and underclocked to the limit
(10:35:43 AM) sech1: or used to dual-mine something else
(10:37:29 AM) sech1: in light of this article, I'm against ProgPoW in its current state now
(10:37:44 AM) sech1: They need more different instructions, a lot more
(10:37:50 AM) sech1: and FP instructions too
(10:38:38 AM) hyc: right
(10:40:45 AM) tevador: we would need this kind of analysis for RandomX also, but it would be a lot more work I guess
(10:41:14 AM) tevador: but I don't think it would take more than a few days for someone with enough experience to make a qualified estimate like this
(10:41:50 AM) sech1: Hey, there are some names mentioned in the end of that article
(10:42:13 AM) hyc: worth checkin out but will probably just be ETH community
(10:45:52 AM) sech1: ProgPoW only has 32x32-bit registers (1024 bits in total), 2 times less than RandomX. And only 16 KiB cache
(10:45:57 AM) sech1: I thought they had more.
(10:46:30 AM) sech1: and this cache is even read-only, what a shame
(10:48:39 AM) tevador: you can see that 90% of the ProgPow math logic is the multiplier
(10:48:42 AM) tevador: the rest is peanuts
(10:48:53 AM) sech1: 32-bit multiplier
(10:48:59 AM) sech1: 64-bit is 4 times bigger, right?
(10:49:12 AM) tevador: yes, it's N**2
(10:49:30 AM) sech1: plus FP64 DIV/SQRT logic is quite big too
(10:49:34 AM) tevador: actually RandomX needs a 64x64->128 multiplier
(10:49:55 AM) sech1: ProgPoW needs 32x32->64 multiplier
(10:50:03 AM) sech1: they have instructions both for low and high 32 bits
(10:50:05 AM) tevador: ok, so it's 4x
(10:55:46 AM) hyc: their op selector r % 11 is totally braindead
(10:56:17 AM) sech1: oh, I calculated wrong. ProgPoW has 16x32x32-bit registers (16384 bits, 2 KiB)
(10:56:36 AM) sech1: That's why they count 2 KiB for regfile
(10:56:59 AM) sech1: ProgPoW operates on vectors of size 16
(10:57:31 AM) hyc: so each of these ops is a vector op? ok
(10:57:46 AM) sech1: yes, it's a vector op
(10:57:56 AM) hyc: which means all of the gate counts in the article must be multiplied by 16
(10:58:02 AM) sech1: article doesn't mention it, so maybe their number are off by a factor 16
(10:58:16 AM) sech1: on the other hand, they do use correct size of register file
(10:58:17 AM) hyc: definitely off by 16
(10:58:28 AM) hyc: "A&B only cost 32 gate"
(10:59:41 AM) sech1: "Total size of Math() is about 0.0015mm² on a TSMC16ULP process."
(10:59:42 AM) hyc: or take their final "An ASIC can implement 10K sets of that block:" and divide by 16
(10:59:54 AM) sech1: I'm not sure if they count vector of 16 here
(11:02:47 AM) sech1: 25k logic gates = 0.0015 mm^2 on 16nm process?
(11:03:13 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:04:00 AM) hyc: their math block is defintely not a vector of 16
(11:04:35 AM) sech1: But then they combine it with full 2 KiB register file
(11:04:55 AM) sech1: whic is 32 vector registers
(11:05:52 AM) tevador: they are not off by a factor of 16
(11:06:09 AM) tevador: ~8.4K Merge() and ~4.8K Math() per hash
(11:06:19 AM) tevador: this does sound like they calculated multiple lanes
(11:06:30 AM) tevador: but the numbers are still off I think
(11:07:45 AM) tevador: PROGPOW_LANES * PROGPOW_CNT_MATH * PROGPOW_CNT_DAG is 18K
(11:09:51 AM) sech1: No, it's correct
(11:10:07 AM) hyc: ? https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1057.md using version 0.9.2 or 0.9.3?
(11:11:44 AM) sech1: math is called PROGPOW_CNT_MATH*PROGPOW_LANES*PROGPOW_CNT_DAG times
(11:12:09 AM) sech1: 18432 times
(11:12:36 AM) sech1: or 1152 with vector math block
(11:13:15 AM) sech1: so their numbers are off 4 times
(11:13:27 AM) tevador: yes
(11:13:48 AM) sech1: maybe because "Task latency is 4 cycles, but we can have 4 independent threads so we can make this pipeline fully loaded."
(11:14:34 AM) sech1: They definitely need to publish full calculation for their numbers
(11:14:48 AM) tevador: they already calculates with it, 1 GHz * 10K cores = 10T throughput
(11:14:54 AM) tevador: calculated*
(11:15:38 AM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(11:15:43 AM) hyc: so is 8.4K Merge per hash correct?
(11:16:41 AM) sech1: It must be more than 18432
(11:16:47 AM) sech1: because merge is called from 2 other places
(11:17:35 AM) tevador: Merge is 33K per hash
(11:17:48 AM) tevador: if I'm seeing it correctly
(11:17:55 AM) sech1: merge count = PROGPOW_CNT_DAG*((PROGPOW_CNT_CACHE+PROGPOW_CNT_MATH)*PROGPOW_LANES+PROGPOW_DAG_LOADS*PROGPOW_LANES)
(11:18:39 AM) tevador: so definitely off by a factor of 4
(11:19:15 AM) sech1:  yes, merge count is 33792
(11:22:46 AM) sech1: "Total size of Math() is about 0.0015mm² on a TSMC16ULP process." So this is for non-vector math block and without register file
(11:22:49 AM) sech1: just did some math
(11:25:55 AM) tevador: so 10K cores would be how many mm2?
(11:26:00 AM) sech1: 10K Math blocks is 15 mm^2
(11:26:20 AM) tevador: for register SRAM, you can count 9 Mbit/mm2
(11:26:28 AM) sech1: plus 2KiB register files for each 16 math blocks
(11:26:45 AM) sech1: so around 1.25 MiB for register files
(11:26:59 AM) sech1: everything can fit in 20 mm^2 I think
(11:27:24 AM) sech1: but 10K Math blocks at 1 GHz won't to 1.2 GH/s
(11:27:36 AM) Inge-: You guys already making a progpow ASIC :D :D
(11:28:00 AM) sech1: this number is definitely off, and not even by 16
(11:28:08 AM) sech1: it's off by factor 64
(11:28:26 AM) sech1: 10K math blocks = 625 vector blocks
(11:28:37 AM) sech1: and then they have factor 4 for the number of math operations
(11:28:49 AM) sech1: so it's 18.75 MH/s, not 1.2 GH/s
(11:30:08 AM) hyc: so 19% more than GTX1070Ti
(11:30:16 AM) tevador: sech1: are you sure? 64 accesses are already counted in the 33K/18K Merge/Math
(11:30:34 AM) sech1: no, it's different 64
(11:30:47 AM) sech1: 16 comes from vector registers
(11:30:56 AM) sech1: oh, nvm
(11:30:59 AM) sech1: it's factor 4
(11:36:55 AM) tevador: so still about 20x more compute efficient than a GPU
(11:37:55 AM) tevador: this probably still makes progpow have worse ASIC/GPU ratio than ethash
(11:38:28 AM) hyc: power-wise seems so
(11:39:57 AM) hyc: I'm missing something. how can their simple 4-stage pipeline work since Math and Merge have different number of invocations per hash loop?
(11:40:18 AM) sech1: They can just bypass math when it's not needed
(11:40:28 AM) hyc: ok
(11:40:42 AM) sech1: yes, still 300 MH/s @ 30 watts is much better than GPU
(11:41:08 AM) sech1: "progpow have worse ASIC/GPU ratio than ethash" <- still true
(11:42:23 AM) hyc: good to know. but progpow fails to get any benefit from randomizing the math
(11:42:46 AM) hyc: the control flow is still pure sequential, trivially simple state machine
(11:43:45 AM) tevador: yes, especially bitwise logic is way too simple and you waste more energy on instruction decoding than the actual operation
(11:44:08 AM) hyc: it incurs all the cost of the math ops without forcing the contro cost onto an ASIC
(11:44:15 AM) hyc: control
(11:44:32 AM) sech1: their problem is too few and too simple instructions
(11:44:35 AM) tevador: they could somewhat close the gap by using floating point
(11:45:08 AM) hyc: that would help a little. they need to offset all of their instruction decode cost, or force the ASIC to pay decode cost.
(11:46:13 AM) sech1: they can't do that because program changes only every 10 blocks (2.5 minutes)
(11:47:06 AM) hyc: yeah, so basically they're toast.
(11:52:44 AM) sech1: btw this math block design can do CN/R math too, with minimal modifications
(11:52:47 AM) sech1: it will be even smaller
(11:53:16 AM) sech1: But math in CN/R has second obstacle for ASICs - high computation latency
(11:54:07 AM) hyc: right, CN/R has only 8 ops
(11:56:43 AM) sech1: GPU-like ASICs for CN/R don't make much sense (too expensive), and on-chip SRAM ASICs for CN/R will be much slower than CNv2 ASICs
(11:57:14 AM) sech1: HBM2 ASICs can still do something like 4 KH/s @ 50W on CN/R
(11:57:24 AM) sech1: 8x better than GPUs
(11:57:30 AM) tevador: yes, the purpose of CN/R math is to make the latency too high for on chip memory
(11:57:57 AM) tevador: I'm working on something similar for the RandomX dataset generation
(11:58:19 AM) tevador: to make a 'light' ASIC slower
(11:59:59 AM) sech1: linzhi-sonia are you here? Where did you get numbers for that progpow article? It's not ~8.4K Merge() and ~4.8K Math() per hash, it's 4 times more in reality
(12:00:21 PM) tevador: sech1: this is my instruction set for a CN/R-like generator https://pastebin.com/MwYtMFd0
(12:00:41 PM) tevador: I want to 100% saturate the core and keep the same latency as SquareHash
(12:01:39 PM) tevador: I'm taking Ivy Bridge as the reference arch, newer CPUs will be faster
(12:02:18 PM) hyc: saturate the core? keep all integer units busy?
(12:02:22 PM) sech1: that might work, you can get up to 3 IPC
(12:02:24 PM) tevador: yes
(12:02:44 PM) sech1: yes, it's 4 IPC in theory, but not in practice
(12:02:46 PM) tevador: also there is some limitation from the decoders
(12:02:52 PM) sech1: unless it's specially crafted test code
(12:03:02 PM) tevador: 16 B/cycle or 4 uOPs/cycle
(12:05:44 PM) tevador: since I want to have 8 different programs, it will run from the L1 cache and not the uOP cache
(12:06:23 PM) tevador: there will be 8 programs per epoch for dataset generation, one program per Cache access
(12:07:16 PM) tevador: and the highest latency register for each program will be the address register for the next access
(12:11:07 PM) sech1 left the room (quit: Quit: Leaving).
(12:16:48 PM) dossier left the room (quit: Quit: Ping timeout (120 seconds)).
(12:20:43 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:40:23 PM) vtnerd left the room (quit: Quit: ZNC 1.7.1 - https://znc.in).
(01:40:57 PM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(02:00:22 PM) kico left the room (quit: Quit: Leaving).
(02:09:21 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(02:12:25 PM) kico left the room (quit: Remote host closed the connection).
(02:41:26 PM) luigi1113 is now known as luigi1111w
(03:02:45 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(03:26:57 PM) spaced0ut left the room (quit: Quit: Leaving).
(03:40:31 PM) kico left the room (quit: Remote host closed the connection).
(03:40:55 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(03:52:16 PM) antanst129 [~antanst@62.169.219.213] entered the room.
(03:52:40 PM) antanst12 left the room (quit: Ping timeout: 246 seconds).
(04:26:18 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(04:43:35 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:06:48 PM) fort3hlulz left the room (quit: Quit: Leaving).
(05:45:56 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:46:21 PM) luigi1111w left the room (quit: Quit: Leaving).
(06:58:41 PM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(07:29:42 PM) Hfdvn [567fe375@gateway/web/cgi-irc/kiwiirc.com/ip.86.127.227.117] entered the room.
(07:47:36 PM) sech1 left the room (quit: Quit: Leaving).
(07:51:01 PM) Hfdvn left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
(07:52:14 PM) Hfdvn [567fe375@gateway/web/cgi-irc/kiwiirc.com/ip.86.127.227.117] entered the room.
(08:02:36 PM) Hfdvn left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
(08:25:54 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(08:26:31 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(09:07:57 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(09:08:43 PM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(09:15:55 PM) OsrsNeedsF2P left the room (quit: Remote host closed the connection).
(09:25:37 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(09:45:02 PM) ArticMine left the room (quit: Ping timeout: 245 seconds).
(09:52:03 PM) kopite71 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(09:52:32 PM) kopite7 left the room (quit: Ping timeout: 245 seconds).
(09:58:56 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:16:02 PM) kopite71 left the room (quit: Ping timeout: 250 seconds).
(10:16:49 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:21:50 PM) kopite71 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:22:26 PM) kopite7 left the room (quit: Ping timeout: 246 seconds).
(11:36:08 PM) jwinterm left the room (quit: Remote host closed the connection).
(11:37:59 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:49:44 AM) ArticMine [~ArticMine@209.52.88.154] entered the room.
(01:52:35 AM) kopite71 left the room (quit: Quit: Leaving.).
(01:56:05 AM) fort3hlulz [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(02:10:48 AM) ArticMine left the room (quit: Read error: Connection reset by peer).
(02:27:13 AM) ArticMine [~ArticMine@209.52.88.123] entered the room.
(04:11:35 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(04:24:04 AM) rottensox left the room (quit: Ping timeout: 250 seconds).
(05:33:37 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bmhobwlcvffeksaq] entered the room.
(06:24:42 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:43:11 AM) sech1: https://www.reddit.com/r/Monero/comments/b79uts/latest_nonce_distribution_chart_4k_starting_from/[1]
(07:09:16 AM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(07:10:18 AM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(07:16:44 AM) smooth left the room (quit: *.net *.split).
(07:22:01 AM) smooth [~ubuntu@ec2-54-201-223-245.us-west-2.compute.amazonaws.com] entered the room.
(07:44:07 AM) linzhi-sonia: sech1: hey! sometimes here. just one person cannot be everywhere, and need to do work on our chip too.
(07:44:55 AM) linzhi-sonia: we are collecting all feedback about mistakes and misunderstandings, try to sort and group them. There was a lot of very good feedback actually.
(07:45:50 AM) linzhi-sonia: keep in mind that this is only a partial analysis, just looking at the logic that was added in ProgPoW. Trying to contribute to the discussion, showing some of our thought paths.
(07:46:06 AM) linzhi-sonia: that guy solardiz made some great comments too, we will process this one by one.
(07:47:14 AM) linzhi-sonia: I have a question too: I realize that Tim Olson must have said something about ProgPoW at some point in the past.
(07:47:56 AM) linzhi-sonia: what? can anyone DM me a way to contact Tim, email maybe? I will try over github.
(09:37:41 AM) kico left the room (quit: Ping timeout: 256 seconds).
(09:40:37 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:39:36 AM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(10:53:20 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:41:08 AM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(11:47:52 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:51:03 AM) wowario left the room (quit: Remote host closed the connection).
(11:51:49 AM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(11:52:20 AM) ArticMine left the room (quit: Ping timeout: 246 seconds).
(11:54:06 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(12:44:05 PM) jwinterm: linzhi-sonia: I would think emailing his github commit email is probably best, that seems like the place he is active in discussion
(12:46:34 PM) rottensox left the room (quit: Read error: Connection reset by peer).
(12:52:26 PM) midipoet [uid316937@gateway/web/irccloud.com/x-zqvvklehuogpwqnn] entered the room.
(05:53:56 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(06:01:40 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(06:48:42 PM) tevador: maxed-out x86 decoder stage: 585 instructions, 2.7 KiB in 170 cycles https://pastebin.com/BLrAmxrN
(06:48:54 PM) tevador: code crafted to fit into 16 bytes each cycle
(06:50:18 PM) hyc: this is to replace squarehash?
(06:50:23 PM) tevador: yes
(06:51:05 PM) hyc: will have to see how it looks for arm64
(06:51:09 PM) tevador: it's work in progress, I have to still map operations on the backend
(06:51:38 PM) tevador: but it looks like I can fit ~400 instructions in the same clock window as SquareHash
(06:52:05 PM) tevador: that's 5x more
(06:53:03 PM) hyc: interesting. so you're leveraging max possible ILP
(06:53:11 PM) tevador: yes that's the goal
(06:53:24 PM) hyc: but a pure in-order core like Cortex-A53 will just be 5x slower
(06:53:57 PM) tevador: A53 can do 2 IPC if the code is optimized
(06:54:17 PM) hyc: ok so only 2.5x slower ;)
(06:54:34 PM) hyc: and a custom ASIC will need some parallelism
(06:54:34 PM) tevador: that's the price you pay for low power 
(06:55:19 PM) tevador: ASIC will need an integer core for this
(06:55:30 PM) tevador: as opposed to a hardwired pipeline for SquareHash
(06:56:36 PM) tevador: I hope the ~1000 64-bit multiplications can burn enough power to be comparable to a DRAM read
(06:57:14 PM) hyc: doing this instead of DRAM accesses?
(06:57:27 PM) tevador: this is for the light version
(06:57:38 PM) tevador: single chip ASIC would use this
(06:57:50 PM) hyc: mov r,r ?
(06:58:13 PM) tevador: as I said, registers are not allocated yet, this is just the frontend allocation
(06:58:19 PM) hyc: ok
(06:58:47 PM) hyc: ok. so single-chip ASIC with large on-die SRAM?
(06:59:03 PM) tevador: yes, 256 MiB of SRAM for the cache
(06:59:19 PM) tevador: I want to make this approach as hard as possible
(06:59:34 PM) tevador: so there will be 8 programs like this per epoch
(06:59:42 PM) hyc: randomly generated?
(06:59:46 PM) tevador: yes
(07:00:42 PM) tevador: this is optimized for x86 code, I think ARM will be slower
(07:02:04 PM) hyc: yeah probably
(07:02:10 PM) tevador: on the other hand, ARM doesn't have decoder issues like x86
(07:02:17 PM) tevador: because all instructions are 4 bytes long
(07:03:19 PM) tevador: I read a lot about the decoders in Intel CPUs, there are 2-3 decoding stages and that burns a lot of power and is often a bottleneck
(07:09:59 PM) sech1: nice
(07:14:14 PM) hyc: an old paper on SRAM vs eDRAM for caches https://www.hpl.hp.com/techreports/2000/HPL-2000-53.pdf
(07:14:33 PM) hyc: eDRAM lets you get larger on-chip capacity
(07:14:52 PM) hyc: within the same chip area...
(07:15:49 PM) hyc: not sure if relevant for an ASIC because it assumes separate L2 cache layer
(07:19:11 PM) tevador: I think eDRAM is unlikely to be used, it makes manufacturing a lot more complicated
(07:19:48 PM) tevador: even the Grin ASIC has all 512 MiB of SRAM
(07:20:20 PM) hyc: I suppose. but we don't really know what cost/perf tradeoff they factored in
(07:23:40 PM) sech1 left the room (quit: Ping timeout: 250 seconds).
(07:34:07 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(08:23:40 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(08:26:17 PM) IRS left the room (quit: Ping timeout: 245 seconds).
(08:35:57 PM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(08:36:59 PM) [-mugatu-] left the room (quit: Ping timeout: 246 seconds).
(09:23:43 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(10:12:08 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:14:27 PM) ArticMine [~ArticMine@184.70.226.34] entered the room.
(11:36:44 PM) ArticMine left the room (quit: Quit: Leaving).
(11:40:16 PM) ArticMine [~ArticMine@184.70.226.34] entered the room.
(11:54:02 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(12:00:52 AM) jwinterm left the room (quit: Remote host closed the connection).
(12:12:42 AM) rottensox left the room (quit: Ping timeout: 250 seconds).
(12:23:08 AM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(12:24:08 AM) minthos: it would be cool if the pow was optimized for arm, not x86. Cool, but probably not desirable.
(01:06:48 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(01:20:58 AM) kopite7 left the room (quit: Quit: Leaving.).
(01:45:55 AM) fort3hlulz [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(01:50:47 AM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(03:56:16 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(04:01:32 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(04:05:26 AM) p0nziph0ne left the room (quit: Quit: Leaving).
(06:01:01 AM) fort3hlulz [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(06:34:28 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(07:35:11 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bxqdmcovgzkdskxd] entered the room.
(09:39:00 AM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(09:39:04 AM) rottensox left the room (quit: Ping timeout: 250 seconds).
(09:51:28 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:56:30 AM) sech1 left the room (quit: Quit: Leaving).
(10:02:52 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(10:19:11 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:22:17 PM) victorSN left the room (quit: Remote host closed the connection).
(01:05:29 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(03:16:57 PM) ferretinjapan left the room (quit: Read error: Connection reset by peer).
(03:17:42 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:02:31 PM) midipoet [uid316937@gateway/web/irccloud.com/x-wyythzybagymlxrv] entered the room.
(04:31:36 PM) IRS is now known as [-mugatu-]
(05:31:16 PM) ArticMine left the room (quit: Ping timeout: 250 seconds).
(05:41:25 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(05:44:16 PM) ArticMine [~ArticMine@d154-20-3-240.bchsia.telus.net] entered the room.
(07:05:06 PM) sech1 left the room (quit: Quit: Leaving).
(07:30:59 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(09:12:09 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:18:23 PM) lithiumpt left the room (quit: Ping timeout: 245 seconds).
(10:08:57 PM) lithiumpt [~lithiumpt@185.236.201.132] entered the room.
(10:50:44 PM) rottensox left the room (quit: Quit: Quit).
(10:50:46 PM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(10:51:26 PM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(11:03:38 PM) dossier [49e955be@gateway/web/cgi-irc/kiwiirc.com/ip.73.233.85.190] entered the room.
(11:30:13 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(12:35:14 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(01:35:23 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:08:17 AM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(02:10:25 AM) [-mugatu-] left the room (quit: Ping timeout: 250 seconds).
(02:13:11 AM) LSDog is now known as [-mugatu-]
(02:13:41 AM) [-mugatu-] is now known as Guest1552
(02:14:14 AM) Guest1552 is now known as lsdog
(02:39:52 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(03:20:47 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:22:51 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(03:27:38 AM) IRS left the room (quit: Read error: Connection reset by peer).
(03:28:25 AM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(05:07:08 AM) midipoet [uid316937@gateway/web/irccloud.com/x-rtytrnjlidrztlrl] entered the room.
(05:20:30 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(07:47:59 AM) victorSN [~victorSN@unaffiliated/victorsn] entered the room.
(09:25:46 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:26:21 AM) moneromooo: linzhi-sonia: in your opinion, would a SHA-3 PoW have a good chance of causing different ASIC makers to compete with designs having very similar efficiency, or would there still be differences large enough that which ASIC maker you choose would matter for a miner ?
(10:26:51 AM) moneromooo: SHA-3 here being selected for being simple to implement in hardware (allegedly).
(10:27:43 AM) moneromooo: In other words, would ASIC manufacturers quickly reach the state where they're stuck at the physical/technological limits, rather than progressing on their work towards those ?
(10:28:31 AM) moneromooo: I'm doubtful this would be the case, given Bitcoin's history with a simple (if not as simple) PoW, where subsequent generations improve a lot.
(10:29:09 AM) moneromooo: Do you think the combination of "now" and "SHA-3" would be enough to yield this "steady state" or not ?
(10:35:55 AM) kico left the room (quit: Remote host closed the connection).
(10:36:12 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:53:56 AM) kico left the room (quit: Remote host closed the connection).
(10:54:05 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:54:52 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:11:34 AM) sech1 left the room (quit: Quit: Leaving).
(11:25:03 AM) kopite7 left the room (quit: Quit: Leaving.).
(11:25:17 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:29:23 AM) kopite7 left the room (quit: Ping timeout: 246 seconds).
(11:30:43 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:52:37 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 246 seconds).
(11:59:44 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(12:11:44 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(12:16:02 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(12:23:37 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(12:44:16 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:16:35 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(02:52:38 PM) midipoet [uid316937@gateway/web/irccloud.com/x-mspowxgpigxldcet] entered the room.
(04:50:37 PM) spaced0ut left the room (quit: Quit: Leaving).
(05:16:33 PM) rottensox left the room (quit: Ping timeout: 250 seconds).
(05:52:20 PM) sech1 left the room (quit: Quit: Leaving).
(06:03:16 PM) jwinterm left the room (quit: Quit: No Ping reply in 180 seconds.).
(06:10:16 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(07:36:44 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(08:06:35 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:12:07 PM) kopite7 left the room (quit: Quit: Leaving.).
(09:12:40 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(09:28:48 PM) sgp_: https://github.com/tevador/RandomX/issues/31#issuecomment-478778652[1]
(10:07:48 PM) minthos: ooh, nice
(10:08:30 PM) minthos: I had the same intuition about branching but I'm not an expert
(10:31:27 PM) hyc: that was a major point that the RWT reviews hammered on
(10:38:59 PM) minthos: rwt?
(10:40:58 PM) hyc: realworldtech forum
(10:47:12 PM) minthos: don't cpus have speculative execution? you could generate two paths every x cycles and randomly branch between them
(10:47:31 PM) minthos: you'd ignore the prediction part but still use some of the cpu's branch logic
(10:47:46 PM) minthos: don't know if that helps though
(10:48:46 PM) minthos: maybe it only helps to trade power for time, which is of no use here
(10:53:17 PM) hyc: speculation requires branching :P
(10:53:37 PM) hyc: i.e., if there are no branches in the code, there is nothing for the CPU to speculate
(10:54:02 PM) minthos: yes that's what I mean, you can generate code with branches in it
(10:54:38 PM) hyc: you can't generate purely random branches, safely.
(10:54:56 PM) hyc: totally random means unpredictable runtime, and possibility of infinite loops
(10:56:26 PM) hyc: we may be in a damned-if-you-do/ situation here. a CPU has a lot of logic devoted to branch prediction, and it's going to be powered up all the time anyway
(10:56:28 PM) minthos: you can generate two branches, they don't have to be random but you only decide which branch to take at the last minute, based on the result of the previous instruction
(10:56:57 PM) hyc: randomX is *all random*.
(10:57:10 PM) hyc: if there's anything non-random in it, an ASIC can hardcode that.
(10:57:55 PM) minthos: insert some branches non-randomly here and there
(10:59:05 PM) hyc: you're not paying attention.
(10:59:22 PM) minthos: I am but I may be missing some context
(11:00:03 PM) hyc: "insert some branches non-randomly" - if they're non-random, then an ASIC-maker can hardwire the specific pattern
(11:00:12 PM) hyc: and then they don't need to worry about the branches at all.
(11:00:58 PM) minthos: they can't hardwire the choice between the two branches if the choice is based on randomly generated code
(11:01:23 PM) minthos: they know there's a branch but they don't know which branch will be chosen until it's time to choose
(11:02:16 PM) minthos: that means all prefetching and pipelining must be discarded at that point unless both paths are executed
(11:43:18 PM) minthos: maybe cpus don't prefetch as aggressively as I thought, instead relying on correctly predicting branches most of the time
(11:44:31 PM) minthos: in which case the only way to take advantage of their branch logic is to serve them branches that closely resemble the real-world code they're optimized for
(12:19:46 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(12:22:38 AM) rottensox left the room (quit: Read error: Connection reset by peer).
(01:16:47 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:50:00 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:52:07 AM) sech1 left the room (quit: Quit: Leaving).
(02:53:55 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(02:55:48 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(03:02:12 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(05:08:38 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bmkrdplaycpugpsw] entered the room.
(05:39:15 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:43:21 AM) hyc: passive liquid cooled box w/96 AMD Epyc CPUs https://www.reddit.com/r/Amd/comments/b8fnf1/we_launched_this_epic_immersion_solution_packed/
(05:50:16 AM) sech1: I don't even want to know the price...
(05:51:41 AM) moneromooo: In liquidcooledboxcoin ?
(08:26:20 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(11:00:39 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:02:27 AM) sech1 left the room (quit: Quit: Leaving).
(11:08:22 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:17:34 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:32:19 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(12:08:06 PM) midipoet [uid316937@gateway/web/irccloud.com/x-hycbqhkccxbouccs] entered the room.
(12:48:36 PM) luigi1111w left the room (quit: Quit: Leaving).
(01:01:40 PM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(01:42:17 PM) needmoney90: > So I'm guessing it can handle minecraft pretty well then?
(01:42:25 PM) needmoney90: lol
(01:42:28 PM) needmoney90: that comment
(01:44:56 PM) needmoney90: https://www.youtube.com/watch?v=V_OYSI-G5uU&feature=youtu.be[1]
(01:48:57 PM) OsrsNeedsF2P left the room (quit: Ping timeout: 268 seconds).
(01:50:15 PM) ferretinjapan left the room (quit: Read error: Connection reset by peer).
(01:51:13 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:53:03 PM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(02:17:39 PM) OsrsNeedsF2P left the room (quit: Read error: Connection reset by peer).
(02:17:59 PM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(03:16:58 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(03:28:08 PM) gethh: Intel will release it's new MCP CPU today
(04:57:40 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(05:42:27 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:16:14 PM) sech1 left the room (quit: Quit: Leaving).
(06:25:55 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:42:40 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(07:12:33 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(07:58:46 PM) hyc: I benchmarked that Xeon chip last June
(07:58:57 PM) hyc: along with a set of 128GB Optane DIMMs
(07:59:23 PM) hyc: 56 cores / 112 threads is kind of impressive. but AMD with 64 cores / 128 threads will knock them on their ass.
(07:59:33 PM) hyc: Intel is in a world of hurt
(09:10:09 PM) luigi1113 [~luigi1111@unaffiliated/luigi1111] entered the room.
(09:11:32 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(09:11:37 PM) glv_ [~glv@2001:41d0:305:2100::165] entered the room.
(09:11:59 PM) suraeNoether_ [sid231938@gateway/web/irccloud.com/x-ocvykchxvleughbs] entered the room.
(09:12:34 PM) luigi1111w left the room (quit: Read error: Connection reset by peer).
(09:12:34 PM) el00ruobuob_[m] left the room (quit: Remote host closed the connection).
(09:12:34 PM) glv left the room (quit: Quit: ZNC 1.7.2+deb1~bpo9+1 - https://znc.in).
(09:12:34 PM) suraeNoether left the room (quit: Ping timeout: 245 seconds).
(09:12:35 PM) suraeNoether_ is now known as suraeNoether
(10:31:48 PM) luigi1113 is now known as luigi1111w
(11:25:24 PM) OSNF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(11:27:50 PM) OsrsNeedsF2P left the room (quit: Ping timeout: 250 seconds).
(01:17:48 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:17:56 AM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:48:50 AM) gethh: last June, thats unfair I got my samples in early January ;0
(02:26:12 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:38:04 AM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(03:06:51 AM) sech11 left the room (quit: Quit: Leaving).
(03:06:53 AM) sech1 left the room (quit: Read error: Connection reset by peer).
(03:15:30 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:22:03 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(05:03:01 AM) glv_ left the room (quit: Quit: ZNC 1.7.2+deb1~bpo9+1 - https://znc.in).
(05:03:52 AM) glv [~glv@2a01:e34:ed03:c7d0:9c3b:23ce:2561:43ee] entered the room.
(05:32:47 AM) midipoet [uid316937@gateway/web/irccloud.com/x-dmkfsvwclchtqcqn] entered the room.
(07:19:55 AM) investanto left the room (quit: Quit: Changing servers).
(07:20:06 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(07:25:06 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:01:07 AM) spaced0ut left the room (quit: Quit: Leaving).
(09:14:07 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:22:39 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:29:22 AM) midipoet [uid316937@gateway/web/irccloud.com/x-bpnkhaoqamxwxuut] entered the room.
(10:53:08 AM) hyc: gethh: well, this was at an Intel facility, not my own site
(10:55:48 AM) sech1 left the room (quit: Quit: Leaving).
(11:02:02 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:04:12 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:37:10 AM) [-mugatu-] is now known as MAGAtu
(11:55:27 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(12:24:10 PM) gethh: i'm gonna talk to amd where are my god damn rome samples
(01:04:39 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(01:13:02 PM) MAGAtu is now known as [-mugatu-]
(02:10:05 PM) tevador: sech1: code generator test output: https://pastebin.com/8Pn35Y1U
(02:10:25 PM) tevador: IPC is around 2.8-3.1 for most programs
(02:11:13 PM) tevador: just the multiplications alone should match the energy needed to fetch data from DRAM
(02:46:44 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(02:46:51 PM) hyc: cool
(02:51:20 PM) sech1: tevador how did you found out port utilization? Some tool or just a guess?
(02:54:00 PM) sech1: IPC > 3 is very cool, especially with that many multiplications
(02:54:50 PM) sech1: 142 multiplications in 171 cycles is also very cool, approaching 1 multiplications/cycle which is the theoretical limit
(03:01:40 PM) sech1: ASIC latency is calculated assumin 1 cycle for all instructions and out-of-order parallel execution?
(03:03:05 PM) sech1: 91 cycle for ASIC @ 1 GHZ (it can't run faster when it needs to do 64x64->128 mul in 1 cycle) is 91 ns, good enough
(03:10:20 PM) tevador: sech1: yes, ASIC latency is calculated for 1 cycle latency and infinite number of ALUs
(03:10:41 PM) tevador: port utilization is simulated as Ivy Bridge CPU
(03:10:58 PM) tevador: port mapping from Agner Fog
(03:12:03 PM) tevador: I still have to measure the actual execution time, I hope it will match the simulation
(03:12:11 PM) sech1: IPC ~ 3 is also theoretical limit for Ivy Bridge is there are no memory operations
(03:12:27 PM) sech1: *if there
(03:12:28 PM) tevador: yes, it has just 3 ALU ports
(03:12:39 PM) tevador: haswell and later have 4
(03:12:51 PM) tevador: bulldozer just 2
(03:13:01 PM) tevador: zen 4
(03:14:15 PM) tevador: > 3 IPC is possible due to move elimination
(03:14:31 PM) tevador: also xor rcx, rcx doesn't use an execution port
(03:18:50 PM) tevador: btw the generator is almost 1000 LoC
(03:41:09 PM) glv left the room (quit: Quit: Leaving).
(04:25:52 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(04:26:45 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(04:26:45 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(04:27:47 PM) fort3hlulz left the room (quit: Read error: Connection reset by peer).
(04:28:58 PM) fort3hlulz_ left the room (quit: Client Quit).
(04:29:22 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1006::16] entered the room.
(04:42:29 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(04:43:04 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:48:31 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:34:38 PM) lsdog left the room (quit: Ping timeout: 245 seconds).
(05:50:28 PM) lsdog [~LSDog@unaffiliated/lsdog] entered the room.
(05:58:04 PM) sech1 left the room (quit: Quit: Leaving).
(06:10:19 PM) midipoet [uid316937@gateway/web/irccloud.com/x-kznspvmkznbddret] entered the room.
(06:20:06 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(08:33:13 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(08:58:03 PM) spaced0ut left the room (quit: Ping timeout: 255 seconds).
(09:02:29 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:20:20 PM) infinitejest_ left the room (quit: Ping timeout: 252 seconds).
(11:22:54 PM) infinitejest_ [sid203393@gateway/web/irccloud.com/x-guxyyscnofyqshja] entered the room.
(11:34:14 PM) infinitejest_ left the room.
(11:37:04 PM) infinitejest- [sid203393@gateway/web/irccloud.com/x-guxyyscnofyqshja] entered the room.
(12:03:31 AM) investanto left the room (quit: Quit: Changing servers).
(12:03:42 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(12:05:37 AM) ArticMine left the room (quit: Quit: Leaving).
(12:08:23 AM) ArticMine [~ArticMine@d154-20-3-240.bchsia.telus.net] entered the room.
(12:19:20 AM) OSNF2P left the room (quit: Read error: Connection reset by peer).
(12:25:11 AM) OsrsNeedsF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(01:28:58 AM) dossier left the room (quit: Ping timeout: 246 seconds).
(01:58:20 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:06:21 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:32:06 AM) sech1 left the room (quit: Quit: Leaving).
(02:40:25 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(04:17:35 AM) oneiric_ left the room (quit: Ping timeout: 256 seconds).
(04:21:34 AM) oneiric_ [~oneiric_@gateway/tor-sasl/oneiric/x-48504833] entered the room.
(04:26:37 AM) el00ruobuob [~el00ruobu@212.121.161.50] entered the room.
(04:41:54 AM) glv [~glv@2a01:e34:ed03:c7d0:6929:4d33:f313:ca20] entered the room.
(05:00:41 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:09:50 AM) midipoet [uid316937@gateway/web/irccloud.com/x-wscbhlugazvlgknb] entered the room.
(05:10:25 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(05:10:38 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:11:07 AM) crCr62U0 left the room (quit: Client Quit).
(05:29:02 AM) gethh left the room (quit: Quit: Connection closed for inactivity).
(05:49:42 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:38:26 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(08:31:58 AM) gethh [uid264798@gateway/web/irccloud.com/x-alqkuqxyrpmiwppi] entered the room.
(08:49:25 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:11:11 AM) midipoet [uid316937@gateway/web/irccloud.com/x-qrjjbqkzqdxsbmmp] entered the room.
(09:22:33 AM) fort3hlulz [~setsimmo@173.38.117.69] entered the room.
(09:56:22 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(10:26:38 AM) OSNF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(10:27:28 AM) OsrsNeedsF2P left the room (quit: Ping timeout: 250 seconds).
(10:57:51 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:10:33 AM) sech1 left the room (quit: Quit: Leaving).
(11:19:34 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:39:21 AM) midipoet [uid316937@gateway/web/irccloud.com/x-duwiwfgjmbyamdds] entered the room.
(11:47:44 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:52:32 AM) charuto [charutocaf@gateway/shell/matrix.org/x-prrlkzvrlgpwvqhr] entered the room.
(11:57:47 AM) el00ruobuob left the room (quit: Ping timeout: 246 seconds).
(12:35:56 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(12:37:28 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(12:38:22 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(01:08:09 PM) glv left the room (quit: Quit: Leaving).
(01:24:38 PM) kicoo [~kico@gateway/tor-sasl/kico] entered the room.
(01:25:12 PM) kico is now known as Guest66575
(01:25:13 PM) kicoo is now known as kico
(01:27:15 PM) Guest66575 left the room (quit: Ping timeout: 256 seconds).
(01:32:43 PM) bearretinjapan is now known as ferretinjapan
(01:59:18 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(02:32:23 PM) midipoet [uid316937@gateway/web/irccloud.com/x-qoruuawurmpcrqrq] entered the room.
(03:15:58 PM) oneiric_ left the room (quit: Quit: out).
(03:25:10 PM) antanst129 left the room (quit: Remote host closed the connection).
(03:26:31 PM) antanst129 [~antanst@62.169.219.213] entered the room.
(03:31:26 PM) antanst129 left the room (quit: Quit: The Lounge - https://thelounge.chat).
(03:31:54 PM) antanst [~antanst@62.169.219.213] entered the room.
(03:56:34 PM) crCr62U0 left the room (quit: Quit: leaving).
(04:14:26 PM) fort3hlulz left the room (quit: Ping timeout: 250 seconds).
(05:08:47 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(05:10:22 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1001::352] entered the room.
(05:13:18 PM) fort3hlulz_ left the room (quit: Client Quit).
(05:13:36 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(05:13:44 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1001::352] entered the room.
(05:36:30 PM) fort3hlulz left the room (quit: Ping timeout: 264 seconds).
(05:54:28 PM) [-mugatu-] is now known as SoiMeter
(05:56:05 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:26:01 PM) sech1 left the room (quit: Quit: Leaving).
(06:35:20 PM) ArticMine left the room (quit: Read error: Connection reset by peer).
(06:41:19 PM) ferretinjapan left the room (quit: Ping timeout: 244 seconds).
(06:51:09 PM) ArticMine [~ArticMine@184.70.226.34] entered the room.
(07:20:54 PM) el00ruobuob left the room (quit: Read error: Connection reset by peer).
(07:26:10 PM) klp left the room (quit: Quit: Connection closed for inactivity).
(08:23:06 PM) SoiMeter is now known as [-mugatu-]
(09:02:05 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:57:15 PM) OSNF2P left the room (quit: Quit: Leaving).
(09:57:34 PM) OSNF2P [~OsrsNeeds@2607:fea8:95e0:963:e75a:d4c1:b5da:7ee4] entered the room.
(11:33:08 PM) SomaticFanatic [~SomaticFa@gateway/tor-sasl/somaticfanatic] entered the room.
(12:11:14 AM) OSNF2P left the room (quit: Ping timeout: 250 seconds).
(12:21:20 AM) OSNF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(01:03:22 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:57:34 AM) vtnerd left the room (quit: Ping timeout: 246 seconds).
(02:01:45 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(02:31:16 AM) parasew[m] left the room (quit: Remote host closed the connection).
(02:31:20 AM) charuto left the room (quit: Read error: Connection reset by peer).
(02:31:47 AM) ErCiccione[m] left the room (quit: Remote host closed the connection).
(02:35:06 AM) moneromooo left the room (quit: Ping timeout: 255 seconds).
(02:39:25 AM) Guest37836 [fluffypony@primary.spagni.net] entered the room.
(02:40:32 AM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-pjdsvpapekwunfki] entered the room.
(02:45:46 AM) klp [uid344501@gateway/web/irccloud.com/x-mdtdbhmdwdlaezpv] entered the room.
(02:55:24 AM) ErCiccione[m] [erciccione@gateway/shell/matrix.org/x-gwzjjmydgkfyjkvh] entered the room.
(02:55:24 AM) charuto [charutocaf@gateway/shell/matrix.org/x-rrgcvopeqhyasttc] entered the room.
(03:09:57 AM) luigi1111w left the room (quit: Read error: Connection reset by peer).
(03:11:40 AM) sech1 left the room (quit: Quit: Leaving).
(03:15:43 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(03:24:20 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:24:48 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:48:46 AM) Coupe420 left the room (quit: Remote host closed the connection).
(03:49:17 AM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(04:21:29 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:22:01 AM) SomaticFanatic left the room (quit: Ping timeout: 256 seconds).
(04:38:24 AM) Guest37836 is now known as moneromooo
(04:38:34 AM) moneromooo left the room (quit: Changing host).
(04:38:34 AM) moneromooo [fluffypony@unaffiliated/moneromooo] entered the room.
(04:55:23 AM) midipoet [uid316937@gateway/web/irccloud.com/x-tuiucysusjiplmft] entered the room.
(05:50:00 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:53:09 AM) parasew[m] left the room (quit: Remote host closed the connection).
(05:53:13 AM) ErCiccione[m] left the room (quit: Remote host closed the connection).
(05:53:36 AM) charuto left the room (quit: Remote host closed the connection).
(06:01:31 AM) parasew[m] [parasewmat@gateway/shell/matrix.org/x-uakfmitgixfkoscw] entered the room.
(06:14:19 AM) ErCiccione[m] [erciccione@gateway/shell/matrix.org/x-weskfnvkzsetqdyp] entered the room.
(06:14:19 AM) charuto [charutocaf@gateway/shell/matrix.org/x-mimbnhjuqvyskaif] entered the room.
(08:12:44 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(08:16:03 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:28:09 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(08:38:46 AM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(08:40:06 AM) fort3hlulz_ [~setsimmo@2001:420:c0cc:1006::44] entered the room.
(08:43:26 AM) fort3hlulz left the room (quit: Ping timeout: 246 seconds).
(08:55:54 AM) kico left the room (quit: Remote host closed the connection).
(08:56:30 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(09:01:59 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(09:07:15 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(09:36:29 AM) sech1: tevador I have a question about ISTORE instruction. Can it possibly store data to L3 under some conditions?
(09:37:25 AM) sech1: it's a bit unclear from documentation
(09:39:53 AM) sech1: ok, I can see from the code that ISTORE can only write to L1 and L2
(10:03:58 AM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(10:35:40 AM) tevador: yes, L1 and L2 with 3:1 ratio, same as reads
(10:36:34 AM) tevador: yesterday I analyzed one RandomX program and the only optimizations I could find were multiple loads/stores from the same address
(10:37:26 AM) sech1: I did some math with memory accesses for GPU and the conclusion is Vega 64 can run at only 200 H/s if it runs 1 program per CU
(10:37:45 AM) sech1: because memory access latency is huge, ~1000 ns
(10:38:09 AM) sech1: and there are 350-370k accesses to global memory on GPU per hash (everything except L1)
(10:39:00 AM) sech1: the only way to get decent performance is an branchless interpreter like I described above for NVIDIA GPUs
(10:39:09 AM) sech1: which can run thousands of programs in parallel
(10:39:23 AM) tevador: so eneric's estimate was very optimistic then
(10:39:54 AM) sech1: Memory access is a bottleneck here
(10:40:20 AM) sech1: to such scale that even running an interpreter is viable to improve performance
(10:40:32 AM) tevador: I'm curious about the performance of Titan V with the interpreter
(10:40:57 AM) tevador: if it can match Threadripper at 9K
(10:41:23 AM) sech1: Not sure. GTX 1080 ti can get to 1000-2000 h/s with many parallel programs
(10:41:39 AM) sech1: here comes bandwidth limitation because each memory access counts as 128 bytes even if it's only 8 bytes
(10:42:21 AM) sech1: Titan V will probably get to 3000 h/s but it will be limited by memory bandwidth
(10:42:38 AM) tevador: interesting, so compute is not an issue at all
(10:43:43 AM) sech1: No, compute is not a problem here. You can calculate a formula containing all instructions and combine them to get final result (aka branchless interpreter).
(10:43:55 AM) sech1: and you'll still be waiting for data from memory
(10:44:51 AM) sech1: I don't think _any_ modern GPU can get more than 3000 h/s, even the beefiest ones (Titan V, Radeon VII)
(10:46:15 AM) tevador: so basically having at least L2 scratchpad in SRAM in a must
(10:46:23 AM) tevador: is a must*
(10:47:31 AM) sech1: On the other hand, Cryptonight has 2M accesses per hash and GTX 1080 ti can run it at 1000 h/s
(10:47:46 AM) sech1: So 350-370k accesses on RandomX might mean GTX 1080 ti can do 5000 h/s
(10:47:54 AM) sech1: if optimized properly
(10:49:04 AM) sech1: hmm, no, won't work
(10:49:22 AM) sech1: many programs mean that L1 accesses count too
(10:49:55 AM) sech1: 983040 total accesses per hash (L1, L2, L3, dataset) if my math is right
(10:49:59 AM) sech1: so only 2000 h/s at best
(10:50:21 AM) tevador: how much cache does 1080 ti have?
(10:50:27 AM) tevador: should be enough for L1 scratchpads
(10:50:59 AM) tevador: 1000 threads is 16 MiB for L1
(10:52:51 AM) sech1: L1 will be thrashed by dataset/L3 accesses
(10:53:00 AM) sech1: only shared memory (64 KiB per SM) can be used for this
(10:53:03 AM) sech1: not enough
(10:54:27 AM) sech1: either way, an initial estimation "top GPU = 4 core CPU" still stands
(10:58:03 AM) fort3hlulz_: Is there any math/tests against Xeon procs yet?
(10:58:19 AM) fort3hlulz_: Or would it be useful? I have two dual Xeon boxes here with different model CPUs
(10:59:12 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:59:53 AM) tevador: some Xeons have been tested, results here: https://github.com/tevador/RandomX/issues/25[1]
(11:00:06 AM) fort3hlulz_: ty
(11:00:14 AM) tevador: mostly older models, though
(11:06:42 AM) tevador: sech1: btw I had to exclude register r5 from one instruction's destination due to x86 weirdness
(11:06:58 AM) tevador: so RandomX will carry some of x86 legacy, lol
(11:09:34 AM) sech1: LEA instruction?
(11:11:17 AM) sech1: it has limitations on some register combinations IIRC
(11:14:54 AM) tevador: yes
(11:15:04 AM) tevador: https://stackoverflow.com/questions/52522544/rbp-not-allowed-as-sib-base[1]
(11:15:15 AM) tevador: r13 cannot be the base register without offset
(11:15:44 AM) tevador: and I needed the instruction to be exactly 4 bytes, so I cannot use the 0 offset trick
(11:19:23 AM) sech1 left the room (quit: Quit: Leaving).
(11:44:24 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:53:17 AM) fort3hlulz_ left the room (quit: Quit: Leaving).
(11:58:14 AM) sech1: I've just checked again what enerc did to get 1200 h/s. His test program correctly does all scratchpad/dataset accesses, including the ones in random program, so GPU is able to hide some latency apparently.
(12:03:06 PM) tevador: fresh simulations of SuperscalarHash (SquareHash replacement): Average IPC 2.95, Average ASIC latency: 86.5 cycles, Average Multiplications: 140
(12:04:03 PM) tevador: compared to SquareHash: IPC 0.5, ASIC latency: 85/43 cycles (depends if MUL+SUB can be done in 1 cycle), Multiplications: 42
(12:04:18 PM) hyc: nice...
(12:04:56 PM) tevador: CPU latency should be ~170 for both
(12:05:38 PM) sech1: MUL+SUB can be done in 1 cycle
(12:05:51 PM) sech1: It's the same thing as FMA circuit does
(12:06:15 PM) sech1: almost 0 cost to add to existing multiplier (just rewire a bit before final addition)
(12:06:15 PM) hyc: yeah, basic DSP operation
(12:06:21 PM) tevador: right, so it's only 42-43 cycles for SquareHash
(12:06:34 PM) hyc: so a 4:1 advantage is now 2:
(12:06:36 PM) hyc: 1
(12:07:54 PM) sech1: ASIC cycles are not the same as CPU cycles
(12:08:04 PM) sech1: CPU runs at 4 GHz, ASIC runs at 1 GHz
(12:08:52 PM) tevador: anyways, SquareHash was definitely a weak point in the design
(12:08:56 PM) hyc: good point. but ASIC cycles also cost less power, most likely much lower voltage
(12:09:50 PM) tevador: ASIC can run maybe at 0.5 volts
(12:10:41 PM) sech1: No
(12:10:44 PM) sech1: 0.8 V
(12:10:48 PM) sech1: because of SRAM
(12:11:06 PM) sech1: compute-only ASICs can run at 0.5, but SRAM is a different beast
(12:11:19 PM) tevador: good, so that's less than 2x power advantage per cycle
(12:11:36 PM) tevador: my Ryzen runs at 1.05 V
(12:11:39 PM) sech1: CPUs can also run at 0.8 V, you just have to underclock them
(12:11:45 PM) tevador: 3rd gen can be undervolted even more
(12:12:15 PM) tevador: most of the time you can actually undervolt without underclocking
(12:12:23 PM) hyc: interesting point. miners tended to underclock/undervolt their GPUs. wonder if it's worthwhile to do for a CPU
(12:12:28 PM) tevador: the factory voltages have margins
(12:13:05 PM) tevador: undervolting will be definitely a thing
(12:13:26 PM) tevador: 5% lower voltage means 10% lower power
(12:15:42 PM) sech1: My notebook CPU (2012 Ivy Bridge) runs at 1.2 GHz, 0.8V when idle
(12:15:46 PM) sech1: just checked
(12:17:09 PM) sech1: Which means newer CPUs can go even lower
(12:21:13 PM) sech1: Ryzen 5 2600 goes to 1.5 GHz @ 0.4V when idle
(12:21:24 PM) sech1: not sure if it can run under load with that low voltage though
(12:21:45 PM) sech1: even not sure if CPU-Z shows correct voltage
(12:22:20 PM) tevador: Kaby Lake laptop idles at 0.6 V, 700 MHz
(12:23:20 PM) tevador: I used HWMonitor
(12:24:31 PM) sech1: Nope, it can't run under load (1.5 GHz, 0.8V - instant freeze)
(12:24:38 PM) sech1: Ryzen 5 2600
(12:26:41 PM) tevador: you tried to set the voltage in bios?
(12:26:55 PM) hyc: did you lock to low frequency too?
(12:27:07 PM) sech1: No, I used AMD Ryzen Master tool
(12:27:09 PM) sech1: under Windows
(12:27:22 PM) hyc: low voltage will slow transistor switching speed, so without underclocking you're hosed
(12:27:46 PM) sech1: trying to find lowest voltage which can sustain 1.5 GHz on Ryzen 5 2600
(12:28:03 PM) tevador: "for the 16nm PTM SRAM, the DRV is 649mV"
(12:28:09 PM) tevador: DRV = data retention voltage
(12:28:27 PM) tevador: operating voltage must be higher than this
(12:31:15 PM) sech1: ok, I needed to set frequence to 1.5 GHz first, then lower voltage
(12:31:29 PM) sech1: Running 1.5 GHz @ 0.8V now
(12:31:52 PM) tevador: try some burn test if it's stable
(12:32:01 PM) sech1: it has built-in stress test
(12:32:06 PM) hyc: randomX benchmark ;)
(12:32:13 PM) sech1: I'll find the limit with it first then try randomx
(12:32:20 PM) hyc: do you have a watt meter too?
(12:32:34 PM) sech1: yes, but it needs new batteries
(12:32:43 PM) tevador: I guess there is no ryzen master for Ubuntu?
(12:32:51 PM) sech1: Don't know
(12:33:09 PM) hyc: pretty sure there's similar, but I don't recall the name
(12:33:14 PM) sech1: Running 1.5 GHz @ 0.65V, lol
(12:33:19 PM) hyc: there's a tool for tweaking mobile ryzen power settings
(12:34:10 PM) tevador: 0.65 V seems low to be stable
(12:34:35 PM) sech1: was able to run @ 0.6V even
(12:34:39 PM) sech1: 0.55V - instant reboot
(12:35:32 PM) tevador: second step would be to find the highest stable clock speed for 0.6 V
(12:36:18 PM) tevador: anyways - try RandomX if it even gives the correct result
(12:37:05 PM) tevador: it's a good stress test for the memory controller
(12:44:43 PM) sech1: 1600 H/s at 1.5 GHz (was 4000+ h/s at 4 GHz)
(12:44:50 PM) sech1: so scaling is perfect
(12:45:09 PM) sech1: trying to find the lowest voltage now (0.9V runs fine)
(12:46:32 PM) sech1: 0.8V: CPU power 7.8W, SoC power 12.2W, 20W total. The bad thing is SoC voltage is separate and it doesn't go down
(12:47:06 PM) tevador: highest CPU efficiency doesn't mean highest system efficiency because there is overhead from chipset/SSD/RAM
(12:47:11 PM) sech1: SoC voltage is 0.86V
(12:47:47 PM) sech1: yes, I think the optimal value would be around 2.5-3 GHz and higher voltage
(12:48:06 PM) tevador: yes, there will be some sweet spot
(12:48:36 PM) sech1: 0.65V - running, CPU core power down to 5W, SoC power is still 12.2W
(12:48:54 PM) tevador: SoC voltage cannot be controlled?
(12:49:02 PM) sech1: maybe it can, but from BIOS
(12:50:51 PM) sech1: ok, so it runs fine @ 0.6V, CPU power down to 4.2W
(12:51:13 PM) sech1: and it was even 1800 H/s
(12:51:34 PM) sech1: maybe some background Windows services ran before when I got 1600 H/s
(12:52:24 PM) sech1: So I guess 64-core EPYC at low voltage will be the most efficient system
(12:52:27 PM) tevador: nice
(12:52:49 PM) sech1: yes, I can reduce SoC voltage in BIOS
(12:52:55 PM) tevador: but total system overhead for a 1 socket system will be high
(12:53:39 PM) tevador: if you can get 1600 H/s, I wonder if you can beat the laptop at 33 W total power
(12:54:04 PM) sech1: if I reduce SoC voltage to bare mininum and also reduce DRAM voltage... maybe
(12:54:13 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(12:54:35 PM) sech1: I think it's still much more than 33 W because of GPU (Vega) and HDD
(12:54:57 PM) tevador: yes, GPU is a problem
(12:55:07 PM) tevador: I wonder if ryzen can boot without a GPU
(12:55:15 PM) sech1: No, it can't
(12:55:24 PM) sech1: Only Ryzen with integrated GPU can
(12:55:27 PM) tevador: that's one advantage of Intel
(12:56:23 PM) tevador: I will test it later with one RX 550
(12:56:31 PM) tevador: and measure the wall power
(12:57:28 PM) sech1: Some GPUs consume < 10W when idle. Not sure if it's RX 550 or something else
(12:57:53 PM) sech1: 32-core Threadripper + some low-end GPU would be also very efficient
(01:07:09 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:20:01 PM) sech1: so reducing SoC voltage from 0.875V to 0.8V freezes the system when testing RandomX
(01:21:21 PM) crCr62U0: sech1: are you underclocking PC or laptop?
(01:21:34 PM) sech1: PC (Ryzen 5 2600)
(01:23:00 PM) sech1: I managed to get 1800 H/s and 16.5 W for CPU, but there is also the rest of PC
(01:23:06 PM) sech1: I think it's around 40W total
(01:23:25 PM) tevador: sech1: the memory controller uses SoC voltage
(01:23:33 PM) tevador: so it's clear why it freezes
(01:26:00 PM) sech1: but CPU core runs RandomX stable @ 1.5 GHz, 0.6V
(01:28:20 PM) sech1: Which is very cool. I think 32-core Threadripper with this speed and voltage can do 7.5 kh/s @ 30W (excluding the rest of system)
(01:32:46 PM) ArticMine left the room (quit: Ping timeout: 250 seconds).
(01:43:46 PM) sech1: Measured power at the wall: 50 W when idle (whole PC with Vega 64 and 1 TB HDD)
(01:44:00 PM) sech1: 63 W when mining RandomX (1.5 GHz, 0.6V, 1800 h/s)
(01:44:35 PM) spaced0ut left the room (quit: Quit: Leaving).
(01:45:06 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(01:51:43 PM) sech1: 123 W all stock (3.7 GHz, 1.15V, 4020 h/s)
(01:51:59 PM) sech1: so stock is a bit more efficient than underclock for Ryzen 5 2600
(01:52:59 PM) sech1: 32.6 H/s/watt for stock, 28.6 H/s/watt underclocked
(01:59:08 PM) midipoet [uid316937@gateway/web/irccloud.com/x-gdwqayphqzssvhbg] entered the room.
(02:07:02 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(02:13:26 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:14:29 PM) sech1 left the room (quit: Read error: Connection reset by peer).
(02:16:04 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:17:01 PM) sech1: and my notebook (Core i5-3210M, 2 cores) does 689 H/s @ 24 W (monitor off)
(02:17:07 PM) sech1: a bit worse than Ryzen PC
(02:17:33 PM) tevador: so it looks like I was a bit optimistic about the CPU scheduler
(02:18:27 PM) sech1: it has only 3 MB cache, so I'm not sure if 2 RandomX threads is optimal
(02:18:48 PM) tevador: tested SuperscalarHash: KabyLake is ~30% slower, Iny Bridge ~60% slower
(02:18:53 PM) tevador: :(
(02:19:01 PM) tevador: Ivy*
(02:19:28 PM) tevador: compared to SquareHash
(02:19:44 PM) sech1: you can still have 2 times more multiplications than SquareHash
(02:19:49 PM) sech1: just reduce the size of program
(02:21:28 PM) tevador: I wonder if there is some good profiler for Windows where I can see exactly what the bottleneck is
(02:21:51 PM) sech1: Intel Vtune
(02:22:29 PM) tevador: does it use performance counters?
(02:22:41 PM) sech1: yes
(02:26:07 PM) tevador: I'm 80% sure the scheduler is dumb and doesn't reserve Port1 for multiplication
(02:27:42 PM) sech1: It can do it sometimes if there are other instructions in the mix
(02:27:46 PM) sech1: They can go to that port
(02:28:11 PM) sech1: whatever
(02:28:20 PM) sech1: if it's better than SquareHash we need to use it
(03:02:30 PM) tevador: especially if all ports are used
(03:53:34 PM) jwinterm left the room (quit: Quit: No Ping reply in 180 seconds.).
(04:21:07 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(04:51:23 PM) hyc: TSMC 5nm https://www.reddit.com/r/Amd/comments/b9uno8/tsmc_completes_5_nm_design_infrastructure_paving/
(05:11:50 PM) tevador: sech1: it's definitely port contention
(05:12:09 PM) sech1: ok
(05:12:14 PM) sech1: on another topic: https://imgur.com/a/QQXszHj
(05:12:57 PM) tevador: SquareHash = 30 seconds, SuperscalarHash with only NOP = 29 seconds, SuperscalarHash with only MUL (rest NOP) = 30 second, SuperscalarHash (all instructions) = 51 seconds
(05:15:29 PM) tevador: sech1: context?
(05:15:48 PM) sech1: it's from chat here https://www.youtube.com/watch?v=LFNT_6nqtdA[1] - in the very end of the video
(05:15:56 PM) tevador: which ASIC manufacturer? is it a CN/R ASIC?
(05:16:03 PM) sech1: someone trying to do CN/R ASIC
(05:17:40 PM) sech1: and looks like they're almost ready to tape out
(05:17:48 PM) sech1: or it's just someone trolling
(05:17:54 PM) tevador: so ~3 months away
(05:18:05 PM) tevador: or more likely a troll
(05:19:16 PM) sech1: CN/R was finalized on Feb 14th, so almost 2 months passed
(05:19:22 PM) sech1: enough time to do CN/R design
(05:19:49 PM) tevador: so they can expect 2-3 months of mining
(05:19:52 PM) tevador: worth it?
(05:21:21 PM) sech1: maybe, if price shoots up
(05:21:28 PM) sech1: but it won't be 128 kh/s like with CNv2
(05:21:34 PM) sech1: more like 40 kh/s or less
(05:59:18 PM) lithium_pt [~lithiumpt@185.236.201.132] entered the room.
(06:01:20 PM) lithiumpt left the room (quit: Ping timeout: 255 seconds).
(06:01:28 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:01:29 PM) moneromooo left the room (quit: Ping timeout: 246 seconds).
(06:02:20 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:02:41 PM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(06:02:51 PM) sech1 left the room (quit: Remote host closed the connection).
(06:02:52 PM) el00ruobuob_[m] left the room (quit: Remote host closed the connection).
(06:02:55 PM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(06:04:04 PM) sech11 left the room (quit: Client Quit).
(06:07:50 PM) Guest64755 [fluffypony@primary.spagni.net] entered the room.
(06:10:48 PM) Guest64755 left the room (quit: Changing host).
(06:10:48 PM) Guest64755 [fluffypony@unaffiliated/moneromooo] entered the room.
(06:10:49 PM) Guest64755 is now known as moneromooo
(06:30:31 PM) dossier [49e955be@gateway/web/cgi-irc/kiwiirc.com/ip.73.233.85.190] entered the room.
(06:32:27 PM) dossier left the room (quit: Remote host closed the connection).
(06:49:32 PM) ferretinjapan left the room (quit: Ping timeout: 244 seconds).
(06:57:25 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(06:59:45 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(07:46:12 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(08:35:06 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:57:08 PM) kico left the room (quit: Remote host closed the connection).
(11:57:31 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(12:44:53 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(01:20:33 AM) kopite7 left the room (quit: Quit: Leaving.).
(01:54:46 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:55:35 AM) crCr62U0 left the room (quit: Client Quit).
(03:00:21 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(03:01:02 AM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(03:22:58 AM) Inge- left the room (quit: Quit: leaving).
(03:30:42 AM) Inge- [~inge@ti0051a400-2085.bb.online.no] entered the room.
(04:58:28 AM) midipoet [uid316937@gateway/web/irccloud.com/x-ntzohnvthsxggvgq] entered the room.
(05:11:51 AM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(05:36:07 AM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(05:39:49 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(05:45:10 AM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(06:36:49 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:44:48 AM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(09:46:12 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(10:17:55 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:18:12 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(11:31:31 AM) midipoet [uid316937@gateway/web/irccloud.com/x-tpfktyhlnblficni] entered the room.
(12:17:52 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:32:43 PM) tevador: the problem with many multiplications is that if any register becomes 0, things go horribly wrong very quickly
(12:45:22 PM) sech1: how often does it happen?
(12:45:43 PM) sech1: CryptonightR has additions with random 32-bit constants to mitigate this
(12:51:11 PM) tevador: in SuperscalarHash, the programs are long enough to almost always end up with zeroes
(12:51:37 PM) tevador: I'm reworking the instruction set now to add some add/xor with constants
(12:52:44 PM) tevador: btw I found the reason why the CPU cannot schedule instructions efficiently in some cases
(12:52:48 PM) tevador: explained here: https://stackoverflow.com/questions/40681331/how-are-x86-uops-scheduled-exactly[1]
(12:53:04 PM) tevador: the scheduling happens *IN ORDER*
(12:53:24 PM) tevador: so you have to make sure to put multiplications first to saturate port 1, then is works
(12:54:49 PM) ferretinjapan left the room (quit: Read error: Connection reset by peer).
(12:54:55 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:07:42 PM) bearretinjapan left the room (quit: Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number).
(01:08:15 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:20:39 PM) SomaticFanatic [~SomaticFa@gateway/tor-sasl/somaticfanatic] entered the room.
(01:28:32 PM) sech1: Do you remove "sub/xor reg, reg" instructions? They are the main source of zeroes
(01:32:24 PM) hyc: interesting. xmrig-amd outperforms xmrig on my ryzen APU 2700U
(01:32:47 PM) hyc: on my Trinity APU the IGP was slower than the CPU
(01:32:49 PM) hyc: on CNv0
(01:33:39 PM) tevador: sech1: yes, sub/xor is not allowed with the same source operand
(01:34:50 PM) tevador: I saw in the debugger that the zeroes are made by repeated multiplications, the register ends with progressively longer sequences of zeroes until it's all zeroes
(01:35:35 PM) hyc: makes sense, repeated mullts are basically left-shifts
(01:37:25 PM) tevador: yes, when the multiplier is even
(01:38:12 PM) bearretinjapan is now known as ferretinjapan
(01:42:47 PM) sech1: just insert "add reg, random_number" after every 3 multiplications with "reg" as destination
(02:01:27 PM) tevador: I fixed it by forbidding a register to be multiplied twice in a row
(02:07:03 PM) tevador: the new version has even better ASIC latency: https://pastebin.com/s5AhSvwi
(02:07:24 PM) tevador: because there is one long dependency chain and several shorter ones
(02:08:30 PM) tevador: just code entropy os lower because I had to add a lot more restrictions
(02:08:38 PM) tevador: is lower*
(02:11:16 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(02:19:10 PM) sech1: btw is it a problem in main RandomX loop? Do any registers end up as 0 often?
(02:28:38 PM) tevador: RandomX loop reads from memory, so it doesn't happen there
(02:28:38 PM) el00ruobuob left the room (quit: Ping timeout: 250 seconds).
(02:29:42 PM) tevador: sech1: can you please review the generated code? https://pastebin.com/mA0g4LnX
(02:30:00 PM) tevador: multiplications come in groups of 3 to keep Port 1 saturated
(02:30:28 PM) sech1: is just an example code or it'll be set in stone?
(02:30:43 PM) tevador: example
(02:30:54 PM) tevador: each epoch will have 8 different programs
(02:31:19 PM) sech1: you combine instructions in 16-byte groups, right?
(02:31:24 PM) tevador: yes
(02:31:35 PM) tevador: no instruction crosses 16 byte boundary
(02:31:48 PM) tevador: otherwise the decoder would be a bottleneck
(02:32:41 PM) sech1: and always 4 instructions per 16 bytes?
(02:33:20 PM) tevador: sometimes only 3 fit
(02:33:26 PM) tevador: or 3 + nop
(02:35:44 PM) sech1: imul are always first in each group, so they shouldn't be stalled because of wrong port scheduling
(02:36:20 PM) tevador: yes, the solution to bad scheduling is to overschedule muls so port 1 is never free for other ops
(02:39:20 PM) sech1: line 274 "mov r13, rdx"
(02:39:32 PM) sech1: not sure where it comes from, there is nothing changing rdx nearby
(02:40:07 PM) sech1: rdx is only changed by mul at line 242
(02:40:56 PM) sech1: no, wait
(02:41:06 PM) sech1: imul at line 273 is 64x64->128?
(02:42:25 PM) sech1: overall, not bad
(02:43:10 PM) sech1: I'm curious how much faster can it run if written as C code and compiled by GCC with all optimizations and with "-march=native"
(02:43:23 PM) sech1: because it'll be fixed per epoch
(02:43:42 PM) sech1: so we (and ASIC) can throw all the fancy compiler optimizations at it
(02:54:01 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(03:17:17 PM) [-mugatu-] is now known as gsp
(03:17:36 PM) gsp is now known as [-mugatu-]
(03:24:21 PM) SomaticFanatic left the room (quit: Ping timeout: 256 seconds).
(04:10:34 PM) tevador: I think optimizations should be limited
(04:11:34 PM) tevador: is there some assembly optimizer?
(04:12:41 PM) sech1: GCC has instruction-level optimizer, but you still have to start with C code
(04:14:13 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(04:17:18 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:18:40 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:27:14 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(04:38:52 PM) tevador: it should be trivial to generate C code for these programs
(05:15:27 PM) tevador: hyc: good work about the solo mining support, I'd like to have it also for RandomX miners
(05:25:33 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:46:56 PM) hyc: yes I think it's an important part of our decentralization story
(05:52:46 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:54:22 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:10:24 PM) tevador: sech1: I tested it with the GCC 8 optimizer
(06:11:15 PM) tevador: the compiler can do move elimination and also some constants are changed, but overall it's 50 more instructions than my asm generator
(06:13:16 PM) bearretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:17:22 PM) sech1: And what's the actual performance on CPU?
(06:18:36 PM) tevador: correction: constants are unchanged, just the order of operations is changed and ror is sometimes changed to rol
(06:19:27 PM) tevador: haven't run actual benchmarks yet
(06:19:38 PM) tevador: I don't see why it would be faster
(06:19:54 PM) tevador: want to see the code?
(06:21:51 PM) tevador: compiler thinks it is smart by optimizing lea r11, [r11+r10*4]; add r11, -1890012073 to lea rcx, [r10-1890012073+r13*4]
(06:22:08 PM) tevador: except this lea will need port 1, which is occupied by multiplications
(06:23:00 PM) tevador: and I did -march=ivybridge
(06:36:30 PM) sech1: Compiler sometimes generated faster code when I was testing CN/R
(06:40:49 PM) sech1 left the room (quit: Quit: Leaving).
(06:44:11 PM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(06:46:02 PM) sech1: on the other hand, if you achieve 1 multiplication/cycle, it can't be possibly faster
(06:46:25 PM) sech1: "Execution time: 173 cycles; Multiplications: 147" almost there
(06:55:06 PM) tevador: sometimes it's up to 160
(06:56:14 PM) tevador: I decreased it from 1 mul/cycle due to the zeroing problems
(06:56:43 PM) tevador: to have sufficient number of ops in between for each register
(06:58:07 PM) tevador: it's probably possible to increase it, but this must be enough... I have spent more than a week on this 
(07:02:40 PM) sech1: yes, I think compiler optimizations won't help here
(07:03:44 PM) sech1 left the room (quit: Quit: Leaving).
(07:36:18 PM) ArticMine left the room (quit: Ping timeout: 250 seconds).
(07:49:07 PM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(08:11:24 PM) Coupe420 left the room (quit: Ping timeout: 250 seconds).
(08:28:12 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(10:21:59 PM) Tom_Cruise left the room (quit: Read error: Connection reset by peer).
(10:22:18 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(01:15:40 AM) investanto left the room (quit: Quit: Changing servers).
(01:15:52 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(02:11:14 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:11:50 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:47:30 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(03:42:06 AM) midipoet [uid316937@gateway/web/irccloud.com/x-yxeziqygkeaxeobg] entered the room.
(03:49:34 AM) hyc: there's definitely a memory leak in AMD OpenCL libs
(03:49:50 AM) hyc: or xmrig-amd isn't calling some cleanups that it ought to
(03:50:02 AM) el00ruobuob [~el00ruobu@blabour.fr] entered the room.
(03:52:10 AM) sech1: yes there is
(03:53:12 AM) sech1: the leak is inside clBuildProgram
(03:53:25 AM) sech1: old drivers have it, newer drivers (19.3.1) are ok
(03:53:48 AM) sech1: this is why I added this as a mitigation: https://github.com/xmrig/xmrig-amd/pull/249[1]
(03:54:46 AM) hyc: hm that's not in master yet? mine crashed after about 8-9 hours
(03:55:06 AM) sech1: it's in dev branch
(03:55:13 AM) hyc: ok
(03:55:33 AM) sech1: there was an actual leak in xmrig-amd, but it's fixed in master: https://github.com/xmrig/xmrig-amd/commit/4378a0c27f217cb6bb7c6e9d250303154d4bf0a4[1]
(03:56:50 AM) hyc: cool
(03:57:14 AM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(03:57:33 AM) hyc: yeah my leak tracer isn't showing anything in xmrig itself right now
(03:59:25 AM) hyc: 19.3.1? I'm using the OpenCL libs from amdgpu-pro-18.50
(04:00:16 AM) sech1: 19.3.1 is Windows driver
(04:00:20 AM) hyc: ah ok
(04:00:24 AM) hyc: this is ubuntu
(05:34:06 AM) investanto left the room (quit: Quit: Changing servers).
(05:34:19 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(05:34:44 AM) tevador: sech1: I have tested the optimizer (200M iterations): manual assembly: 17.9 seconds, compiled with msvc: 18.8 seconds
(05:34:48 AM) tevador: so compiler is slower
(05:35:58 AM) sech1: Nice! Hand-crafted assembly is always faster, just wanted to make sure there are no arithmetic optimizations left.
(05:41:30 AM) sech1: It's also important that we can squeeze every last bit of performance out of x86 CPU in verification mode
(05:41:37 AM) sech1: Single-chip ASIC is no longer viable
(06:01:27 AM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(06:25:58 AM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(06:26:01 AM) sech11 left the room (quit: Remote host closed the connection).
(06:26:43 AM) sech1 left the room (quit: Ping timeout: 245 seconds).
(07:18:54 AM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(07:29:32 AM) bearretinjapan is now known as ferretinjapan
(07:57:54 AM) antanst left the room (quit: Quit: The Lounge - https://thelounge.chat).
(07:58:08 AM) ferretinjapan left the room (quit: Ping timeout: 252 seconds).
(08:09:23 AM) antanst [~antanst@62.169.219.213] entered the room.
(08:10:40 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(09:16:04 AM) tevador: good news, light verification time is the same with SuperscalarHash
(09:16:20 AM) tevador: currently with an average of 156 multiplications per program
(09:17:32 AM) tevador: average ASIC latency = 92.4 cycles
(09:23:29 AM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(09:25:52 AM) el00ruobuob left the room (quit: Ping timeout: 245 seconds).
(09:39:49 AM) vp11: https://www.reddit.com/r/Monero/comments/bafpce/randomx_opcodes/[1]
(09:40:03 AM) vp11: if someone wants to answer the person
(09:46:21 AM) hyc: sigh. since there is working code, clearly the mapping of bytes to opcodes exists and is in the same repo as the specs document
(09:46:45 AM) hyc: people who can't think for themselves really bug me
(10:09:35 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:07:13 AM) sech1: tevador this is awesome news, does Superscalar hash produce random enough results? No zeroes anymore? Is there a documentation decribing how dataset is generated with it?
(11:13:39 AM) tevador: sech1: no zeroes anymore, it looks random - I could do a more detailed statistical analysis if needed
(11:14:04 AM) tevador: documentation is not ready yet, everything is provisional
(11:14:13 AM) tevador: also the code needs refactoring... but it works
(11:16:54 AM) tevador: the 8 registers are intialized using this: https://github.com/tevador/RandomX/blob/feature/light-code-gen/src/JitCompilerX86-static.asm#L180[1]
(11:17:40 AM) tevador: it's one step of a linear generator (a*x+1) and the rest is simply a xor...
(11:17:56 AM) tevador: then 8 chained programs
(11:18:54 AM) tevador: one register from each program serves as the address for the next cache load
(11:18:58 AM) tevador: similar to the old scheme
(11:19:38 AM) sech1: No, I'm asking about generated 2 GB dataset - does it pass http://simul.iro.umontreal.ca/testu01/tu01.html[1] for example?
(11:19:46 AM) sech1: it should pass all randomness tests
(11:20:14 AM) sech1: One more test I always use is try to compress it with 7-zip at the best compression level. If it's not compressible then it's good
(11:22:46 AM) tevador: no, we need to test SuperscalarHash separately, dataset contained mixed data from the cache
(11:22:53 AM) tevador: contains*
(11:23:02 AM) tevador: cache is Blake2b, so pseudorandom
(11:23:46 AM) tevador: we need at least strict avalanche I think
(11:24:11 AM) tevador: mean 1 flipped bit will change all other bits with ~50% chance
(11:25:43 AM) tevador: even when there was the bug and all registers collapsed to 0, dataset was still random due to the last cache access mixing in random data
(11:26:16 AM) sech1: yes, so it's something for upcomfing audits to look at
(11:45:11 AM) midipoet [uid316937@gateway/web/irccloud.com/x-lkjmdxcnotvxyzkn] entered the room.
(12:46:42 PM) SomaticFanatic [~SomaticFa@gateway/tor-sasl/somaticfanatic] entered the room.
(12:59:11 PM) SomaticFanatic left the room (quit: Ping timeout: 256 seconds).
(01:28:05 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(01:29:37 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(01:53:55 PM) hyc: re: undervolting on Linux, https://www.reddit.com/r/Amd/comments/b9ymst/are_ryzen_laptops_any_good/ek840sw/
(01:54:09 PM) hyc: senstates-linux, and wattmanGTK
(01:54:13 PM) hyc: zenstates
(02:03:29 PM) bearretinjapan is now known as ferretinjapan
(02:12:36 PM) tevador: sech1: https://github.com/tevador/RandomX/issues/34[1]
(02:13:07 PM) tevador: is there a better solution?
(02:15:52 PM) sech1: if it doesn't slow down RandomX mining mode, why not
(02:17:34 PM) sech1: on the other hand, it can also be optimized for CPU when generating x86 code
(02:17:38 PM) tevador: haven't tested, but there should be enough room in the pipeline to accomodate one extra addition
(02:18:25 PM) sech1: "Same thing happens with store operations, in which case the first ISTORE instruction can be optimized away." -> only if there is no load between them
(02:18:52 PM) sech1: I think one extra addition is better solution. More stuff to do for ASIC
(02:19:29 PM) hyc: lea uses address generation unit, isn't that independent of ALU?
(02:19:58 PM) sech1: If CPU execution ports are underutilized, adding more stuff without slowing down CPU improves ASIC resistance
(02:20:16 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(02:21:38 PM) sech1: hyc lea reg1, [reg2+C] goes to ports 1 and 5 on Skylake CPU which are regular ALU ports
(02:21:46 PM) moneromooo: Is there any thought given to whether a particular change hurts ASICs more than it hurts CPUs which are not the particular one you're trying to target ?
(02:21:47 PM) sech1: there is no dedicated AGU there
(02:22:31 PM) sech1: moneromooo this particular change is neutral (power-wise)
(02:22:41 PM) sech1: ASIC and CPU will spend the same power calculating the result
(02:23:05 PM) sech1: but if CPU doesn't slow down because it has enough execution resources, it's a win
(02:23:25 PM) moneromooo: I feel my point was missed.
(02:23:34 PM) moneromooo: I'll try to rephrase.
(02:24:30 PM) moneromooo: While I am not faimilar with the details of modern CPU arhitecture, you seem to be trying to tie execution to a very particular configuration of ports.
(02:25:01 PM) sech1: Well, we have to target something most widespread
(02:25:09 PM) moneromooo: A change which makes this CPU run the hash better might make another common CPU run the hash worse. 
(02:25:09 PM) sech1: which turns out to be Intel CPUs now
(02:25:38 PM) sech1: This change actually favors AMD Ryzen a bit more than Intel CPUs
(02:25:40 PM) hyc: other chips have looser constraints, I think. even AMD bulldozer had at least 3 execution ports, most modern chips now have more
(02:25:41 PM) moneromooo: My point is whether any thought was given to how the expected average CPU does, compared to a hypothetical ASIC.
(02:26:43 PM) moneromooo: By "the expected average CPU", I mean weighted by how useful they are a priori of couse.
(02:27:02 PM) sech1: But we've been tuning RandomX for "the expected average CPU" the whole time
(02:27:11 PM) hyc: indeed
(02:27:15 PM) sech1: Intel CPUs didn't change much since Sandy Bridge (2011)
(02:27:31 PM) sech1: Ryzen behaves very similarly to Intel CPUs now
(02:27:33 PM) moneromooo: In the extreme, you gain 1% perf on the target CPU, ASIC stays the same, but it's actually a loss since the other CPUs lose 10%. That kind of thing.
(02:27:35 PM) hyc: and AMD has gained popularity recently, but is still outnumbered by Intel in the field
(02:28:02 PM) sech1: I mean optimizations for Ryzen also do well on Intel CPUs and vice versa
(02:28:07 PM) moneromooo: I think "But we've been tuning RandomX for "the expected average CPU" the whole time" means "yes". Thanks.
(02:45:02 PM) tevador: yes, RandomX optimizations generally target Intel SandyBridge/IvyBridge or newer and AMD Ryzen
(02:45:21 PM) tevador: I think that includes the vast majority of currently used CPUs
(02:50:11 PM) tevador: hyc: actually Bulldozer has only 2 ALUs per core, one of the reasons for its poor performance
(03:00:31 PM) sech1: I don't see a problem here. Bulldozer is 2 times slower than Ryzen in most computing tasks and it's also 2 times slower in RandomX: Opteron 6274 (8 core modules) does 1770 H/s
(03:01:12 PM) sech1: https://github.com/tevador/RandomX/issues/25#issuecomment-468789587[1]
(03:02:07 PM) hyc: sure, no problems
(03:05:38 PM) wowario left the room (quit: Remote host closed the connection).
(03:06:00 PM) wowario [~wowario@gateway/tor-sasl/wowario] entered the room.
(03:54:25 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(04:04:52 PM) Tom_Cruise left the room (quit: Read error: Connection reset by peer).
(04:05:20 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(06:36:42 PM) sech1 left the room (quit: Quit: Leaving).
(06:37:57 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(07:02:02 PM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(07:22:36 PM) Tom_Cruise [~Tom@47-33-89-35.dhcp.rvsd.ca.charter.com] entered the room.
(07:31:04 PM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(07:43:49 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(08:11:48 PM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(08:20:42 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(08:26:42 PM) Tom_Cruise left the room (quit: Ping timeout: 245 seconds).
(09:41:39 PM) kico left the room (quit: Ping timeout: 256 seconds).
(09:51:16 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(09:58:05 PM) kico left the room (quit: Ping timeout: 256 seconds).
(10:10:55 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:12:44 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:17:39 PM) Tom_Cruise left the room (quit: Ping timeout: 244 seconds).
(10:18:11 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:24:04 PM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(10:25:07 PM) Tom_Cruise [~Tom@cpe-24-24-133-238.socal.res.rr.com] entered the room.
(12:34:58 AM) zone117x [sid117212@gateway/web/irccloud.com/x-dqqwzpcvqsclmkzu] entered the room.
(01:00:22 AM) kico left the room (quit: Remote host closed the connection).
(01:00:45 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(01:24:04 AM) investanto left the room (quit: Quit: Changing servers).
(01:24:15 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:36:20 AM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(01:36:22 AM) [-mugatu-] left the room (quit: Ping timeout: 250 seconds).
(02:13:10 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:25:12 AM) sech1 left the room (quit: Quit: Leaving).
(02:46:43 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(02:48:11 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:38:41 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:33:13 AM) ArticMine left the room (quit: Ping timeout: 250 seconds).
(04:36:15 AM) midipoet [uid316937@gateway/web/irccloud.com/x-teceipydbjndgqlq] entered the room.
(04:53:53 AM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(05:20:50 AM) cryptodonkey left the room (quit: Ping timeout: 250 seconds).
(05:22:21 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(05:23:04 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(05:24:02 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:29:02 AM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(05:41:39 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:53:16 AM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(06:03:46 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(06:08:01 AM) Tom_Cruise left the room (quit: Ping timeout: 252 seconds).
(07:16:45 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(07:21:30 AM) Tom_Cruise left the room (quit: Ping timeout: 258 seconds).
(08:09:33 AM) sech1: tevador asmCode << "xchg ax, ax ;nop" << std::endl;
(08:09:37 AM) sech1: is it multi-byte nop?
(08:10:12 AM) sech1: use "db 0Fh, 1Fh 00h" for 3-byte nop
(08:10:32 AM) sech1: and "db 0Fh, 1Fh, 40h, 00h" for 4-byte nop
(08:10:37 AM) sech1: https://www.felixcloutier.com/x86/nop[1]
(08:40:54 AM) sech1: "Register f0 is XORed with register e0 and the result is stored in register f0" This doesn't look safe. Mantissa bits will be biased to 0 after XOR
(08:41:03 AM) sech1: so scratchpad will have more zeroes than usual
(08:41:24 AM) sech1: I mean exponent bits
(08:41:51 AM) sech1: It's better to swap low and high 32 bits in one of registers before XORing
(08:42:38 AM) sech1: Low 32 bits have higher entropy and we won't end up XORing exponent bits from two registers
(08:42:44 AM) sech1: pshufd instruction can be used to do this
(08:44:07 AM) sech1: use pshufd on f0 to swap bits 0-31 with bits 32-63 and bits 64-95 with bits 96-127
(10:42:25 AM) kico left the room (quit: Remote host closed the connection).
(10:42:51 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(10:53:39 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:56:41 AM) sech1 left the room (quit: Quit: Leaving).
(10:57:47 AM) Tom_Cruise left the room (quit: Ping timeout: 240 seconds).
(10:59:59 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:17:24 AM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(11:22:51 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:30:03 AM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(11:45:12 AM) Coupe420 left the room (quit: Ping timeout: 268 seconds).
(11:55:01 AM) ferretinjapan left the room (quit: Ping timeout: 244 seconds).
(12:07:09 PM) el00ruobuob_[m] left the room (quit: Ping timeout: 252 seconds).
(12:08:12 PM) ferretinjapan [~ferretinj@unaffiliated/ferretinjapan] entered the room.
(12:10:26 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(12:13:32 PM) bearretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(12:14:37 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(12:15:09 PM) Tom_Cruise left the room (quit: Ping timeout: 255 seconds).
(12:19:29 PM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(12:39:38 PM) bearretinjapan is now known as ferretinjapan
(12:39:57 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:37:30 PM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(02:12:11 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(02:13:47 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(02:20:37 PM) OhGodAGirl_ left the room (quit: Ping timeout: 252 seconds).
(02:20:54 PM) luigi1111 left the room (quit: Read error: Connection reset by peer).
(02:20:55 PM) endogenic left the room (quit: Read error: Connection reset by peer).
(02:20:55 PM) selsta left the room (quit: Read error: Connection reset by peer).
(02:21:09 PM) selsta [sid124829@gateway/web/irccloud.com/x-pxajqtfnvjrvjwug] entered the room.
(02:21:14 PM) luigi1111 [sid85934@gateway/web/irccloud.com/x-drchrdsxoetpskdk] entered the room.
(02:21:15 PM) endogenic [sid145991@gateway/web/irccloud.com/x-tacaawyiiyyhskfz] entered the room.
(02:21:21 PM) OhGodAGirl_ [sid164689@gateway/web/irccloud.com/x-mtyhjfecxbaoqtvp] entered the room.
(02:40:04 PM) tevador: sech1: it's a 2-byte nop: 0x66 0x90
(02:40:21 PM) tevador: sech1: correct, about 6 bits of the exponent have low entropy
(02:41:12 PM) tevador: I guess we could do 4 shuffles per iteration, but I wanted to avoid fixed operations that are very cheap for an ASIC
(02:42:55 PM) tevador: btw 2048 KiB scratchpad compresses to 2072 KiB with 7-zip (Ultra compression level)
(02:44:00 PM) tevador: 'compresses'
(02:50:20 PM) hyc: lol
(02:50:25 PM) sech1: I guess it's a minor issue then
(02:50:45 PM) sech1: Compresses to 2072 KiB after all 8 programs are done?
(02:50:47 PM) hyc: talk about a newbie compressor error. 
(02:51:13 PM) hyc: we figured out to detect when compressed size is > original size and do nothing, ~30+ years ago
(02:51:24 PM) hyc: bad 7-zip...
(02:52:28 PM) hyc: have you tried bzip2? might be a bit more sane, should also achieve no compression
(03:06:41 PM) tevador: sech1: yes, this is the final scratchpad
(03:07:12 PM) tevador: the XOR doesn't actually produce zeroes because the exponents of group F and group E registers are somewhat decorrelated
(03:08:31 PM) tevador: hyc: bzip2 2052 KiB
(03:08:46 PM) tevador: 2054*
(03:09:29 PM) tevador: 2072 was with LZMA
(03:09:36 PM) tevador: LZMA2 does 2049 KiB
(03:09:39 PM) tevador: almost
(03:11:23 PM) hyc: that all sounds good. uncompressible, with just a difference in how large a standard metadata header they each prepend.
(03:12:58 PM) tevador: they could just have a 1 bit flag in the header that says 'uncompressed' in cases like this
(03:14:52 PM) hyc: yes, that's essentially what gzip does
(03:17:19 PM) tevador: I will dump the dataset and try compressing it
(03:20:02 PM) tevador: LZMA2, Ultra, 4 cores
(03:20:08 PM) tevador: gonna take a while maybe
(03:20:36 PM) hyc: 2GB? yeah could be a while
(03:20:50 PM) tevador: shows 5 MB/s
(03:20:57 PM) hyc: run it under /usr/bin/time -v
(03:21:08 PM) hyc: see how much RAM and CPU it uses
(03:21:28 PM) tevador: RAM ~2260 MBB
(03:21:46 PM) tevador: CPU - all 4 cores
(03:22:16 PM) tevador: actually only about 70% usage
(03:22:33 PM) hyc: usually a compressor uses a small window like 64KB that moves along the input. I suppose in Ultra it may try to analyze the entire input
(03:22:59 PM) tevador: yes, Ultra selects a 4 GB windows, or the file size, whichever is smaller
(03:23:16 PM) tevador: so 2 GB window in this case
(03:26:31 PM) tevador: finished: 2 147 597 683 bytes
(03:26:59 PM) tevador: so roughly 100 KiB overhead
(03:27:02 PM) hyc: great
(03:27:15 PM) hyc: it must still be writing chunks with per-chunk headers
(04:30:54 PM) spaced0ut left the room (quit: Quit: Leaving).
(04:32:34 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:54:00 PM) vp11: do we have some rough consensus or any idea for when randomx should be implemented on mainnet? are you aiming for the next hardfork?
(04:54:25 PM) hyc: that's the aim, yes
(04:54:55 PM) hyc: moneromooo seems to be holding out for one more tweak to CN/R before, but we might be able to talk him out of that
(04:55:24 PM) moneromooo: It will depend on whether it's just about ready, or ready ready.
(04:55:48 PM) hyc: code freeze will be April 30. we have one proposal for code review from Kudelski
(04:55:52 PM) moneromooo: And no, I don't really have any objective criteria for that :)
(04:56:16 PM) vp11: is there anything to gain by aiming on this october? wouldn't be better to play this one more conservatively and aim for 2020? get some more time to scrutinize the algo, maybe get some funding to do some audits?
(04:56:36 PM) hyc: even if they find any problems in review, we have plenty of time to fix before OCtober
(04:58:55 PM) vp11: for bulletproofs we raised some money for audits via the CCS. would it be a good idea for RandomX? is it even possible? I imagine that there aren't that many institutions specialized in proof of work algorithms, hehe
(04:59:12 PM) cryptodonkey [~cryptodon@yunohost-arm64-6c.11c8.cloud] entered the room.
(04:59:22 PM) hyc: I assumed we would do CCS again. we don't have kudelski's price yet.
(05:00:08 PM) hyc: we also asked another team, and got no response. so, so far, only 1 reviewer team.
(05:00:16 PM) moneromooo: Did you ask Quarkslab ?
(05:00:20 PM) vp11: yes, I mean, apart from Kudelski
(05:00:21 PM) Letres [4009f79a@gateway/web/freenode/ip.64.9.247.154] entered the room.
(05:00:44 PM) hyc: yes, asked quarkslab, no answer
(05:01:26 PM) Letres: I've been trying to make a (shitty) implementation of random x to do some testing on internal values
(05:01:26 PM) hyc: in contrast, the kudelski folks are very eager to do the audit, they seem to have a keen interest in PoW right now
(05:01:59 PM) Letres: How is argon called with a 0 output size
(05:04:22 PM) antanst8 [~antanst@62.169.219.213] entered the room.
(05:04:31 PM) antanst left the room (quit: Ping timeout: 252 seconds).
(05:08:51 PM) Letres: Since the memory fill is based on a variable hash unless the Argon2 spec PDF is wrong
(05:12:03 PM) tevador: Letres: Argon2 normally fills the intenal array and then outputs a hash value of selected length
(05:12:16 PM) tevador: RandomX stops the process when the internal array is filled
(05:12:23 PM) tevador: no final hash
(05:13:19 PM) tevador: you have to remove everyhing that comes after the call to fill_memory_blocks
(05:14:35 PM) Letres: So it's calling H' with Tau set to both 0 and 64
(05:15:06 PM) tevador: no, the 0 is used only for the final hash
(05:15:16 PM) tevador: otherwise Argon uses always 64 byte output
(05:15:51 PM) tevador: actually we could use any value as the output length since the output step is skipped, but I felt like 0 makes sense in this case
(05:16:34 PM) tevador: you have to select output length even if you don't output anything because it's part of the initial block hash
(05:16:51 PM) Letres: Okay
(05:23:10 PM) Letres: Thank you for that tho
(05:40:14 PM) Letres: The wiki article has it done correctly :(
(05:56:05 PM) Letres left the room (quit: Ping timeout: 256 seconds).
(06:27:38 PM) Letres [4009f79a@gateway/web/freenode/ip.64.9.247.154] entered the room.
(06:29:23 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(06:39:09 PM) Letres left the room (quit: Ping timeout: 256 seconds).
(07:00:43 PM) sech1 left the room (quit: Quit: Leaving).
(07:12:45 PM) Tom_Cruise left the room (quit: Ping timeout: 255 seconds).
(08:03:44 PM) Letres [49751e06@gateway/web/freenode/ip.73.117.30.6] entered the room.
(09:11:46 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:51:56 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:05:09 PM) Tom_Crui_ [~Tom@cpe-24-24-133-238.socal.res.rr.com] entered the room.
(10:07:54 PM) Tom_Cruise left the room (quit: Ping timeout: 250 seconds).
(12:53:35 AM) CommonDeer [~CommonDee@14-202-132-82.static.tpgi.com.au] entered the room.
(12:53:43 AM) Letres left the room (quit: Ping timeout: 256 seconds).
(01:08:29 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:18:25 AM) kopite7 left the room (quit: Quit: Leaving.).
(02:12:34 AM) Tom_Crui_ left the room (quit: Ping timeout: 246 seconds).
(02:26:54 AM) kicoo [~kico@gateway/tor-sasl/kico] entered the room.
(02:27:19 AM) kico left the room (quit: Remote host closed the connection).
(02:55:47 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(03:06:03 AM) sech1 left the room (quit: Quit: Leaving).
(03:12:57 AM) Common-Deer [~CommonDee@14-202-132-82.static.tpgi.com.au] entered the room.
(03:15:00 AM) lithium_pt left the room (quit: Quit: ZNC 1.7.2 - https://znc.in).
(03:15:02 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:15:04 AM) lithiumpt [~lithiumpt@185.236.201.132] entered the room.
(03:15:55 AM) CommonDeer left the room (quit: Ping timeout: 246 seconds).
(04:20:52 AM) kicoo is now known as kico
(04:44:48 AM) investanto left the room (quit: Quit: Changing servers).
(04:44:59 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(04:52:02 AM) midipoet [uid316937@gateway/web/irccloud.com/x-mkunmgfoxmojlvaa] entered the room.
(05:05:28 AM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(06:44:07 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(07:38:10 AM) lsdog left the room (quit: Ping timeout: 250 seconds).
(08:06:20 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(08:13:02 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(08:19:38 AM) ferretinjapan is now known as bearretinjapan
(09:12:37 AM) sech1: tevador I'm concerned about FDIV_M instruction. It uses 32-bit signed integers as divisors, so lowest 22 bits are 0 in FP64 format. ASIC can use 53:31 bit divider which is simpler and faster than 53:53 bit divider.
(09:13:36 AM) sech1: I also noticed that RandomX uses register xmm14 only in combination with FDIV_M, so we can easily fill these 22 bits with some random values in xmm14
(09:30:08 AM) sech1: Or maybe we can just convert 64-bit integer and duplicate it to both halves of the register. It'll also enforce current rounding mode when converting to FP64.
(09:30:38 AM) sech1: I mean it'll make ASIC use current rounding mode because 32-bit integer conversion doesn't require rounding.
(09:33:13 AM) sech1: No, it's a bad idea. ASIC can optimize common parts when divisor is the same. It's better do have different divisors, but with full 53 bits of precision.
(09:33:59 AM) midipoet: slightly off-topic:
(09:34:00 AM) midipoet: https://www.reuters.com/article/us-china-cryptocurrency/china-says-it-wants-to-eliminate-bitcoin-mining-idUSKCN1RL0C4?feedType=RSS&feedName=businessNews&utm_source=reddit.com[1]
(09:38:08 AM) spaced0ut [~spaced0ut@unaffiliated/spaced0ut] entered the room.
(09:40:16 AM) investanto left the room (quit: Quit: Quitting...).
(09:40:32 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:59:20 AM) Letres [49751e06@gateway/web/freenode/ip.73.117.30.6] entered the room.
(10:06:00 AM) Letres: This entire thing is really beautiful ngl
(10:30:11 AM) el00ruobuob_[m] [~el00ruobu@37.169.254.231] entered the room.
(10:47:07 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(10:59:24 AM) jwinterm left the room (quit: Ping timeout: 252 seconds).
(11:01:24 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:02:59 AM) sech1 left the room (quit: Quit: Leaving).
(11:13:46 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(11:17:26 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:50:45 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(11:51:05 AM) Letres: Are there any test vectors for the custom functions?
(11:54:30 AM) jwinterm left the room (quit: Ping timeout: 264 seconds).
(11:58:25 AM) kopite7 left the room (quit: Quit: Leaving.).
(12:39:06 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(12:47:23 PM) kopite7 [~kmaneshni@gateway/shell/openbmc/x-csyegwzrudydyxln] entered the room.
(01:01:55 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(01:12:44 PM) sech1: tevador hyc Are there RandomX build instructions for Windows somewhere?
(01:13:04 PM) hyc: notthat I know of
(01:13:19 PM) sech1: There is no clear way to build it
(01:13:24 PM) sech1: No Visual Studio project
(01:13:29 PM) sech1: makefile is for linux
(01:13:41 PM) sech1: tried building it in msys64, nope - crashes in jit
(01:14:03 PM) hyc: hmmm. might need to adapt JIT to MS ABI, calling convention
(01:14:45 PM) sech1: but there is Windows binary in https://github.com/tevador/RandomX/releases[1]
(01:15:29 PM) hyc: mebbe built in msds with different gcc version...
(01:15:32 PM) hyc: msys
(01:16:26 PM) sech1: it's built in Visual Studio
(01:16:37 PM) Letres left the room (quit: Ping timeout: 256 seconds).
(01:22:41 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:22:51 PM) sech1: I had to force-change ABI to sysv_abi in a few places to make it work with msys64 on Windows
(01:25:04 PM) p0nziph0ne [p0nziph0ne@gateway/vpn/privateinternetaccess/p0nziph0ne] entered the room.
(01:39:13 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(01:50:19 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:46:51 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(02:47:01 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(02:50:59 PM) smauginjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:52:39 PM) bearretinjapan left the room (quit: Ping timeout: 255 seconds).
(03:20:00 PM) tevador: sech1: yes, we could put something in the lowest 22 bits of xmm14, good idea
(03:20:07 PM) tevador: would a constant be enough?
(03:20:49 PM) sech1: Why constant? We can change it with every program
(03:21:14 PM) tevador: ok
(03:21:27 PM) sech1: just double check it's 22 bits and not 21 or 20
(03:22:59 PM) tevador: I can push a msvc project file also
(03:28:04 PM) tevador: yes, it's 22 bits, 31 bits are needed for int and 1 bit is implicit in FP, 52-30=22
(03:33:34 PM) tevador: xmm14 is also used at the beginning of the loop for all F registers, but that's not an issue: https://github.com/tevador/RandomX/blob/master/src/asm/program_loop_load.inc[1]
(03:33:44 PM) tevador: E* registers
(03:35:58 PM) midipoet [uid316937@gateway/web/irccloud.com/x-orrhelmzujitibnj] entered the room.
(03:36:21 PM) smauginjapan is now known as ferretinjapan
(04:04:35 PM) p0nziph0ne left the room (quit: Quit: Leaving).
(04:05:01 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(04:10:49 PM) fort3hlulz left the room (quit: Ping timeout: 268 seconds).
(04:39:37 PM) sech1: It won't hurt if E registers have random 22 bits too
(04:40:25 PM) sech1: btw why FDIV_M sets exponent to 2^-240?
(04:40:43 PM) sech1: and 2^-240 for E registers too
(04:41:33 PM) tevador: 1) to avoid 0 2) to increase the range of E registers
(04:41:58 PM) tevador: -240 means there can be 5 divisions before overflow
(04:42:32 PM) sech1: but what if program has more than 5 divisions?
(04:42:52 PM) tevador: low chance that all divisions use the same register
(04:43:05 PM) tevador: and sqrt will halve the exponent
(04:43:27 PM) tevador: but there is a nonzero chance of overflow, so ASIC must also support it
(04:43:40 PM) sech1: so it can still happen in theory
(04:43:53 PM) sech1: Does spec describe how RandomX behaves in this case?
(04:44:09 PM) sech1: it's a grey area in IEEE-754
(04:44:11 PM) tevador: inifnity is a perfectly valid value
(04:44:19 PM) tevador: infinity*
(04:44:37 PM) tevador: not a gray area, the binary encoding of infinity is specified
(04:44:44 PM) sech1: inf/inf=NaN and NaN doesn't have unique representation
(04:45:07 PM) tevador: except the register can never be used as a divisor
(04:45:26 PM) tevador: that's why all FP operations use A registers as the source operands
(04:46:27 PM) tevador: all FP operations in RandomX are either: F += A, F += mem, F -= A, F -= mem, E *= A, E /= mem, E = sqrt(E)
(04:47:29 PM) sech1: hmm
(04:47:46 PM) sech1: it means there are literally no inter-dependencies between FP registers
(04:47:55 PM) tevador: otherwise you cannot avoid NaN
(04:48:02 PM) tevador: and overflow/underflow
(04:48:11 PM) tevador: yes, no interdependencies
(04:48:22 PM) sech1: I guess it doesn't matter much. It can all be done in parallel on ASIC, but power will be roughly the same
(04:48:50 PM) tevador: each register has its own dependency chain
(04:50:01 PM) sech1: "F += A, F += mem, F -= A, F -= mem" I have a strong feeling this can be optimized in most cases
(04:50:10 PM) sech1: two consecutive additions with A registers for example
(04:51:03 PM) tevador: how would you optimize it?
(04:51:08 PM) tevador: FP is not associative
(04:51:31 PM) sech1: oh, forgot about it
(04:51:39 PM) sech1: yes, rounding breaks arithmetic optimizations
(04:51:42 PM) tevador: F += A1; F += A2 is not F += (A1 + A2)
(04:52:03 PM) tevador: plus rounding mode can change in between
(04:53:26 PM) tevador: that's the 'beauty' of floating point
(04:56:10 PM) sech1: Nice. So the only thing missing is 22 low bits for divisor to force 53:53 bit divider in ASIC.
(04:58:35 PM) tevador: yes I missed that optimization
(04:58:50 PM) tevador: first I need to finish the new dataset initialization
(04:58:57 PM) tevador: now I'm making an interpreter
(04:59:22 PM) tevador: I think a fully interpreted hash will take more than 1 second
(04:59:23 PM) tevador: lol
(05:01:59 PM) tevador: 650 ms per hash, not bad
(05:04:05 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(05:06:29 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1003::249] entered the room.
(05:09:38 PM) fort3hlulz left the room (quit: Ping timeout: 245 seconds).
(05:14:26 PM) kico left the room (quit: Remote host closed the connection).
(05:14:49 PM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(05:24:34 PM) sech1: "650 ms per hash, not bad" poor web miners, lol
(05:37:59 PM) fort3hlulz_ left the room (quit: Quit: Leaving).
(05:38:41 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1003::249] entered the room.
(05:50:13 PM) spaced0ut left the room (quit: Quit: Leaving).
(05:54:32 PM) sech1 left the room (quit: Quit: Leaving).
(06:18:45 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(06:27:47 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(06:56:09 PM) hyc: interesting bit on breaking up botnets https://twitter.com/maddiestone/status/1115584640977444866
(06:56:32 PM) hyc: if you have a botnet targeting Android devices, google will hunt you down and destroy it
(06:56:43 PM) hyc: Microsoft should have been so pro-active.
(07:01:13 PM) moneromooo: Too busy hunting and destroying DRDOS, Lotus, Borland, linux, nokia, Netscape...
(07:02:03 PM) hyc: lol
(07:02:38 PM) moneromooo: Are you happy with 5400 btw ?
(07:04:41 PM) hyc: yeah it looks ok to me with that one read to write fixed
(07:04:57 PM) moneromooo: Cool, thanks.
(07:05:54 PM) hyc: back to -dev
(07:42:11 PM) kopite7 left the room (quit: Quit: Leaving.).
(07:47:57 PM) ferretinjapan left the room (quit: Ping timeout: 245 seconds).
(08:23:34 PM) fort3hlulz [~setsimmo@2001:420:c0c4:1003::249] entered the room.
(08:28:21 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:33:51 PM) tevador_ [~tevador@ip-86-49-254-95.net.upcbroadband.cz] entered the room.
(08:35:15 PM) tevador left the room (quit: Ping timeout: 244 seconds).
(08:35:22 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(08:45:11 PM) kopite7 left the room (quit: Quit: Leaving.).
(09:15:58 PM) IRS is now known as [-mugatu-]
(09:39:03 PM) fort3hlulz left the room (quit: Ping timeout: 252 seconds).
(09:50:35 PM) Tom_Cruise left the room (quit: Read error: Connection reset by peer).
(09:50:56 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(09:56:28 PM) Letres [49751e06@gateway/web/freenode/ip.73.117.30.6] entered the room.
(09:57:04 PM) Letres: Aperently python doesn't like having 256mebibytes put through it
(10:24:21 PM) OSNF2P left the room (quit: Remote host closed the connection).
(11:07:10 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(11:27:18 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(11:36:10 PM) LSDog [~LSDog@unaffiliated/lsdog] entered the room.
(11:36:33 PM) Letres left the room (quit: Ping timeout: 256 seconds).
(12:30:53 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(12:43:16 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:58:49 AM) investanto left the room (quit: Quit: Changing servers).
(12:59:01 AM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(01:08:04 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:15:27 AM) klp left the room (quit: Quit: Connection closed for inactivity).
(01:32:58 AM) Tom_Crui_ [~Tom@cpe-24-24-133-238.socal.res.rr.com] entered the room.
(01:35:42 AM) Tom_Cruise left the room (quit: Ping timeout: 255 seconds).
(02:52:03 AM) sech1 left the room (quit: Quit: Leaving).
(03:05:34 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(03:05:48 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 268 seconds).
(03:38:12 AM) Coupe420 left the room (quit: Read error: Connection reset by peer).
(03:41:39 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(03:44:22 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:02:45 AM) klp [uid344501@gateway/web/irccloud.com/x-srhmfgufpckdvcni] entered the room.
(04:40:09 AM) Tom_Crui_ left the room (quit: Ping timeout: 268 seconds).
(04:51:27 AM) jwinterm left the room (quit: Ping timeout: 240 seconds).
(05:51:28 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(05:55:52 AM) Tom_Cruise left the room (quit: Ping timeout: 245 seconds).
(06:19:57 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(06:21:20 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(07:08:46 AM) ferretinjapan left the room (quit: Quit: Leaving).
(07:09:02 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(08:17:52 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(08:41:59 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(09:19:02 AM) hyc: we got a reply from Quarkslab. so they're actually interested
(09:20:40 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(09:25:35 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(09:30:09 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(09:34:55 AM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(09:46:46 AM) moneromooo: Nice. They did a really really good job on BPs.
(10:40:57 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:45:26 AM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(10:54:51 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(10:58:54 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(11:01:38 AM) sech1: I've just did a quick benchmark of GTX 1060 RandomX compute speed: https://pastebin.com/kGTFTDrv
(11:01:58 AM) sech1: These are only "heavy" instructions, the rest don't change the final number much
(11:02:26 AM) sech1: In the end, GTX 1060 does < 400 h/s even without memory accesses, branches and randomly changing programs
(11:02:50 AM) sech1: GTX 1080 ti is 2.6 times faster, so it'll do < 1000 h/s in ideal conditions
(11:03:49 AM) nioc left the room (quit: Read error: Connection reset by peer).
(11:04:18 AM) nioc [sid298274@gateway/web/irccloud.com/x-xadpyukywmhqjzlr] entered the room.
(11:06:18 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 255 seconds).
(11:06:45 AM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(11:14:21 AM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(11:14:59 AM) sech1 left the room (quit: Quit: Leaving).
(11:15:27 AM) hyc: what would be its typical cryptonight hashrate sech1?
(11:15:59 AM) hyc: Since GPUs tend to only support FP32, would expect FP64 to be 4x slower
(11:18:36 AM) hyc: https://www.minershashrates.com/nvidia-geforce-gtx-1060-hashrate/
(11:18:43 AM) hyc: 450H/s to 500H/s
(11:19:22 AM) hyc: slower, but not orders of magnitude slower. hardly a big deal.
(11:19:42 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(11:38:05 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:38:49 AM) sech1: hyc GTX 1060 can do 450-500 h/s on Cryptonight
(11:39:49 AM) sech1: 400 h/s on RandomX is an upper limit if memory accesses can be done fully in parallel and thread divergence is solved somehow
(11:40:00 AM) sech1: We'll be lucky if it does 100 h/s in reality
(11:52:28 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(11:56:33 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(11:57:22 AM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(12:14:16 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:14:47 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(01:02:59 PM) hyc: ok. btw that benchmark page said 450H/s for 1060 with 6GB RAM, 420H/s for 1060 w 3GB RAM
(01:11:22 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(01:15:56 PM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(01:19:18 PM) Letres [49751e06@gateway/web/freenode/ip.73.117.30.6] entered the room.
(01:19:46 PM) tevador_: that's quite brutal, I didn't expect it to be so compute bound
(01:19:58 PM) tevador_: it's similar performance to 1 CPU core
(01:20:12 PM) hyc: that's a fully utilized GPU?
(01:20:28 PM) hyc: all compute units running?
(01:20:34 PM) tevador_ is now known as tevador
(01:21:23 PM) tevador: 1060 should be 137 GFLOPS in FP64
(01:21:28 PM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(01:22:23 PM) tevador: sech1's benchmark shows only 2 GFLOPS for addition
(01:23:21 PM) sech1: Don't know why, here's the code: https://pastebin.com/Q3STt8x6
(01:24:38 PM) sech1: I'll try to play with kernel launch parameters
(01:33:04 PM) sech1: yes, apparently block size = 1 is far from optimal, lol
(01:51:05 PM) Letres left the room (quit: Ping timeout: 256 seconds).
(01:58:52 PM) Letres [49751e06@gateway/web/freenode/ip.73.117.30.6] entered the room.
(02:00:59 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(02:34:41 PM) sech1: ok, it looks like GTX 1050 can do 6800 h/s with block size = 256 and GTX 1060 can do 16000 h/s (extrapolating)
(02:35:22 PM) sech1: the only question is how much slower they will be with thread divergence and memory accesses
(02:36:21 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(02:48:29 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(02:58:58 PM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(03:11:13 PM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(03:13:47 PM) sech1: actually, 400 h/s on GTX 1060 with block size = 1 is what would happen with 100% thread divergence, so 400 h/s is a lower bound of the actual hashrate
(03:34:11 PM) vtnerd left the room (quit: Quit: ZNC 1.7.1 - https://znc.in).
(03:34:22 PM) vtnerd_ [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(04:09:20 PM) tevador: so it will be limited by memory bandwidth rather than compute
(04:11:29 PM) fort3hlulz left the room (quit: Quit: Leaving).
(04:12:56 PM) sech1: I think NVIDIA cards will have approximately the same hashrate as they do with Cryptonight now
(04:13:00 PM) sech1: Maybe up to 2 times lower
(04:14:10 PM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(04:16:17 PM) tevador: considering that CPUs run RandomX about 8x faster than CN... not looking good for GPUs
(04:28:03 PM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(04:28:51 PM) moneromooo: That's good. Further protection vs Ethereum farms, and better possibility for hash-for-service sytems.
(04:29:17 PM) moneromooo: Assuming GPUs don't drop significantly more than an ASIC would.
(04:34:56 PM) fort3hlulz: As someone who has easy access to old Xeon systems
(04:35:02 PM) fort3hlulz: Im looking forward to mining RandomX lol
(04:37:15 PM) cjd: I understand GPUs are actually able to quickly change code, it's just that nobody is really working on GPU JIT compilers at the moment
(04:37:40 PM) Letres: How long until someone creates a universal Turing machine from the randomx vm
(04:37:57 PM) cjd: heh
(04:38:31 PM) cjd: It would be cool to see R&D move forward a bit on GPU JIT
(04:42:44 PM) sech1: GPU JIT is possible to do on AMD GPUs, they have all needed documentation for GCN instructions
(04:43:04 PM) sech1: NVIDIA keeps their instruction encodings private
(04:43:26 PM) cjd: oh wow, that's super annoying, I had no idea
(04:44:14 PM) Letres: Numba might be able to help out if someone has experience on C bindings for it
(04:45:03 PM) sech1: NVIDIA has only PTX assembly, but it's not what runs on the actual hardware, so it can't be JIT'ed
(04:45:56 PM) cjd: That alone is good enough reason for me to basically avoid doing anything with NV in the future
(04:46:16 PM) cjd: and I was considering both of them for a possible project, but I had not seriously investigated either
(04:47:10 PM) tevador: Letres: RandomX is (probably) not Turing complete due to the lack of loops
(04:48:13 PM) sech1: tevador you would be surprised to know how many things _are_ Turing complete
(04:48:29 PM) tevador: yes, x86 mov is
(04:48:42 PM) sech1: I read an article once where someone did Turing complete with only mov instructions
(04:48:48 PM) tevador: that's why I'm saying 'probably'
(04:49:06 PM) Letres: I think thatit isn't since there is a bounded input
(04:50:18 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(04:53:11 PM) Letres: By input by tape 
(04:58:26 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(05:01:43 PM) sech1: And we have another problem with AMD cards. It seems they don't support IEEE-754 compliant rounding for division.
(05:02:09 PM) tevador: all AMD cards?
(05:02:15 PM) sech1: There is no dedicated instruction for FP64 DIV, it's done using multiple instructions.
(05:02:32 PM) sech1: And opencl says "<= 3 ulp" precision for DIV
(05:02:42 PM) sech1: and it says "Correctly rounded" for +, -, *
(05:02:48 PM) tevador: yes, opencl is not ieee-754 compliant
(05:03:08 PM) tevador: but actual GPUs are usually more strict
(05:03:21 PM) sech1: yes, and AMD seemed to choose the easy way to be opencl compliant but not IEEE-754 compliant
(05:03:29 PM) tevador: sqrt must be also correctly rounded
(05:03:37 PM) tevador: so it seems only division is a problem?
(05:03:41 PM) sech1: nope
(05:03:48 PM) sech1: it' done with multiple instructions as well
(05:06:20 PM) tevador: Table 7.2 of the OpenCL standard says double precision +, -, *, / and sqrt must be correctly rounded
(05:06:35 PM) tevador: 2.5 ulp for single precision
(05:08:15 PM) sech1: 2.5 ulp is not IEEE-754 compliant
(05:09:40 PM) sech1: Things don't look good here: https://imgur.com/a/nnvAwI5
(05:09:59 PM) sech1: AMD opencl compiler uses multiple instructions to do FP64 DIV and SQRT
(05:11:12 PM) sech1: It's not impossible to implement correctly rounded DIV and SQRT though
(05:11:23 PM) sech1: But it'll probably require more instructios than on these screenshots
(05:12:03 PM) tevador: in worst case, you have to do a few Newton-Rhapson iterations to converge
(05:12:29 PM) sech1: Yes, and the final 64x64->128 multiplication to get correct rounding
(05:14:28 PM) tevador: should be only 53x53 I think
(05:15:11 PM) sech1: yes, but it has to be 64x64 on GPU
(05:18:18 PM) sech1: and I have to do Newton-Raphson iterations on mantissa in 64-bit fixed point format, because FP64 format can't converge to needed precision
(05:19:16 PM) sech1: or maybe it can. The last bit can be wrong after it converges, so I only need to check if I need to increase or decrease the last bit
(05:20:11 PM) sech1: anyway, I'll start with CUDA implementation since it guarantees correct rounding
(05:21:04 PM) fort3hlulz left the room (quit: Quit: Leaving).
(05:30:00 PM) sech1: btw since correctly rounded DIV/SQRT will be slower, 1200 h/s estimate for Vega 56 is a bit too optimistic
(05:32:08 PM) Letres: Has nvidia done any work on on chip memory?
(05:58:50 PM) OsrsNeedsF2P [~OsrsNeeds@CPEf0f249490513-CMf0f249490510.cpe.net.cable.rogers.com] entered the room.
(06:02:25 PM) Letres left the room (quit: Quit: Page closed).
(06:04:17 PM) Tom_Cruise left the room (quit: Ping timeout: 268 seconds).
(06:26:51 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(06:43:12 PM) ferretinjapan left the room (quit: Ping timeout: 246 seconds).
(07:10:31 PM) sech1 left the room (quit: Quit: Leaving).
(07:43:26 PM) midipoet [uid316937@gateway/web/irccloud.com/x-nqigxxalcfoeqzoi] entered the room.
(07:58:44 PM) investanto left the room (quit: Quit: Changing servers).
(07:58:55 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(08:02:46 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(08:28:15 PM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:31:26 PM) IRS [~shillosop@unaffiliated/shillosopher] entered the room.
(08:32:16 PM) [-mugatu-] left the room (quit: Read error: Connection reset by peer).
(08:32:16 PM) kopite7 left the room (quit: Read error: Connection reset by peer).
(08:32:36 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(08:39:35 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(09:34:53 PM) investanto left the room (quit: Quit: Changing servers).
(09:35:04 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(09:54:57 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(09:56:51 PM) midipoet left the room (quit: Quit: Connection closed for inactivity).
(09:59:54 PM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(10:06:05 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(10:34:37 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(10:42:20 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(12:02:10 AM) ArticMine left the room (quit: Ping timeout: 246 seconds).
(12:08:07 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(12:15:42 AM) ArticMine [~ArticMine@s207-81-214-17.bc.hsia.telus.net] entered the room.
(01:30:51 AM) kopite7 left the room (quit: Quit: Leaving.).
(01:47:44 AM) Tom_Cruise left the room (quit: Ping timeout: 246 seconds).
(01:48:48 AM) luigi1113 [~luigi1111@unaffiliated/luigi1111] entered the room.
(01:52:57 AM) luigi1111w left the room (quit: Ping timeout: 268 seconds).
(02:09:00 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(02:34:10 AM) sech1 left the room (quit: Quit: Leaving).
(02:41:58 AM) luigi1113 left the room (quit: Read error: Connection reset by peer).
(02:44:48 AM) sech1 [~sech1@static-213-115-0-116.sme.telenor.se] entered the room.
(02:55:34 AM) vtnerd_ left the room (quit: Ping timeout: 250 seconds).
(02:58:50 AM) kico left the room (quit: Remote host closed the connection).
(02:59:16 AM) kico [~kico@gateway/tor-sasl/kico] entered the room.
(03:18:06 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 250 seconds).
(03:25:05 AM) vtnerd [~Lee@173-23-103-30.client.mchsi.com] entered the room.
(03:44:07 AM) Coupe420 left the room (quit: Read error: Connection reset by peer).
(03:53:58 AM) el00ruobuob_[m] [~el00ruobu@212.121.161.50] entered the room.
(04:57:14 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(05:20:51 AM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:08:59 AM) Common-Deer left the room (quit: Read error: Connection reset by peer).
(06:22:29 AM) sech11 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(07:16:35 AM) sech11 left the room (quit: Quit: Leaving).
(08:06:57 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(08:11:34 AM) ErCiccione[m] left the room (quit: Ping timeout: 250 seconds).
(08:12:13 AM) charuto left the room (quit: Ping timeout: 252 seconds).
(08:12:17 AM) parasew[m] left the room (quit: Ping timeout: 264 seconds).
(09:19:54 AM) fort3hlulz [~setsimmo@2001:420:20b0:2250:7026:be9a:a08:95b0] entered the room.
(09:38:21 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(10:10:41 AM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(10:26:31 AM) crCr62U0 left the room (quit: Remote host closed the connection).
(10:35:45 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(10:41:33 AM) ferretinjapan left the room (quit: Ping timeout: 255 seconds).
(11:11:21 AM) sech1 left the room (quit: Quit: Leaving).
(11:13:55 AM) IRS is now known as [-mugatu-]
(11:17:55 AM) crCr62U0 left the room (quit: Ping timeout: 256 seconds).
(11:20:54 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(11:33:12 AM) Coupe420 [~420coupe@170.55.14.86] entered the room.
(11:46:15 AM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(11:53:53 AM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(11:56:17 AM) el00ruobuob_[m] left the room (quit: Ping timeout: 245 seconds).
(11:58:40 AM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(12:52:54 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(02:42:22 PM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(02:51:19 PM) crCr62U0 left the room (quit: Remote host closed the connection).
(02:56:58 PM) crCr62U0 [~crCr62U0@gateway/tor-sasl/crcr62u0] entered the room.
(04:08:47 PM) fort3hlulz left the room (quit: Ping timeout: 240 seconds).
(04:35:38 PM) [-mugatu-] left the room (quit: Max SendQ exceeded).
(04:36:38 PM) [-mugatu-] [~shillosop@unaffiliated/shillosopher] entered the room.
(04:49:55 PM) fort3hlulz [~setsimmo@cpe-174-109-234-150.nc.res.rr.com] entered the room.
(04:52:11 PM) fort3hlulz_ [~setsimmo@2001:420:c0c4:1007::172] entered the room.
(04:52:43 PM) el00ruobuob_[m] [~el00ruobu@blabour.fr] entered the room.
(04:55:16 PM) fort3hlulz left the room (quit: Ping timeout: 252 seconds).
(05:48:36 PM) ferretinjapan left the room (quit: Read error: Connection reset by peer).
(05:57:54 PM) ferretinjapan [ferretinja@gateway/vpn/privateinternetaccess/ferretinjapan] entered the room.
(06:10:36 PM) sech1 left the room (quit: Quit: Leaving).
(06:15:50 PM) fort3hlulz_ left the room (quit: Ping timeout: 268 seconds).
(06:57:22 PM) ferretinjapan left the room (quit: Ping timeout: 252 seconds).
(07:21:44 PM) LSDog left the room (quit: *.net *.split).
(07:22:03 PM) kinghat left the room (quit: Quit: The Lounge - https://thelounge.chat).
(07:22:51 PM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(07:23:16 PM) kinghat left the room (quit: Client Quit).
(07:24:23 PM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(07:24:27 PM) investanto left the room (quit: Ping timeout: 255 seconds).
(07:25:10 PM) kinghat left the room (quit: Client Quit).
(07:25:58 PM) kinghat [~kinghat@static.237.44.203.116.clients.your-server.de] entered the room.
(07:37:07 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(07:37:11 PM) investanto [~investant@devtalk.ryo-currency.com] entered the room.
(07:49:11 PM) jwinterm left the room (quit: Ping timeout: 250 seconds).
(07:51:43 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(07:57:12 PM) jwinterm left the room (quit: Read error: Connection reset by peer).
(10:35:50 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(10:43:47 PM) jwinterm left the room (quit: Ping timeout: 240 seconds).
(11:07:05 PM) jwinterm [~quassel@unaffiliated/jwinterm] entered the room.
(11:17:51 PM) kopite7 left the room (quit: Ping timeout: 252 seconds).
(11:20:37 PM) kopite7 [~kmaneshni@ip72-194-108-100.oc.oc.cox.net] entered the room.
(12:41:49 AM) Tom_Cruise left the room (quit: Ping timeout: 252 seconds).
(01:33:18 AM) sech1 [~sech1@31-208-119-248.cust.bredband2.com] entered the room.
(01:50:34 AM) Tom_Cruise [~Tom@198.55.124.115.adsl.inet-telecom.org] entered the room.
(01:57:33 AM) rottensox [~rottensox@unaffiliated/rottensox] entered the room.
(02:13:06 AM) kopite7 left the room (quit: Quit: Leaving.).
(03:08:49 AM) The account has disconnected and you are no longer in this chat. You will be automatically rejoined in the chat when the account reconnects.