< 1613174792 801729 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :OK, apparently zsync uses a file called .zsync to control it; I will read the documentation to see how suitable it is. < 1613174898 8581 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :However, what I have, I think that what is helpful is each "realm" has its own timestamp, and may be by name (ordinary files and NNTP) or by hash (Fossil repositories). By hash is always immutable; by name can be mutable (ordinary files) or immutable (NNTP). < 1613175226 349304 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613175546 39140 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Is there a backup protocol that does that? < 1613176298 980971 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613176574 7358 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613176771 784335 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I think .zsync files are probably not suitable for my use. < 1613176828 71579 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(I also do not see documentation about the zsync file format, anyways.) < 1613177039 21664 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Yeah, I haven't seen it documented either. There's a page that explains what it's made of conceptually -- http://zsync.moria.org.uk/paper200503/ -- but doesn't bother to describe the exact file format. But you're right that it's probably not really designed to be extensible. < 1613177139 124558 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric > 1613177207 199090 PRIVMSG #esoteric :14[[07Chatlog14]]4 M10 02https://esolangs.org/w/index.php?diff=80707&oldid=80689 5* 03PythonshellDebugwindow 5* (+57) 10Move cats to bottom; add some too > 1613177296 645328 PRIVMSG #esoteric :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=80708&oldid=80670 5* 03PythonshellDebugwindow 5* (+14) 10/* C */ Add [[Chatlog]] > 1613177392 334294 PRIVMSG #esoteric :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=80709&oldid=80708 5* 03PythonshellDebugwindow 5* (+14) 10/* P */ Add [[Pewlang]] < 1613177447 993390 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613177523 711232 :arseniiv!~arseniiv@95.105.2.1.dynamic.ufanet.ru QUIT :Quit: gone too far < 1613179593 390314 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613179836 371899 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 240 seconds < 1613180448 253096 :sftp!~sftp@unaffiliated/sftp QUIT :Excess Flood < 1613180485 104307 :oren!~oren@ec2-34-239-129-109.compute-1.amazonaws.com PRIVMSG #esoteric :monitors should just have feel-able markings in the shape of H D M I < 1613180492 471236 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1613180501 746031 :oren!~oren@ec2-34-239-129-109.compute-1.amazonaws.com PRIVMSG #esoteric :so that you can tell which one is the HDMI port > 1613180945 492709 PRIVMSG #esoteric :14[[07Divrac14]]4 N10 02https://esolangs.org/w/index.php?oldid=80710 5* 03PythonshellDebugwindow 5* (+2287) 10Make language > 1613180978 390854 PRIVMSG #esoteric :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=80711&oldid=80709 5* 03PythonshellDebugwindow 5* (+13) 10/* D */ +[[Divrac]] < 1613181008 120263 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 QUIT :Quit: Leaving < 1613182842 380709 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613182980 102146 :craigo!~craigo@144.136.206.168 JOIN :#esoteric < 1613183106 375017 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613183405 476386 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 240 seconds < 1613183735 571034 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613185366 371154 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613185626 378806 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613187835 104848 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613187881 282764 :imode!~imode@unaffiliated/imode JOIN :#esoteric < 1613188125 967212 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613189401 431501 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613189697 336562 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613191755 529455 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu JOIN :#esoteric < 1613192646 339832 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613192937 348321 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613193720 546719 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net PRIVMSG #esoteric :Has anyone made a spacesort analogous to sleepsort that just puts stuff into a large array? < 1613194620 778453 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net PRIVMSG #esoteric :https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=581dc6e3ac2423bf0b82105cb731faf9 < 1613195144 437225 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This sort of thing is sometimes called "bucket sort" or other names. < 1613195306 714276 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"counting sort" was what I meant, I think. < 1613195335 111079 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Radix sort often uses this kind of thing. < 1613195470 551343 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net PRIVMSG #esoteric :It has a legitimate use??? < 1613195509 976198 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net PRIVMSG #esoteric :I guess I was thinking that since I was trying to tamper with the obviously esoteric sleepsort, the corresponding wasteful of space would also be esoteric < 1613195524 56042 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure, if there's a small number of values. < 1613195756 404487 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's a linear-time sorting algorithm. < 1613195886 52188 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613196182 135602 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613197114 340760 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613197401 336827 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1613197676 103798 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613197967 976122 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 272 seconds < 1613198531 425933 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613198793 386401 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 246 seconds < 1613199066 377887 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613200360 954008 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :How is sleepsort working? < 1613200703 483395 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :On a television show, for a few seconds it showed a different television show for a few seconds; it displayed two overlapping station indicators. And then, it switched back to the correct show, and then a few seconds after that, it was interrupted again, for less than one second I saw a message that said "Press any key to watch TV". < 1613200736 460738 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(It is a message and font style which are not applicable to any of the equipment I have.) < 1613202333 345800 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 264 seconds < 1613203447 723734 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613203835 142633 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613204397 926524 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613204432 837151 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds < 1613204851 825550 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1613205246 276908 :user24!~user24@2a02:810a:1440:7304:1c93:4023:74a1:6468 JOIN :#esoteric < 1613206028 429311 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 QUIT :*.net *.split < 1613206180 649468 :APic!apic@apic.name QUIT :*.net *.split < 1613206181 870960 :iovoid!iovoid@hellomouse/dev/iovoid QUIT :*.net *.split < 1613206181 987364 :joast!~rick@cpe-98-146-112-4.natnow.res.rr.com QUIT :*.net *.split < 1613206183 92647 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca QUIT :*.net *.split < 1613206183 92699 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca QUIT :*.net *.split < 1613206183 244933 :ineiros!ineiros@kapsi.fi QUIT :*.net *.split < 1613206183 418396 :mla!~mla@162.253.176.229 QUIT :*.net *.split < 1613206191 913100 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :*.net *.split < 1613206191 913152 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :*.net *.split < 1613206192 77894 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar QUIT :*.net *.split < 1613206192 629463 :V!~quassel@anomalous.eu QUIT :*.net *.split < 1613206192 840914 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :*.net *.split < 1613206193 114645 :shachaf!~shachaf@unaffiliated/shachaf QUIT :*.net *.split < 1613206193 467214 :dnm!sid401311@gateway/web/irccloud.com/x-qfqrbyavdfoqnreb QUIT :*.net *.split < 1613206193 785320 :grumble!~Thunderbi@freenode/staff/grumble QUIT :*.net *.split < 1613206194 15515 :moony!moony@hellomouse/dev/moony QUIT :*.net *.split < 1613206194 15562 :jix!~jix@static.71.5.69.159.clients.your-server.de QUIT :*.net *.split < 1613206194 59257 :mniip!~mniip@freenode/staff/mniip QUIT :*.net *.split < 1613206194 211588 :BWBellairs!~bwbellair@hellomouse/dev/bwbellairs QUIT :*.net *.split < 1613206194 517077 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu QUIT :*.net *.split < 1613206194 614181 :MDude!~MDude@71.50.47.112 QUIT :*.net *.split < 1613206194 702096 :Melvar!~melvar@dslb-088-070-039-190.088.070.pools.vodafone-ip.de QUIT :*.net *.split < 1613206194 702174 :lifthrasiir!~lifthrasi@ec2-52-79-98-81.ap-northeast-2.compute.amazonaws.com QUIT :*.net *.split < 1613206196 80246 :olsner!~salparot@c83-249-186-43.bredband.comhem.se QUIT :*.net *.split < 1613206196 311511 :sftp!~sftp@unaffiliated/sftp QUIT :*.net *.split < 1613206196 394550 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :*.net *.split < 1613206196 787640 :glowcoil!sid3405@gateway/web/irccloud.com/x-aqtyexznctdwfsyn QUIT :*.net *.split < 1613206197 920348 :^[!sid43445@ircpuzzles/2015/april-fools/sixth/zgrep QUIT :*.net *.split < 1613206198 164144 :myname!~myname@2001:41d0:1:766f::1 QUIT :*.net *.split < 1613206198 164189 :wesleyac!~wesleyac@wesleyac.com QUIT :*.net *.split < 1613206198 391564 :izabera!izabera@unaffiliated/izabera QUIT :*.net *.split < 1613206198 576497 :Hooloovo0!Hooloovoo@sorunome.de QUIT :*.net *.split < 1613206198 971412 :FireFly!znc@freenode/staff/firefly QUIT :*.net *.split < 1613206200 667491 :aloril!~aloril@mobile-access-56737e-89.dhcp.inet.fi QUIT :*.net *.split < 1613206200 800547 :pikhq!sid394595@gateway/web/irccloud.com/x-kibzupzhkkvzdppb QUIT :*.net *.split < 1613206211 625101 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-shijvpdkiryqdnex QUIT :*.net *.split < 1613206216 711241 :ocharles!sid30093@musicbrainz/user/ocharles QUIT :*.net *.split < 1613206216 958641 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi QUIT :*.net *.split < 1613206217 3346 :Soni!~quassel@unaffiliated/soniex2 QUIT :*.net *.split < 1613206217 44889 :mich181189!sid268336@gateway/web/irccloud.com/x-kingoalphuaqblae QUIT :*.net *.split < 1613206217 71120 :shikhin!~shikhin@unaffiliated/shikhin QUIT :*.net *.split < 1613206217 585734 :none30!none30matr@gateway/shell/matrix.org/x-jqpbvotbjddkkiyg QUIT :*.net *.split < 1613206217 945158 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-grdsknfpaibkkqkw QUIT :*.net *.split < 1613206221 275523 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :*.net *.split < 1613206221 491188 :sebbu!~sebbu@unaffiliated/sebbu QUIT :*.net *.split < 1613206221 608474 :HackEso!~h@unaffiliated/fizzie/bot/hackeso QUIT :*.net *.split < 1613206221 608513 :clog!~nef@bespin.org QUIT :*.net *.split < 1613206221 721441 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com QUIT :*.net *.split < 1613206221 849075 :int-e!~noone@int-e.eu QUIT :*.net *.split < 1613206222 394217 :fungot!~fungot@unaffiliated/fizzie/bot/fungot QUIT :*.net *.split < 1613206222 630106 :paul2520!~paul2520@unaffiliated/paul2520 QUIT :*.net *.split < 1613206223 168525 :dionys!dionys@gateway/shell/blinkenshell.org/x-tkapqqtlebfdhwjt QUIT :*.net *.split < 1613206223 236974 :ski!~ski@ed-3358-10.studat.chalmers.se QUIT :*.net *.split < 1613206223 563890 :hakatashi!~hakatashi@104.131.49.125 QUIT :*.net *.split < 1613206223 716728 :ornxka_!~ornxka@unaffiliated/ornx QUIT :*.net *.split < 1613206224 554650 :interruptinuse!~interrupt@girl.mrtheplague.net QUIT :*.net *.split < 1613206224 708489 :user24!~user24@2a02:810a:1440:7304:1c93:4023:74a1:6468 QUIT :*.net *.split < 1613206224 773606 :imode!~imode@unaffiliated/imode QUIT :*.net *.split < 1613206225 83607 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu QUIT :*.net *.split < 1613206225 189662 :nakilon!~nakilon@62.241.154.104.bc.googleusercontent.com QUIT :*.net *.split < 1613206226 119169 :Lymia!lymia@magical.girl.lyrical.lymia.moe QUIT :*.net *.split < 1613206226 548029 :sparr!~sparr@pdpc/supporter/active/sparr QUIT :*.net *.split < 1613206227 395787 :j4cbo!sid186930@gateway/web/irccloud.com/x-eizznkynbubdgphm QUIT :*.net *.split < 1613206227 395872 :lambdabot!~lambdabot@haskell/bot/lambdabot QUIT :*.net *.split < 1613206227 630056 :shinh!~i@b146029.dynamic.ppp.asahi-net.or.jp QUIT :*.net *.split < 1613206227 675345 :j-bot!~jbot@hagall.firefly.nu QUIT :*.net *.split < 1613206227 761205 :heroux!sandroco@gateway/shell/insomnia247/x-jtoimutuuoauadvi QUIT :*.net *.split < 1613206228 31241 :vertrex-!~vertrex@unaffiliated/vertrex QUIT :*.net *.split < 1613206228 31321 :atehwa!atehwa@185.18.76.165 QUIT :*.net *.split < 1613206228 605176 :fizzie!fis@unaffiliated/fizzie QUIT :*.net *.split < 1613206228 945441 :orbitaldecay!~bob@forder.cc QUIT :*.net *.split < 1613206228 945556 :oren!~oren@ec2-34-239-129-109.compute-1.amazonaws.com QUIT :*.net *.split < 1613206229 3360 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :*.net *.split < 1613206229 85944 :craigo!~craigo@144.136.206.168 QUIT :*.net *.split < 1613206229 313160 :harha_!~harha@ns356919.ip-91-121-144.eu QUIT :*.net *.split < 1613206229 313272 :spruit11!~unknown@86.82.44.193 QUIT :*.net *.split < 1613206229 467004 :zeroed!~admin@unaffiliated/zeroed QUIT :*.net *.split < 1613206229 560600 :copumpkin!~copumpkin@unaffiliated/copumpkin QUIT :*.net *.split < 1613206229 664235 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator QUIT :*.net *.split < 1613206229 953164 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de QUIT :*.net *.split < 1613206230 73488 :kmc!~beehive@unaffiliated/kmcallister QUIT :*.net *.split < 1613206230 130007 :relrod!~relrod@redhat/ansible.staff.relrod QUIT :*.net *.split < 1613206230 130087 :djanatyn!~djanatyn@vps-7f49a6b0.vps.ovh.ca QUIT :*.net *.split < 1613206230 308410 :haavard!root@haavard.me QUIT :*.net *.split < 1613206232 156619 :df1111!df1matrixo@gateway/shell/matrix.org/x-vgmxphbkjzuwvjvq QUIT :*.net *.split < 1613206234 823679 :trn!jhj@prone.ws QUIT :*.net *.split < 1613206235 67464 :stux|RC-only!stux2@grid9.quadspeedi.net QUIT :Excess Flood < 1613206904 514278 :APic!apic@apic.name JOIN :#esoteric < 1613206904 515357 :orbitaldecay!~bob@forder.cc JOIN :#esoteric < 1613206904 515386 :oren!~oren@ec2-34-239-129-109.compute-1.amazonaws.com JOIN :#esoteric < 1613206904 515402 :fizzie!fis@unaffiliated/fizzie JOIN :#esoteric < 1613206904 515418 :interruptinuse!~interrupt@girl.mrtheplague.net JOIN :#esoteric < 1613206904 515433 :trn!jhj@prone.ws JOIN :#esoteric < 1613206904 515449 :haavard!root@haavard.me JOIN :#esoteric < 1613206904 515464 :sparr!~sparr@pdpc/supporter/active/sparr JOIN :#esoteric < 1613206904 515480 :FireFly!znc@freenode/staff/firefly JOIN :#esoteric < 1613206904 515496 :djanatyn!~djanatyn@vps-7f49a6b0.vps.ovh.ca JOIN :#esoteric < 1613206904 515513 :izabera!izabera@unaffiliated/izabera JOIN :#esoteric < 1613206904 515528 :olsner!~salparot@c83-249-186-43.bredband.comhem.se JOIN :#esoteric < 1613206904 515544 :relrod!~relrod@redhat/ansible.staff.relrod JOIN :#esoteric < 1613206904 515559 :paul2520!~paul2520@unaffiliated/paul2520 JOIN :#esoteric < 1613206904 515582 :BWBellairs!~bwbellair@hellomouse/dev/bwbellairs JOIN :#esoteric < 1613206904 515598 :V!~quassel@anomalous.eu JOIN :#esoteric < 1613206904 515618 :atehwa!atehwa@185.18.76.165 JOIN :#esoteric < 1613206904 515635 :kmc!~beehive@unaffiliated/kmcallister JOIN :#esoteric < 1613206904 534458 :vertrex-!~vertrex@unaffiliated/vertrex JOIN :#esoteric < 1613206904 534515 :wesleyac!~wesleyac@wesleyac.com JOIN :#esoteric < 1613206904 534536 :myname!~myname@2001:41d0:1:766f::1 JOIN :#esoteric < 1613206904 534555 :mniip!~mniip@freenode/staff/mniip JOIN :#esoteric < 1613206904 534575 :jix!~jix@static.71.5.69.159.clients.your-server.de JOIN :#esoteric < 1613206904 534611 :moony!moony@hellomouse/dev/moony JOIN :#esoteric < 1613206904 534632 :rodgort!~rodgort@static.38.6.217.95.clients.your-server.de JOIN :#esoteric < 1613206904 534652 :pikhq!sid394595@gateway/web/irccloud.com/x-kibzupzhkkvzdppb JOIN :#esoteric < 1613206904 534671 :^[!sid43445@ircpuzzles/2015/april-fools/sixth/zgrep JOIN :#esoteric < 1613206904 534690 :aloril!~aloril@mobile-access-56737e-89.dhcp.inet.fi JOIN :#esoteric < 1613206904 534719 :fungot!~fungot@unaffiliated/fizzie/bot/fungot JOIN :#esoteric < 1613206904 534739 :Lymia!lymia@magical.girl.lyrical.lymia.moe JOIN :#esoteric < 1613206904 534758 :heroux!sandroco@gateway/shell/insomnia247/x-jtoimutuuoauadvi JOIN :#esoteric < 1613206904 534777 :Soni!~quassel@unaffiliated/soniex2 JOIN :#esoteric < 1613206904 534797 :mich181189!sid268336@gateway/web/irccloud.com/x-kingoalphuaqblae JOIN :#esoteric < 1613206904 534816 :shikhin!~shikhin@unaffiliated/shikhin JOIN :#esoteric < 1613206904 534836 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi JOIN :#esoteric < 1613206904 553642 :grumble!~Thunderbi@freenode/staff/grumble JOIN :#esoteric < 1613206904 553717 :ornxka_!~ornxka@unaffiliated/ornx JOIN :#esoteric < 1613206904 553747 :j-bot!~jbot@hagall.firefly.nu JOIN :#esoteric < 1613206904 553770 :shinh!~i@b146029.dynamic.ppp.asahi-net.or.jp JOIN :#esoteric < 1613206904 553792 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator JOIN :#esoteric < 1613206904 553813 :Hooloovo0!Hooloovoo@sorunome.de JOIN :#esoteric < 1613206904 553839 :hakatashi!~hakatashi@104.131.49.125 JOIN :#esoteric < 1613206904 553862 :dnm!sid401311@gateway/web/irccloud.com/x-qfqrbyavdfoqnreb JOIN :#esoteric < 1613206904 553883 :lambdabot!~lambdabot@haskell/bot/lambdabot JOIN :#esoteric < 1613206904 553904 :int-e!~noone@int-e.eu JOIN :#esoteric < 1613206904 553925 :copumpkin!~copumpkin@unaffiliated/copumpkin JOIN :#esoteric < 1613206904 553946 :j4cbo!sid186930@gateway/web/irccloud.com/x-eizznkynbubdgphm JOIN :#esoteric < 1613206904 553967 :zeroed!~admin@unaffiliated/zeroed JOIN :#esoteric < 1613206904 553989 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com JOIN :#esoteric < 1613206904 554009 :ocharles!sid30093@musicbrainz/user/ocharles JOIN :#esoteric < 1613206904 554031 :glowcoil!sid3405@gateway/web/irccloud.com/x-aqtyexznctdwfsyn JOIN :#esoteric < 1613206904 554054 :nakilon!~nakilon@62.241.154.104.bc.googleusercontent.com JOIN :#esoteric < 1613206904 572793 :clog!~nef@bespin.org JOIN :#esoteric < 1613206904 572890 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu JOIN :#esoteric < 1613206904 572928 :HackEso!~h@unaffiliated/fizzie/bot/hackeso JOIN :#esoteric < 1613206904 572961 :shachaf!~shachaf@unaffiliated/shachaf JOIN :#esoteric < 1613206904 572995 :lifthrasiir!~lifthrasi@ec2-52-79-98-81.ap-northeast-2.compute.amazonaws.com JOIN :#esoteric < 1613206904 573027 :Melvar!~melvar@dslb-088-070-039-190.088.070.pools.vodafone-ip.de JOIN :#esoteric < 1613206904 573061 :spruit11!~unknown@86.82.44.193 JOIN :#esoteric < 1613206904 573092 :harha_!~harha@ns356919.ip-91-121-144.eu JOIN :#esoteric < 1613206904 573123 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1613206904 573159 :ski!~ski@ed-3358-10.studat.chalmers.se JOIN :#esoteric < 1613206904 573190 :sebbu!~sebbu@unaffiliated/sebbu JOIN :#esoteric < 1613206904 573223 :dionys!dionys@gateway/shell/blinkenshell.org/x-tkapqqtlebfdhwjt JOIN :#esoteric < 1613206904 573255 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613206904 573302 :MDude!~MDude@71.50.47.112 JOIN :#esoteric < 1613206904 573339 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613206904 573379 :craigo!~craigo@144.136.206.168 JOIN :#esoteric < 1613206904 573422 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1613206904 592517 :imode!~imode@unaffiliated/imode JOIN :#esoteric < 1613206904 592625 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu JOIN :#esoteric < 1613206904 592665 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613206904 592700 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613206904 592734 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1613206904 592769 :user24!~user24@2a02:810a:1440:7304:1c93:4023:74a1:6468 JOIN :#esoteric < 1613206904 592802 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 JOIN :#esoteric < 1613206904 592836 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca JOIN :#esoteric < 1613206904 592869 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca JOIN :#esoteric < 1613206904 592903 :ineiros!ineiros@kapsi.fi JOIN :#esoteric < 1613206904 592936 :mla!~mla@162.253.176.229 JOIN :#esoteric < 1613206904 592969 :iovoid!iovoid@hellomouse/dev/iovoid JOIN :#esoteric < 1613206904 593003 :joast!~rick@cpe-98-146-112-4.natnow.res.rr.com JOIN :#esoteric < 1613206904 593035 :stux|RC-only!stux2@grid9.quadspeedi.net JOIN :#esoteric < 1613206904 593069 :sftp!~sftp@unaffiliated/sftp JOIN :#esoteric < 1613206977 403910 :mniip!~mniip@freenode/staff/mniip QUIT :Ping timeout: 624 seconds < 1613207019 619904 :mniip!~mniip@freenode/staff/mniip JOIN :#esoteric < 1613207239 585042 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613207404 262802 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1613207429 833053 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 268 seconds > 1613207660 597398 PRIVMSG #esoteric :14[[07Befunge14]]4 10 02https://esolangs.org/w/index.php?diff=80712&oldid=80685 5* 03Quintopia 5* (-74) 10Now DNA-code outputs codons equiprobably. < 1613207677 995654 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com PRIVMSG #esoteric :I've found an old programming game / artificial life that seems to have dropped off the internet and made it available again https://corewar.co.uk/biomass/biomass.html < 1613207736 287343 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com PRIVMSG #esoteric :The images are missing, but I'll recreate those if I manage to compile to code with X11 display. < 1613208299 911036 :df1111!df1matrixo@gateway/shell/matrix.org/x-anjcephcolsiodau JOIN :#esoteric < 1613208962 326151 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-hjnutdrjfalzgzre JOIN :#esoteric < 1613208969 483699 :none30!none30matr@gateway/shell/matrix.org/x-wukxpolklzpgyroq JOIN :#esoteric > 1613209114 35826 PRIVMSG #esoteric :14[[07Pewlang14]]4 10 02https://esolangs.org/w/index.php?diff=80713&oldid=80704 5* 03Tasty Kiwi 5* (-23) 10 < 1613209324 746766 :none30!none30matr@gateway/shell/matrix.org/x-wukxpolklzpgyroq QUIT :Ping timeout: 240 seconds < 1613209377 646312 :df1111!df1matrixo@gateway/shell/matrix.org/x-anjcephcolsiodau QUIT :Ping timeout: 258 seconds < 1613209404 738085 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-hjnutdrjfalzgzre QUIT :Ping timeout: 240 seconds > 1613209411 616257 PRIVMSG #esoteric :14[[07Joke language list14]]4 M10 02https://esolangs.org/w/index.php?diff=80714&oldid=80452 5* 03Tasty Kiwi 5* (+14) 10add pewlang > 1613209833 176315 PRIVMSG #esoteric :14[[07Pewlang14]]4 M10 02https://esolangs.org/w/index.php?diff=80715&oldid=80713 5* 03Tasty Kiwi 5* (+18) 10add 2021 category < 1613210192 702212 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Quit: Leaving < 1613210224 993818 :user24!~user24@2a02:810a:1440:7304:1c93:4023:74a1:6468 QUIT :Quit: We must know, we will know < 1613210403 183937 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613212273 810259 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-tjhdkdxaajapejgf JOIN :#esoteric < 1613212390 168348 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Quit: quit < 1613212490 690081 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-cfgygugobaofgzhq JOIN :#esoteric < 1613212920 471765 :none30!none30matr@gateway/shell/matrix.org/x-uywdladeucujnfut JOIN :#esoteric < 1613213163 675073 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613213277 641761 :df1111!df1matrixo@gateway/shell/matrix.org/x-uzaubimwmskouqgz JOIN :#esoteric < 1613214090 56702 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1613214388 162589 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613217759 285837 :imode!~imode@unaffiliated/imode QUIT :Ping timeout: 272 seconds < 1613218304 586235 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :zzo38: you can also upload public files to archive.org < 1613223537 360616 :arseniiv!~arseniiv@95.105.2.1.dynamic.ufanet.ru JOIN :#esoteric < 1613223575 869089 :arseniiv!~arseniiv@95.105.2.1.dynamic.ufanet.ru PRIVMSG #esoteric :fungot do you integrate by parts or you’d better divide and conquer? < 1613223576 214652 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :arseniiv: mr president, the commission communication on sustainable aquaculture, you may ask. in 1848, during the debate on the fayot report because it is difficult for me to respond other than in exceptional cases. the globalisation of democracy. science is obviously an issue, as in the countries of the european union < 1613223595 290544 :arseniiv!~arseniiv@95.105.2.1.dynamic.ufanet.ru PRIVMSG #esoteric :ha government talk < 1613223622 894357 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :"Science is obviously an issue." < 1613223634 515951 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :fungot: Are you one of those anti-science folks? < 1613223634 841949 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :fizzie: ladies and gentlemen, that i am not in a position to take action. mr stevenson also raises the problem of organized crime. this convention is accompanied by a deadline so that we can only welcome the fact that we are spending european money to solve their own problems on to europe. > 1613223661 11395 PRIVMSG #esoteric :14[[07Pewlang14]]4 M10 02https://esolangs.org/w/index.php?diff=80716&oldid=80715 5* 03PythonshellDebugwindow 5* (+169) 10/* Examples */ cats < 1613223683 411787 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I think we can all appreciate the fact fungot is not in any sort of position to take action. < 1613223683 566371 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :fizzie: commissioner, you stated that responsibility for the tasks that will face those two countries. < 1613223774 978955 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :`quote bring an end < 1613223775 796149 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :429) fizzie: i, myself, will bring an end to all. > 1613223863 318114 PRIVMSG #esoteric :14[[07User:PythonshellDebugwindow14]]4 M10 02https://esolangs.org/w/index.php?diff=80717&oldid=80664 5* 03PythonshellDebugwindow 5* (+46) 10/* Languages */ +[[Divrac]] < 1613225540 176660 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613226466 375355 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613226631 600848 :ubq323!~ubq323@host86-154-198-83.range86-154.btcentralplus.com JOIN :#esoteric < 1613226980 971982 :olsner!~salparot@c83-249-186-43.bredband.comhem.se PRIVMSG #esoteric :`quote fungot < 1613226981 385494 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :olsner: mr president, thanks in particular to mr john fnord and the continuation of the bombing of serbia can stop. the eldr resolution is quite clear that the game is over, to visit kaliningrad. i salute the progress which is well represented by the euro very quickly in setting up a european food authority < 1613226981 779306 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :10) GregorR-L: i bet only you can prevent forest fires. basically, you know. \ 13) Finally I have found some actually useful purpose for it. \ 14) oerjan: are you a man, if there weren't evil in this kingdom to you! you shall find bekkler! executing program. please let me go... put me out! he's really a tricycle! pass him! \ 56) i am sad ( of course < 1613227097 922655 :olsner!~salparot@c83-249-186-43.bredband.comhem.se PRIVMSG #esoteric :
ACTION shall now idle for a few more years
< 1613227461 357723 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Ping timeout: 264 seconds < 1613227567 510987 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :fungot: that war has ended for good, thank god < 1613227568 107946 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :b_jonas: mr president, mr churchill, who i hope will soon be time for decisions to be monopolized by a small �lite. one might even imagine cases where codecision or majority voting in environmental matters. this requires careful supervision, as we all know this is not exactly encouraging either and detracts from the fact that the replacement fats are safe? one final point on the jobs of 2 000 observers will be placed on an aspe < 1613227590 992766 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"codecision"? nice < 1613227628 610089 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :that must be some linear logic thing > 1613228364 240445 PRIVMSG #esoteric :14[[07FROM HERE TO THERE14]]4 M10 02https://esolangs.org/w/index.php?diff=80718&oldid=78837 5* 03PythonshellDebugwindow 5* (+40) 10/* Create a variable, initialize it to 7, set it to 19, increment it, then divide it by 4 and print its value */ Shorten titlie < 1613229261 341167 :ubq323!~ubq323@host86-154-198-83.range86-154.btcentralplus.com QUIT :Ping timeout: 264 seconds < 1613231771 412275 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :fungot: "Placed on an aspe"? Is that some sort of woodworking tool, like an adze? < 1613231771 874244 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :fizzie: i would like to reiterate my previous remarks demonstrate that to me seems obvious, but which wish to ignore the historical fact that one country has won three world wars. the issue is one of the following: ‘to draw up and maintain a list of themes, but it has been said by mr smith, i am concerned about the content of several of the speeches this morning and i have had this afternoon. < 1613232374 403136 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I thought we had only had two of those world wars so far. < 1613232673 152263 :APic!apic@apic.name PRIVMSG #esoteric :Nah, the 3rd was the Cold War < 1613232678 571929 :APic!apic@apic.name PRIVMSG #esoteric :Now we are inside World War IV < 1613232682 442146 :APic!apic@apic.name PRIVMSG #esoteric :Also knwon as Information War < 1613232904 898182 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I heard something about World War Z, was that also one of them? < 1613233546 211357 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613233913 389388 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613233931 247256 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sleepsort is actually just another sorting algorithm in disguise, usually heapsort < 1613233941 488564 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because you're basically just delegating the task of actually sorting onto the OS scheduler < 1613233969 167327 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and heapsort isn't a horrible algorithm, although it is really confusing < 1613233995 540112 :int-e!~noone@int-e.eu PRIVMSG #esoteric :it just moves things around quite a bit < 1613234013 844701 :int-e!~noone@int-e.eu PRIVMSG #esoteric :and the memory access patterns aren't too cache-friendly < 1613234107 23237 :int-e!~noone@int-e.eu PRIVMSG #esoteric :oh, what you have is not the usual heapsort; you're just managing the data in a priority queue (usually a heap structure) < 1613234128 830384 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos JOIN :#esoteric < 1613234146 81924 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :"put everything into a priority queue and take it back out again" is heapsort by definition, assuming that the priority queue is implemented as a heap < 1613234159 804699 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, I agree that heapsort is more often done in-place < 1613234193 296972 :int-e!~noone@int-e.eu PRIVMSG #esoteric :to my mind the term "heapsort" is tied to a particular binary heap implemented in place < 1613234394 113172 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also it's apparently possible to create a heap by inserting an array into it in O(n) time < 1613234404 73323 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, inserting an array into an empty heap < 1613234413 472732 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is faster than inserting the elements into it one at a time, which would be O(n log n) < 1613234421 854058 :int-e!~noone@int-e.eu PRIVMSG #esoteric :right < 1613234432 393887 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, there's no way to speed up the "extract in sorted order" part of the algorithm, which is n log n regardless < 1613234504 401592 :int-e!~noone@int-e.eu PRIVMSG #esoteric :there's also the trick of moving everything up and then correcting the heap from below which saves comparisons on average... maybe Knuth analyses this? I forgot where I have this from. < 1613234558 950605 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(it's n log n, but it had a smaller constant factor in the average case) < 1613234733 177524 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613235043 315730 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it crosses my mind that an intrusive heap might potentially be useful < 1613235069 996196 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :probably implemented as an array of pointers to elements, and a index in each element pointing back to the appropriate element of the array < 1613235094 35411 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that way, the elements could automatically find themselves in the heap so that they could be deleted, move themselves when their keys were modified, etc. < 1613236905 381407 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613237160 363419 :scoofy!~scoofy@catv-89-135-21-225.catv.broadband.hu QUIT :Ping timeout: 246 seconds < 1613237772 987895 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Quit: metcalf < 1613237788 782351 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613237961 108799 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613238044 418120 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Client Quit < 1613238046 21237 :hendursaga!~weechat@gateway/tor-sasl/hendursaga PRIVMSG #esoteric :Anyone know of any software using genetic programming or similar to reduce code size for golfing? I think I had one or two bookmarks but they got lost. < 1613238060 555426 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613238169 347974 :hendursaga!~weechat@gateway/tor-sasl/hendursaga PRIVMSG #esoteric :I'm mostly thinking stack-based ones, because I tend to use too many dup's and swaps and whatnot < 1613238332 126356 :kritixilithos!~kritixili@gateway/tor-sasl/kritixilithos QUIT :Quit: quit < 1613239716 95788 :imode!~imode@unaffiliated/imode JOIN :#esoteric > 1613240491 270251 PRIVMSG #esoteric :14[[07User:Hakerh40014]]4 M10 02https://esolangs.org/w/index.php?diff=80719&oldid=80642 5* 03Hakerh400 5* (-81) 10 < 1613240620 65219 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de JOIN :#esoteric < 1613240807 269015 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613240812 303976 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :hendursaga: some of the superoptimization techniques could be applicable maybe? https://en.wikipedia.org/wiki/Superoptimization < 1613240884 354684 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :I don't have a link but I remember a paper about a system that would guess at new peephole optimizations, test them against a bunch of random inputs, and the ones that passed those tests were sent to a SAT solver for an exhaustive proof that they are meaning-preserving < 1613240939 806489 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :maybe you could do something similar < 1613241128 699637 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I think I remember someone giving a talk about something like that in the context of Ethereum smart contracts, where there's a very measurable cost in the "gas" that's needed to run them. < 1613241951 571553 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ah, makes sense < 1613241955 457281 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :good application < 1613242152 364786 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613243324 359935 :hendursaga!~weechat@gateway/tor-sasl/hendursaga PRIVMSG #esoteric :Hmmm, I recall looking at a superoptimizer recently < 1613243526 966228 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I once tried writing a superoptimizer by implementing a subset of x86 in z3 syntax < 1613243530 299353 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but didn't get that far < 1613243579 438138 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: https://github.com/zwegner/x86-sat seems neat. < 1613243673 981077 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :indeed, although that isn't quite the same as what I was working on < 1613243693 331253 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was attempting to optimise it for SAT search, so that an exists-forall search would find a sequence of instructions that implemented some specific algorithm < 1613243721 467346 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That seems tough. < 1613243749 522813 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's probably why I didn't get very far < 1613243898 992107 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :http://nethack4.org/pastebin/z386.smt2 if you're interested < 1613243925 872843 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(it doesn't have a good UI yet, or indeed any real UI) < 1613244033 501351 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Writing SMTLIB2 directly? Courageous. < 1613244131 355676 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :writing a generator may well have been harder < 1613244176 678785 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wish SMT solvers standardized on an API rather than just S-expressions. < 1613244185 807915 :int-e!~noone@int-e.eu PRIVMSG #esoteric :`define-fun` makes this sane < 1613244186 566459 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :define-fun`? No such file or directory < 1613244211 956829 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the s-expressions *are* the API < 1613244213 187562 :int-e!~noone@int-e.eu PRIVMSG #esoteric :oh right, I keep forgetting to mask ` < 1613244231 541899 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean an API that doesn't involve parsing. < 1613244239 59472 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, requiring the parser to be an exact subset of Common Lisp's was probably a mistake < 1613244245 479071 :int-e!~noone@int-e.eu PRIVMSG #esoteric :you only have to pretty-print it :P < 1613244249 110646 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's probably less important when you give the solver one big instance rather than manny small instances. < 1613244273 101632 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I don't disagree... < 1613244304 662858 :int-e!~noone@int-e.eu PRIVMSG #esoteric :...but that z386.smt2 example is not the reason why a standard API would be helpful < 1613244329 199695 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Probably not. < 1613244347 35873 :int-e!~noone@int-e.eu PRIVMSG #esoteric :a better example would be, say, integrating smt solving into a compiler for eliminating bounds checks < 1613244364 87787 :int-e!~noone@int-e.eu PRIVMSG #esoteric :where you'll have many, often small problems < 1613244448 89121 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. < 1613244469 588464 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does that actually require SMT solving in most cases? < 1613244486 108585 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :tracking integer ranges will get rid of most of them in a purely compositional way < 1613244503 126348 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also, in that case, you'd probably want the SMT solver to work on the compiler's IR directly) < 1613244730 201834 :int-e!~noone@int-e.eu PRIVMSG #esoteric :ais523: strength reduction (to reduce the number of variables) and simple interval/offset/stride amalysis will get you quite far I suppose. < 1613244758 682616 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :strength reduction doesn't reduce the number of variables, does it? < 1613244796 509229 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, I was also thinking about range analysis in another context: code which evaluates the exact expression that the user specified, without rounding intermediate results < 1613244804 175263 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a sort of "intermediate results are bignums" way of writing languages < 1613244843 522100 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this would remove entire categories of security vulnerabilities, generally make code much more readable, and with good range analysis might be no more inefficient than the original < 1613244880 894104 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, some programs keep their integers in range with an analysis of the form "this program won't be running long enough for this counter to overflow" and I think there should be some way to formalise that > 1613244909 15373 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03Eekee 5* 10New user account < 1613244997 980100 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it'd be nice for a program to say "you're trying to make me operate on a 860MiB file, but this program will have an integer overflow if operating on a file larger than 750MiB so I won't even try", and for those bounds to be automatically calculated by the compiler < 1613245005 815995 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rather than getting most of the way through and then failing > 1613245199 728877 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=80720&oldid=80705 5* 03Eekee 5* (+353) 10/* Introductions */ +eekee < 1613245728 703879 :ubq323!~ubq323@host86-154-198-83.range86-154.btcentralplus.com JOIN :#esoteric > 1613245762 394972 PRIVMSG #esoteric :14[[07Esolang talk:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=80721&oldid=73907 5* 03Eekee 5* (+805) 10/* Y'all know some goof has split the introduction section into two, right? */ new section < 1613245825 820986 :metcalf_!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613245844 298259 :metcalf_!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Client Quit < 1613245870 796601 :metcalf_!~metcalf@host86-152-246-80.range86-152.btcentralplus.com JOIN :#esoteric < 1613245965 335462 :metcalf!~metcalf@host86-152-246-80.range86-152.btcentralplus.com QUIT :Ping timeout: 264 seconds < 1613245965 801305 :metcalf_!~metcalf@host86-152-246-80.range86-152.btcentralplus.com NICK :metcalf < 1613246638 787632 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: I do something like that, but not intrusively: a binary heap implemented as a normal array, and a dictionary of the same elements keyed on a different key, and each element in the dictionary has the index of the corresponding element in the implementation of the heap, and I update the index every time I move elements in the heap (whether up or down). this way you can find an element in the heap < 1613246644 794276 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :any time and increase its weight to move it later. it helps with a traditional priority queue for timers too, where you often want to postpone timers or forget them entirely. < 1613246977 134199 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"this program will have an integer overflow if operating on a file larger than 750MiB so I won't even try" => ah yes, that bug in ffmpeg. that was for reading 2 gigabytes though, a bit less arbitrary. < 1613247180 306805 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :'some programs keep their integers in range with an analysis of the form "this program won't be running long enough for this counter to overflow"' => yes. the rule I have for that is, if you increment a counter by 1 each time only (as opposed to adding larger numbers, or incrementing many separate counters in parallel then tallying them into it), then it will never reach 2**62 plus its starting value. < 1613247186 313804 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :for example, a generation counter or a reference counter is safe to keep as 64 bit long. but of course you often want an optimization that lets them be just 32 bit long, and that requires either more difficult arguments, or overflow checks every time. < 1613247261 299138 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :this applies even if you sometimes save the counter to the disk and later retrieve it from there, like in a database generation counter, again as long as you don't merge multiple counters into it with addition. < 1613247267 567893 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wonder whether binary heaps actually do better than B-trees in practice, for many of their applications. < 1613247390 92686 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :that said, you can usually make runtime overflow checks very cheap, if they almost never have to detect an overflow. < 1613247411 798860 :fizzie!fis@unaffiliated/fizzie QUIT :Quit: Coyote finally caught me < 1613247418 49269 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :then your program will give a cryptic error message on overflow, instead of undefined behavior < 1613247488 801506 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1613247583 897554 :fizzie!fis@unaffiliated/fizzie JOIN :#esoteric < 1613247712 968924 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613248072 666703 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1613248208 151067 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613248348 208579 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : I wonder whether binary heaps actually do better than B-trees in practice, for many of their applications. ← there's such a thing as a B-heap (which is just a binary heap laid out differently in memory), that might be a fairer comparison < 1613248374 159242 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613248409 145685 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I agree that runtime overflow detection (e.g. Rust in debug mode) is preferable to undefined behaviour or silent wrapping < 1613248430 124719 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, I would prefer compile-time overflow detection, or ideally, the program just functioning as the programmer expected (the programmer's intent is normally clear) < 1613248526 838659 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for example, starting calloc with «if (size * nmemb > SIZE_MAX) return NULL;» doesn't actually work (and good compilers will warn about this), but it is clear what the programmer means and it shouldn't be hard to teach a compiler how to generate code for it < 1613248545 116816 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1613248562 499519 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1613248585 27152 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and at least x86-64 has a perfectly usable 64-to-128-bit multiply instruction < 1613248610 670829 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :s/.*/(note that gcc has an intrinsic for "multiply and check for overflow", &)/ < 1613248618 877275 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(one of my comments got eaten in the connection reset) < 1613248655 230269 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, should that be & (sed-style) or $& (perl-style)? normally the exact regex syntax doesn't matter for these s/// things, but this is a case where it does < 1613248930 408199 :int-e!~noone@int-e.eu PRIVMSG #esoteric :& seems fine < 1613249142 548547 :int-e!~noone@int-e.eu PRIVMSG #esoteric :but this may well amount to asking whether someone is a Perl programmer or not < 1613249241 112018 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de QUIT :Remote host closed the connection < 1613249317 373838 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1613249420 25995 :imode!~imode@unaffiliated/imode QUIT :Ping timeout: 272 seconds < 1613250032 493972 :imode!~imode@unaffiliated/imode JOIN :#esoteric < 1613250679 768446 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: we were discussing alignment a while ago; I've been doing some benchmarking of various memory writing techniques recently (on a recent Intel processor), so decided to try misaligned writes < 1613250722 448232 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they seem to be slower than aligned writes when the written data is in L1 or L2 cache, but no slower when the cache line to write has to be fetched from L3 cache or beyond < 1613250766 139404 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(I'm guessing that the processor can compensate for the misalignment faster than it can evict a line from L2 cache) < 1613250798 321359 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, for aligned writes, it doesn't matter whether you use a misalignment-capable writing instruction or not, the processor notices that the address is aligned < 1613250798 856047 :int-e!~noone@int-e.eu PRIVMSG #esoteric :is this for misaligned access within a single cache line? < 1613250820 488347 :int-e!~noone@int-e.eu PRIVMSG #esoteric :also, what CPU? < 1613250837 379607 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :int-e: I tested using misaligned accesses that collectively cover memory, so some within a cache line and some crossing cache lines, but to consecutive addresses < 1613250901 157272 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is a Whiskey Lake microarchitecture, it seems (I had to look it up, there are way too many different naming schemes for Intel processors) < 1613250902 111606 :craigo!~craigo@144.136.206.168 QUIT :Ping timeout: 272 seconds < 1613250906 414565 :int-e!~noone@int-e.eu PRIVMSG #esoteric :well, it seems interesting to check whether the slowdown is just due to touching more than one cache line < 1613250939 11678 :int-e!~noone@int-e.eu PRIVMSG #esoteric :though that interferes with linear memory access so hrm, tricky < 1613250940 915378 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure there's much use for misaligned writes that are guaranteed to fit within a single cache line < 1613250951 545494 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and I'm not sure how you'd write the test, either < 1613250989 983343 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the /other/ issue with misaligned writes is that you can't bypass the caches with them and write directly to main memory (there isn't an instruction in the instruction set for it, vmovdqnt and friends work on aligned memory only) < 1613250992 491577 :int-e!~noone@int-e.eu PRIVMSG #esoteric :well, access words stuff at a... 64 byte? stride < 1613251000 630621 :int-e!~noone@int-e.eu PRIVMSG #esoteric :and vary the offset? < 1613251017 721064 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess I can imagine a packed structure that's 64 bytes long but where the internal fields are misaligned < 1613251063 718240 :int-e!~noone@int-e.eu PRIVMSG #esoteric :this question isn't really motivated by practical considerations < 1613251078 441923 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, this is #esoteric after all < 1613251096 872168 :int-e!~noone@int-e.eu PRIVMSG #esoteric :it's more about having a model for the slowdown, possibly even an explanation < 1613251107 402163 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, another interesting test would be to have a loop that writes only half of each cache line < 1613251117 584214 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and see whether it's faster, slower, or the same speed as a loop that writes all of it < 1613251126 478040 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(but you could do that with both aligned and misaligned data) < 1613251156 380691 :int-e!~noone@int-e.eu PRIVMSG #esoteric :hmmmm. expetations... it should actually be slower? < 1613251200 362042 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think it might depend on the number of reads of other cache lines you're doing in parallel < 1613251219 936440 :int-e!~noone@int-e.eu PRIVMSG #esoteric :if you write a whole cache line you don't have to wait for it to be fetched from higher up the memory hierarchy... or is that down? < 1613251234 830925 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure which direction in memor is which < 1613251269 727810 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, it wouldn't surprise me if processors couldn't map a line into cache without fetching it from the next-larger cache < 1613251338 354646 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I agree it's an interesting experiment. < 1613251340 922193 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I saw some discussion of this on Twitter recently. Let me see if I can find it. < 1613251354 68680 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :prefetchw, which prepares a line for writing, is documented as reading the line into cache and taking an exclusive lock on it < 1613251397 902754 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ooh! that's probably why vmovdqnt seems to be almost exactly twice as fast as vmovdqa for writing main memory < 1613251402 960393 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it was this thread: https://twitter.com/trav_downs/status/1358288656188854272 < 1613251410 930585 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Though that's talking about AMD, and I think there was something about Intel too. < 1613251435 121705 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I bet vmovdqa has to read the line and then write it, whereas vmovdqnt doesn't have to read it at all < 1613251453 363036 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although I don't bet very much, because I'm not that sure < 1613251693 263696 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, another thing I discovered is that the number of bytes you write at a time speeds up accesses to L1 and L2 but not beyond < 1613251703 468366 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(actually I only tested L2, but with L1 it's kind-of obvious) < 1613251750 278839 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this isn't surprising, the L2/L3 bottleneck is one of the most common limiting factors on a program's speed < 1613252025 349013 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :By the way, did you know there's a simple trick for making a queue that support insert, remove, and monoidal product in amortized constant time? < 1613252043 456453 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's a variant of the two-stack queue trick. < 1613252053 600415 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :how is the product defined? < 1613252061 892068 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :appending one queue to another? < 1613252102 431476 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean product of the contents, sorry. < 1613252129 626296 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm still not sure I grasp what the definition is < 1613252175 803761 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example you can ask for the maximum of the elements currently in the queue. < 1613252190 520732 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah, basically a fold over the entire queue < 1613252195 621839 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1613252239 235402 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :can't you just implement that by draining the entire queue and calculating the product as you go, amortizing it against the time spent to insert? < 1613252258 636442 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, hmm, is this nondestructive? < 1613252267 525441 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in that case I can see how it might be doable but it's nontrivial < 1613252279 540091 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What do you mean? < 1613252296 138728 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, you can ask for the product without removing elements, if that's what you mean. < 1613252312 795571 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right < 1613252312 847841 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example you can use this to calculate sliding window products over an input list. < 1613252408 190451 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm guessing it involves some sort of cache of partial results for sections of the queue; alongside each element, you have a number of elements later than it for which the monoidal product has been calculated (maybe 0), and the value of the product over that many elements < 1613252451 59022 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not 100% sure this algorithm works, but if it's wrong it sounds fixable < 1613252452 806174 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( data FingerQueue a = Empty | One a | Nest a (FingerQueue (a,a)) a ) < 1613252456 75215 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I suppose it does have that property, but I think it's much simpler than what you're thinking. < 1613252483 307668 :int-e!~noone@int-e.eu PRIVMSG #esoteric :oh, wait, you need digits too < 1613252497 308952 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The trick is like a two-stack queue, except the out-stack contains running products instead of values. < 1613252521 816029 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you might store ([abc,bc,c],[f,e,d],def) < 1613252546 125358 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( data FingerQueue a = Empty | OneTwo (Digit a) | Nest (Digit a) (FingerQueue (a,a)) (Digit a); data Digit a = One a | Two a a < 1613252549 149893 :int-e!~noone@int-e.eu PRIVMSG #esoteric :) < 1613252556 643986 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(The "def" is the product of the entire in-stack.) < 1613252569 101806 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When the out-stack is empty, you compute running products of the in-stack into it. < 1613252571 946684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah, I see, the product of the in-stack is calculated twice < 1613252580 800024 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but that doesn't affect the constant-time nature < 1613252586 139786 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because it's calculated exactly twice and 2 is a constant < 1613252597 315582 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. < 1613252622 217712 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can also represent it with a regular mutable queue with a separator between products and values: [abc,bc,c|d,e,f] def < 1613252658 42840 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this seems like a useful data structure < 1613252668 823022 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although I'm not immediately clear on what you'd use it for < 1613252705 609216 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I wonder if there's a way to make it work for random access (think a database table where you can add and remove rows in any order, and always want to know the maximum value of a particular column) < 1613252705 990160 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The original context I wanted it for was computing maximums of windows of an array. < 1613252729 763606 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Though for that case there's a more specialized algorithm which I think is more efficient. < 1613253094 401444 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"also, for aligned writes, it doesn't matter whether you use a misalignment-capable writing instruction or not, the processor notices that the address is aligned" => yes, the manual explicitly says that there's no performance difference anymore between the aligned and non-aligned instruction on newer cpus, nor between the integer vector bitwise and floating point vector bitwise instructions, they're < 1613253100 618656 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :just separate because they had different performance on older cpus < 1613253234 418178 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and also that misaligned access only has performance penalties if it's from different cache lines (or possibly if you're trying to write then very quickly read from an overlapping address, but that's not really an alignment trouble, it's just missing the optimization where quickly reading the same thing that you wrote can bypass even the L1 cache) < 1613253241 512215 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, following multiple links from shachaf's linked twitter thread, I found a Microsoft blog post that uses Intel syntax and the "movabs" instruction < 1613253241 608185 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which leads me to think that x86 assembler syntax actually isn't properly standardised at all < 1613253241 712808 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(both AMD and Intel call the instruction in question "mov", I think "movabs" is a gcc/gas thing) < 1613253264 273315 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :"this is a Whiskey Lake microarchitecture" => what ... is hat a real architecture name? they have the weirdest names these days < 1613253307 857209 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's other weirdness, like "xorps / movdqu" as a method of zeroing memory (I believe that both AMD and Intel have processors on which xorps / movups would be equivalent and faster with no downsides) < 1613253335 224899 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, wait < 1613253340 139032 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :xorps is one of those weird exceptions < 1613253365 737489 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is treated as an int instruction by some processors and a float instruction by others < 1613253383 858061 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the whole movdqu/movups distinction is one of the weirdest bits of x86 as it is < 1613253452 820170 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I think even some very recent processors have a latency (but not throughput) penalty if you access the same register with both an int instruction and a float instruction in consecutive cycles < 1613253476 460451 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the problem being, they don't agree on whether xorps is an int or a float instruction, so there's no way to get a guaranteed match between it and another instruction < 1613253597 747476 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can work around the issue by using pxor, but that's one byte longer if targeting an xmm register with a source for which any registers involved are numbered in the range 0-7 < 1613253629 382286 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, hmm < 1613253639 392781 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" I'm not sure there's much use for misaligned writes that are guaranteed to fit within a single cache line" => there used to be one somewhat rare but important use, for when you want to shift a vector register by a variable number of bytes, and to do that, you do a maybe-unaligned read to get an index vector, then use that index vector with the PBLENDB or newer shuffle instruction. maybe the < 1613253643 42641 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think pxor and vpxor actually have different rules for this, just to make things even more complex < 1613253645 414041 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :specific use case is obsolete with some later instructions, but I think something similar still exists. < 1613253676 641280 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that uses a misaligned *read* < 1613253680 850819 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and it is still useful I think < 1613253695 739082 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but writes are less obviously useful < 1613253697 547232 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :or maybe it's not for shifting bytes, where you don't need this too much, but something similar. < 1613253713 189199 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ok, sorry, that's stupid, it's probably not actually a use case, ignore it < 1613253721 18992 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(especially because the normal advice for small copies where the relative distance between source and destination is misaligned is "read misaligned, write aligned") < 1613253773 119799 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've been working on a program over the last few days where I have an infinitely repeating PSHUFB pattern but the repeat length is an odd number < 1613253789 211321 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I have the choice of making 32 copies of it so that I can read it aligned at any position, or of reading misaligned < 1613253814 925397 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" it's more about having a model for the slowdown, possibly even an explanation" => the L1 cache caches memory in 64-byte chunks called cache lines. if you're writing misaligned data, the L1 cache has to work harder because it has to update two of these, and also possibly communicate more with the L2 cache if the lines aren't yet in the L1 cache. isn't that enough of a mental model? < 1613253858 898422 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I think int-e thinks that that's a possible explanation of the slowdown but doesn't know whether it's the *correct* model or not, and wants to find some way to establish whether or not it is < 1613253875 108677 :int-e!~noone@int-e.eu PRIVMSG #esoteric :right < 1613253886 78566 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think it's been established that *page*-misaligned memory accesses are slow because you need to access the TLB twice, but that's a very rare case < 1613253946 69748 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I'm off for tonight though, have fun! < 1613254057 235998 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" By the way, did you know there's a simple trick for making a queue that support insert, remove, and monoidal product in amortized constant time?" => there's a heavyweight trick for that: use a finger tree, but in each node, cache the fold of the leaves descending from it. there's probably a much better way if you want just a queue. This is more useful for the general case, when you want a < 1613254063 244439 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :sequence that you can cut and paste anywhere and want to be able to get the product of keys in any subsequence. < 1613254067 632059 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :s/subsequence/range/ < 1613254107 803167 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :or similarly for an ordered keyed dictionary where you want to be able to compute the fold of a weight (secondary key) field for any range < 1613254133 472469 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :a structure that you can insert to, remove from, and answers questions like "what is the sum of weights of items with key between x and y" < 1613254168 951401 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but it's possible that this doesn't actually give you amortized constant time, only amortized logarithmic time < 1613254262 414345 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I was trying to work out if it's always possible to keep the tree balanced in amortized constant time, but it is, you can use any of the normal tricks for self-balancing trees and just recalculate the cache value of the modified nodes at every tree rotation < 1613254322 414656 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm. I think you can keep B-trees balanced in amortized constant time, but not if you have folds in the internal nodes. < 1613254332 800786 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :of course, for invertible structures like sums, there are often much cheaper algorithms (e.g. if you want to know the sum of elements in a queue, just track the sum and add to it on push, subtract from it on shift) < 1613254334 261419 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Because then you need to ascend up the spine on every mutation. < 1613254350 283776 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, invertibility makes it much easier. < 1613254399 265338 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" The original context I wanted it for was computing maximums of windows of an array." => ah yes, that might be related to one of my favorite algorithmic problems, one I've already mentioned here: you get a list of machine word sized nonnegative integers, find the infix in it to maximize the product of the length of that infix and the minimum of its values < 1613254445 481567 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, I wonder if it's possible to make a sort of heap where the heap property is updated only lazily, and if this might be amortized-faster than more regular implementations < 1613254498 15071 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which thing could be faster? < 1613254503 252737 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" b_jonas: I think even some very recent processors have a latency (but not throughput) penalty if you access the same register with both an int instruction and a float instruction in consecutive cycles" => even if they're the same vector size? < 1613254517 338022 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :is this on intel or AMD? < 1613254579 988528 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: both companies have seen that behaviour at various points in time, I forget which one it is which has it on recent processors, let me look it up < 1613254636 734782 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :also, if you're trying to use xorps for zeroing a register, I think all cpus except very old ones have optimizations specifically for zeroing registers, both general and vector, and these might make the ordinary problem of integer vs float instructions moot. but maybe that's not what you want the xorps for. < 1613254728 909666 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :apparently Intel Skylake+ has some such delays, but only for rare combinations like integer logical operation → floating-point multiply, they don't trigger on things like moves; AMD Zen 3 has a 1-cycle delay for any sort of mismatch < 1613254741 962773 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: oh, you want specifically misaligned *write* guaranteed within a cache line only. yeah, I don't know a good case for that. < 1613254747 346342 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so that's the most recent architecture family for both Intel and AMD < 1613254849 335124 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" Because then you need to ascend up the spine on every mutation." => no, not if you use a balanced tree optimized for persistent (no mutating in place) access < 1613254869 442979 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and if it's a queue, inserting only at the ends, that can help < 1613254935 976197 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: re integer and float vector penalties, I see. < 1613254952 86175 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and AMD Zen isn't the low power notebook family, right? < 1613254967 847989 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :if it's any sort of mismatch, that is serious < 1613254991 339566 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :if it's just certain floating point multiplies, that sounds less of a problem < 1613255122 266029 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Zen is the super-high performance family < 1613255143 249618 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :good < 1613255165 942463 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I learned something new then < 1613255170 872577 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it's a latency penalty, not throughput, so I'm guessing that the issue is that there are integer vectors and floating point vectors on different physical parts of the chip < 1613255195 545901 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :an xor is cheap enough that having two separate xor units is probably cheaper than finding the wires to quickly move data from one end of the chip to the other < 1613255234 214290 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :yes, but a latency penalty often translates to a throughput penalty, because if you try to solve it, you run into a decoder bottleneck, even on AMD < 1613255239 267524 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :all this said, I'm rather confused at why all these floating-point logical operations exist at all, xor'ing floats is not the sort of thing that's particularly mathematically meaningful < 1613255252 131466 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: they exist for conditionals mostly < 1613255260 45314 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, I see < 1613255264 83150 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :also for negation and for ldexp and frexp < 1613255273 142181 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :using the all-1s "floating point" value as a boolean true < 1613255274 696011 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :negation isn't too important, you can use subtraction for that < 1613255290 672322 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but ldexp and frexp and safe conversion to and from integers does have to involve them < 1613255292 311487 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :is all-1s +infinity, or is it a NaN? < 1613255294 77564 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but mostly it's comparisons < 1613255312 311365 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :the floating point comparison instructions before AVX512 give floating point result in the performance sense < 1613255324 248833 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: compilers compile -x on floating point x to an xor with a sign-bit constant < 1613255343 85338 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :subtraction from 0 actually gives different results (related to negative versus positive zero and the sign bit on NaNs) < 1613255349 650532 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, you have to subtract from -0 < 1613255356 757033 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, of course < 1613255361 927320 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :because -0 is the additive unit of floating point, not 0 < 1613255364 923155 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that still has a different effect on the sign bit of NaNs < 1613255365 601604 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it's always -0 < 1613255391 872417 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, subtraction from -0 is no more efficient than xor with the sign-bit number < 1613255399 419471 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it has a different effect on NaNs, but compilers in general don't give good enough tools to handle NaNs deterministically: < 1613255407 474231 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually… is the sign bit number -0 when interpreted as a float? < 1613255429 584313 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :you can't force a compiler to not swap the operands of a floating point addition without inline assembly < 1613255432 671296 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`! c printf("%g", 0x8000000000000000L); < 1613255436 584133 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0 < 1613255447 969579 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that looks suspiciously like a negative zero to me < 1613255458 286350 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which would make sense, as it's just 0 with the sign bit flipped < 1613255471 870442 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I guess the question is "xor with -0 or subtract from -0?" < 1613255486 609452 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :floating point xor and subtraction are equally fast, xor might use less power though? < 1613255516 507960 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: my guess is that compilers (usually) compile negation that way because it's less likely that you run out of execution units that do floating point addition, which can in rare cases be a bottleneck in numeric code, like in matrix multiplication AI nonsense, if it's hyperoptimized, and otherwise the difference doesn't matter < 1613255554 31968 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, that might be the case on old processors < 1613255564 79448 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :no, I mean on recent Intel cpus < 1613255571 503684 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it's a difference that doesn't come up often, I admit < 1613255573 455121 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think in modern processors, floating point adds can be done on any vector unit, and floating point xors can't be done on a scalar unit < 1613255581 598829 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but I don't see a reason to use subtraction instead of xor < 1613255586 750414 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :well < 1613255589 141262 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ok, that's not true < 1613255614 798803 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :if you do not care about negative zero, then subtraction may be faster if you have register pressure, because loading 0 is faster. but usually you care about negative zero. < 1613255655 995875 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :on Coffee Lake, xorps and pxor both run on 0/1/5 (the three main ALUs), addps and addss only run on 0/1 < 1613255672 475259 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, so you're right, there is one vector unit that can handle floating point logic but not floating point add < 1613255682 342232 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" I think in modern processors, floating point adds can be done on any vector unit, and floating point xors can't be done on a scalar unit" => that sounds like you're either talking about a newer microarchitecture or another brand than the ones I'm the most familiar with < 1613255697 647956 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the other ALU is 6, which can do XORs but probably isn't capable of reading vector registers < 1613255704 672226 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: no, I was just mistaken < 1613255740 145804 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: wait, is this for a vector negate, or for negating a single float? < 1613255743 157068 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for a comparison, paddq runs on 0/1/5 < 1613255752 835438 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: single float < 1613255810 449077 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it hardly matters, assuming you're using SSE/AVX as the FPU (which is the only sane default on x86-64), single-float and vector-float instructions are encoded and executed almost identically (the only difference is a single bit in the instruction encodings) < 1613255823 784100 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: wait wait < 1613255836 498488 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also I think the vector instructions are actually faster in cases where the destination is a different register from the sources < 1613255840 943004 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: 32 bit or 64 bit? doesn't 64 bit float subtract have a longer instruction encoding by one byte? < 1613255852 823375 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :whereas for the xorps it doesn't matter < 1613255856 353137 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: oh right, there's the SSE special case < 1613255860 79243 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :because you can use xorps for 64-bit < 1613255864 746212 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I'm not sure < 1613255867 946273 :TheLie!~TheLie@24.134.17.157 JOIN :#esoteric < 1613255873 510188 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :where …ps instructions are 1 byte shorter < 1613255877 989684 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :I don't really remember all the SSE2 encodings < 1613255881 527415 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if not vex-encoded < 1613255914 472504 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :basically, the way to think about it is: you have two encoding families for vector instructions, SSE and VEX < 1613255949 937233 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :all I remember is that there's a rare special case when using MMX registers as temporaries when you run out of general purpose registers in a tight loop can be worth just because MMX has shorter encodings than SSE2 < 1613255958 878699 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the only functionality difference is that the VEX encodings have a V at the start of the instruction name, and zero the high 128 bits of a ymm register if you write the low 128 bits; the SSE instructions have no V and will leave the high 128 bits unchanged < 1613255990 149928 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :both encoding families have a special case where they're one byte shorter < 1613256000 514132 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :SSE is one byte shorter for …ps instructions, which is a simple enough rule to remember < 1613256002 381876 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, I understand that part, but I mean the pre-AVX MMX/SSE/SSE2/SSSE3/SSE4.1/SSE4/2 instructions have a lot of encoding detail < 1613256022 903488 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :and I don't remember when the shortcuts apply, as in when you need fewer prefixes < 1613256073 722052 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: although while we're there, you say that modern AMD has latency penalties for mixing integer and floating point vector instrs. does it also have penalties for mixing 32-bit and 64-bit floating point instructions, including for the bitwise? < 1613256082 277569 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, instructions are allocated to various "maps"; map 1 instructions are 1 byte shorter in SSE < 1613256091 163084 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whereas they're one byte shorter in VEX only if none of the input arguments access a register numbered 8-15 inclusive (it's OK if the output does) < 1613256164 146482 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: apparently not, you can type-pun float as double and back for free < 1613256218 483276 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's another reason I think it's likely that the issue is "this register is stored physically near the floating-point units" rather than anything to do with caching extra metadata about floats < 1613256356 235406 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also, for anyone reading this who doesn't know, it's worth remembering that registers named in machine code instructions generally no longer have any real relationship to physical registers on the processor, they're just a convenient way of telling the processor which instructions are meant to give their output to which other instructions) < 1613256373 238349 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :ais523: sure, but you could have 32-bit and 64-bit float units physically distant too, just as the integer vs float unints < 1613256414 839106 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :or are all the optimized-for-marketing fma units so important that that's not worth? < 1613256471 914507 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fma is mildly useful, I'm not sure how heavily it drove into processor marketing < 1613256489 155528 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, it is an operation that is *very* hard to do efficiently without processor support, so the people who needed it probably really needed it < 1613256514 358140 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(and it also made Intel rearchitecture significant parts of their processor internals, so they probably wouldn't have done it unless there was heavy demand) < 1613256557 672957 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :until FMA was added, Intel processors couldn't take more than two inputs to any internal instruction, and there were horrible things going on micro-architecturally to avoid having to do that < 1613256570 887849 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but there's pretty much no way around taking three inputs to an FMA instruction < 1613256572 416619 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1613256583 983552 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess if Intel are going to go to that effort, they're going to market it heavily < 1613256689 636031 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it's certainly useful to optimize fma so that the CPU can do matrix multiplications quickly. but Intel pushed that a bit too far, pushing benchmarks for matrix multiplications or similar used for fashionable AI nonsense, apparently optimizing for the benchmarks of that one thing more than the large variety of tasks that a CPU should handle. that's when you got a cpu where you run out of execution units < 1613256695 640876 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :with floating point add faster than with fma. that was a few years ago admittedly. < 1613256764 992211 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, that's hilarious < 1613256784 752933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :looks like FMA runs on 0/1 nowadays < 1613256809 873493 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the same as floating point add, and floating point multiply, individually < 1613256958 491437 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :also some people claim that they're optimizing for marketing "number of instructions" the way AVX512 was defined, in a way that adds a bit too much historical load that they have to support in all future CPUs. I don't really buy that. I think it only seems like that partly because they're adding a larger variation of instructions that are *easy* to implement, which seems redundant but actually helps < 1613256964 499192 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :because of how often the decoder and neighbors is the bottleneck, and partly because of the AVX512 mask registers, which admittedly seems a weird design and possibly not the best idea, but might turn out to be good after all for all I know. < 1613256995 160618 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :" looks like FMA runs on 0/1 nowadays / the same as floating point add, and floating point multiply, individually" => yes, what I mentioned was pre-AVX512 < 1613257051 190995 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is a non-AVX-512 processor (although after it was invented) < 1613257072 175436 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :AVX-512 looks like something that Intel doesn't want to have as a "default" feature in consumer processors, at least not yet < 1613257098 734642 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and actually, at some point increasing the size of the vector units isn't going to help much because the bottleneck will be memory/cache speed and not compute speed < 1613257144 221671 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :sure < 1613257224 50706 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :but, just like AVX and AVX2, AVX512 also adds new instructions or instruction modes on shorter vectors, most notably the additional vector registers and the mask registers, not only wider vectors < 1613257234 153280 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :it's not only about the width < 1613257322 796599 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :that's why it is worth to have low-power cpus that support the AVX2 instruction set but only 16 byte execution units and decoding the 32 byte wide instructions to run on two execution units, and similarly it can be worth to have AVX512 instructions that only have 32 byte wide execution units < 1613257343 865338 :b_jonas!~a@catv-176-63-12-131.catv.broadband.hu PRIVMSG #esoteric :well, partly that's why. the other part is decoding. < 1613257399 398619 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think many modern procesors turn off half the vector registers most of the time to save power < 1613257422 308325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and will run 32-byte instructions by passing them through the low half of the vector units twice while the high half is busy turning on < 1613258421 342053 :arseniiv!~arseniiv@95.105.2.1.dynamic.ufanet.ru QUIT :Ping timeout: 264 seconds < 1613259115 353003 :delta23!~deltaepsi@unaffiliated/deltaepsilon23 JOIN :#esoteric < 1613259824 369771 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1613260011 108411 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1613260113 358471 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds