< 1543881684 162241 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Read error: Connection reset by peer < 1543883802 159610 :Melvar!~melvar@dslb-002-203-099-095.002.203.pools.vodafone-ip.de QUIT :Ping timeout: 268 seconds < 1543884109 273128 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com QUIT :Quit: Qutting < 1543885566 681051 :mniip!mniip@freenode/staff/mniip QUIT :Ping timeout: 630 seconds < 1543885755 438992 :Melvar!~melvar@dslb-002-203-087-130.002.203.pools.vodafone-ip.de JOIN :#esoteric < 1543888568 243716 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm surprisingly annoyed at the lack of boxed-slice constructors in Rust < 1543888594 204620 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you have to go via a temporary Vec if you want one (assuming that the size isn't known at compile time) < 1543888600 850801 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even if you know the size at runtime < 1543888603 824731 :nfd9001!~nfd9001@140.160.182.116 JOIN :#esoteric < 1543888843 430924 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even if you know the size at runtime < 1543888851 847876 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whoops, meant to do that in my shell, not IRC < 1543888971 108101 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Do you know how to play poker with tarot cards or mahjong with pokemon? < 1543889110 743607 :nfd9001!~nfd9001@140.160.182.116 QUIT :Ping timeout: 250 seconds < 1543889122 458796 :xkapastel!uid17782@gateway/web/irccloud.com/x-zbmakvgafuehpsci QUIT :Quit: Connection closed for inactivity > 1543889328 835544 PRIVMSG #esoteric :14[[07+-14]]4 10 02https://esolangs.org/w/index.php?diff=58559&oldid=58522 5* 03Cortex 5* (+69) 10/* Examples */ > 1543889717 931130 PRIVMSG #esoteric :14[[07Omgrofl14]]4 10 02https://esolangs.org/w/index.php?diff=58560&oldid=58453 5* 03Cortex 5* (-110) 10 > 1543889739 919106 PRIVMSG #esoteric :14[[07Template:Dead memes14]]4 N10 02https://esolangs.org/w/index.php?oldid=58561 5* 03Cortex 5* (+123) 10Created page with "'''WARNING''': This article contains high amounts of dead memes and outdated jokes. Please remember that before proceeding." > 1543889776 938813 PRIVMSG #esoteric :14[[07Surround notation14]]4 10 02https://esolangs.org/w/index.php?diff=58562&oldid=22152 5* 03Cortex 5* (+16) 10/* Examples */ < 1543892436 14048 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Do you like this? < 1543892496 355615 :paul2520!~paul2520@unaffiliated/paul2520 PRIVMSG #esoteric :poker with tarot, interesting < 1543892510 31364 :paul2520!~paul2520@unaffiliated/paul2520 PRIVMSG #esoteric :I've been meaning to find a use for mine. < 1543892683 211164 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :There are a number of different games played with tarot. Originally the games were trick taking games, somewhat like whist or bridge, except there is one suit of permanent trumps. In some games the Fool is the highest trump, and in some other games, you can play it at any time even if you are able to follow suit but you will always lose the trick if you play it (it is sometimes called "Excuse" in this case). < 1543892787 692821 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :(Even though it is either the highest trump or has no numerical value, still it seems it is commonly labeled zero. Someone told me that it is zero because it represents the beginning of a journey; I can see how, although that still does not seem a good enough reason to call it zero when its value in the game isn't actually zero.) < 1543893262 377695 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :There are a few different games you can find, actually. If you have Latin-suited cards and the rules mention French-suited or vice-versa, you can use the following correspondences: spades=swords, clubs=rods/wands, diamonds=coins (sometimes they have pentagrams printed on them; it is fine if they do), hearts=cups < 1543893412 228633 :sebbu!~sebbu@unaffiliated/sebbu QUIT :Ping timeout: 246 seconds < 1543893866 127938 :paul2520!~paul2520@unaffiliated/paul2520 PRIVMSG #esoteric :very interesting < 1543894245 352361 :mniip!mniip@freenode/staff/mniip JOIN :#esoteric < 1543894475 853580 :sebbu!~sebbu@unaffiliated/sebbu JOIN :#esoteric < 1543898252 744225 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1543898325 809896 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1543899074 941090 :zzo38!~zzo38@24-207-47-161.eastlink.ca QUIT :Ping timeout: 246 seconds < 1543899412 830653 :zzo38!~zzo38@24-207-47-161.eastlink.ca JOIN :#esoteric < 1543899505 476990 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Hello < 1543900202 34381 :doesthiswork!~Adium@131.191.115.81 QUIT :Quit: Leaving. < 1543901324 156555 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Hello < 1543901330 56441 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Sorry < 1543901370 485164 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :O, good, I didn't miss any < 1543901931 910331 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1543902032 934639 :zzo38!~zzo38@24-207-47-161.eastlink.ca QUIT :Ping timeout: 250 seconds < 1543902042 414294 :zzo38!~zzo38@24-207-47-161.eastlink.ca JOIN :#esoteric > 1543905325 915136 PRIVMSG #esoteric :14[[07HARSH14]]4 10 02https://esolangs.org/w/index.php?diff=58563&oldid=58549 5* 03ShareMan 5* (+1059) 10Fixed computation classification, and just generally made things cleaner, easier to understand, etc. < 1543908028 315303 :arseniiv!~arseniiv@77.79.183.229.dynamic.ufanet.ru QUIT :Ping timeout: 245 seconds < 1543909806 881100 :imode!~imode@unaffiliated/imode QUIT :Ping timeout: 250 seconds < 1543910844 383339 :xkapastel!uid17782@gateway/web/irccloud.com/x-lhkudfsqamydwbpy JOIN :#esoteric < 1543911557 281759 :doesthiswork!~Adium@131.191.115.81 JOIN :#esoteric < 1543912893 971249 :oerjan!oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1543914635 533839 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :oh they've removed +r < 1543917203 324735 :Vorpal!~Vorpal@unaffiliated/vorpal QUIT :Ping timeout: 245 seconds < 1543917487 867911 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 JOIN :#esoteric < 1543917854 492550 :Vorpal!~Vorpal@unaffiliated/vorpal JOIN :#esoteric < 1543918754 384988 :doesthiswork!~Adium@131.191.115.81 QUIT :Quit: Leaving. < 1543920217 620836 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :otppenztarak.hu has one of the worst authentication system I've ever seen on a website < 1543920284 448356 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :the start seems sane: you enter your email address, which identifies your account, and your password, which you have set earlier. the password has some stupid restrictions on it: I think it must contain at least two digits or something stupid like that. < 1543920308 980074 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but then, it sends you a one-time token in email that is valid for 10 minutes only. who the heck thinks that everyone can receive email in 10 minutes? < 1543920807 169938 :oerjan!oerjan@hagbart.nvg.ntnu.no QUIT :Quit: Later > 1543923250 752700 PRIVMSG #esoteric :14[[07User:Salpynx14]]4 10 02https://esolangs.org/w/index.php?diff=58564&oldid=58302 5* 03Salpynx 5* (-119) 10 > 1543923337 860067 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=58565&oldid=58534 5* 03Salpynx 5* (+11) 10/* A */ A-DU < 1543923381 320313 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :`bobadventureslist http://bobadventures.comicgenesis.com/d/20181204.html < 1543923382 603073 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :bobadventureslist http://bobadventures.comicgenesis.com/d/20181204.html: b_jonas > 1543923424 194494 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=58566&oldid=58565 5* 03Salpynx 5* (+15) 10/* G */ > 1543923701 759371 PRIVMSG #esoteric :14[[07Joke language list14]]4 10 02https://esolangs.org/w/index.php?diff=58567&oldid=58426 5* 03Salpynx 5* (+80) 10/* General languages */ 42 < 1543923850 257174 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :ais523: re rust boxed slice constructors, I was confused about that at first, but it turs out that there's a really good reason why it's done this way < 1543923921 208033 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :ais523: the problem is that a slice or boxed slice has the type invariant that all the elements of he slice are initialized, and you can't initialize a general type, so you can't just make a general boxed slice constructor for any type < 1543924033 208402 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :ais523: however, you can initialize the elements one by one from left to right, keeping track how much is initialized. in fact, Vec does exactly that, and the rust std guarantees that a Vec allocates the contents the same way as a boxed slice. so there's a safe method that converts a Vec to a boxed slice that is guarateed to not reallocate the memo < 1543924033 343094 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :ry if the Vec's size is equal to its capacity. < 1543924123 764230 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :the box is effectively just a start pointer, a size and a capacity; and a boxed slice is effectively a start pointer and a size; and this pointer and size and capacity are local variables that the optimizer can see directly when optimizing your program when you fill a vec. < 1543924236 134140 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :So the general way to create a boxed slice is to create a boxed vector, possibly extend it to the capacity if you know the size in advance, then push the elements from left to right, then convert it to a boxed slice, which is at that point free. You can even abort by throwing away the vec. < 1543924302 433236 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :There are some convenience abstractions around this in std, but perhaps not enough, and that part of your complaint might be valid. < 1543924313 961467 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :But you can write any missing abstractions yourself. < 1543924342 896428 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :If you want to initialize the slice in an order different from left to right, then you're somewhat screwed though. < 1543924349 226344 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :There are ways to do that, but they're not easy. < 1543924386 141725 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :And they're unsafe because there's no way to prove to the compiler that you kept track of which elements are initialized correctly. < 1543924396 717925 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 268 seconds < 1543924552 821667 :Lord_of_Life!~Lord@46.217.121.194 JOIN :#esoteric < 1543924552 960881 :Lord_of_Life!~Lord@46.217.121.194 QUIT :Changing host < 1543924552 960912 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1543924678 394963 :zzo38!~zzo38@24-207-47-161.eastlink.ca QUIT :Ping timeout: 250 seconds > 1543924926 525572 PRIVMSG #esoteric :14[[07APLBAONWSJAS14]]4 10 02https://esolangs.org/w/index.php?diff=58568&oldid=57861 5* 03Salpynx 5* (+154) 10/* Interpreter */ Python3 interpreter silliness > 1543925030 664414 PRIVMSG #esoteric :14[[07APLBAONWSJAS14]]4 M10 02https://esolangs.org/w/index.php?diff=58569&oldid=58568 5* 03Salpynx 5* (+37) 10/* In other languages */ > 1543925318 868292 PRIVMSG #esoteric :14[[07User:Salpynx14]]4 10 02https://esolangs.org/w/index.php?diff=58570&oldid=58564 5* 03Salpynx 5* (+133) 10/* Code for languages created by others */ < 1543925565 463574 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :ais523: I think if you want to initialize the elements in an order other than left to right, then you're screwed. I don't see a sane way to do that and get a Box from it. < 1543925648 697426 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :You can use a custom container, which uses Box<[std::mem::MaybeUninitialized]> for allocation and deallocation, fill the elements in place in whatever order you want, and once you're sure that all elements are initialized to a valid states, you can expose the contents as a &mut [T], and you can implement this as an unsafe method that calls mem:: < 1543925648 823698 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :transmute on the slice (not on the box) < 1543925810 397334 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au JOIN :#esoteric < 1543926119 456149 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :nope, it's even worse if the type has a destructor < 1543926163 516078 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au QUIT :Ping timeout: 244 seconds < 1543926220 429170 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :you need a Box<[std::mem::MaybeUninitialized>]> for that > 1543926241 942261 PRIVMSG #esoteric :14[[07Grime MC14]]4 10 02https://esolangs.org/w/index.php?diff=58571&oldid=58464 5* 03Salpynx 5* (+632) 10Notes on macros < 1543926791 927347 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :but probably only for a year or two more, I think people already want to add a single wrapper for std::mem::MaybeUninitialized> because it's too common < 1543926814 388815 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :I bet you'll find one in std within two years < 1543927504 784829 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator QUIT :Ping timeout: 268 seconds < 1543927551 919366 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator JOIN :#esoteric < 1543927741 656003 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au JOIN :#esoteric < 1543928551 140707 :arseniiv!~arseniiv@77.79.183.229.dynamic.ufanet.ru JOIN :#esoteric < 1543928577 763240 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au QUIT :Ping timeout: 268 seconds < 1543930555 295208 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com JOIN :#esoteric < 1543930570 988327 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com QUIT :Max SendQ exceeded < 1543930595 231233 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com JOIN :#esoteric < 1543932029 604160 :doesthiswork!~Adium@131.191.115.81 JOIN :#esoteric > 1543936774 380357 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58572&oldid=46762 5* 03Gamer 5* (+15) 10/* Truth-machine */ > 1543936793 426962 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58573&oldid=58572 5* 03Gamer 5* (+0) 10/* Truth-machine */ > 1543936843 325088 PRIVMSG #esoteric :14[[07Element14]]4 M10 02https://esolangs.org/w/index.php?diff=58574&oldid=58573 5* 03Gamer 5* (+0) 10/* Truth-machine */ > 1543936942 502265 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58575&oldid=58574 5* 03Gamer 5* (-46) 10/* Nth Triangular Number */ > 1543936960 385134 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58576&oldid=58575 5* 03Gamer 5* (-2) 10/* Digital root calculator */ > 1543937205 228329 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58577&oldid=58576 5* 03Gamer 5* (-113) 10/* N Factorial */ > 1543937295 973929 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58578&oldid=58577 5* 03Gamer 5* (+0) 10/* Nth Triangular Number */ > 1543937610 879197 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58579&oldid=58578 5* 03Gamer 5* (-121) 10/* GCD of two numbers */ > 1543937622 768633 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58580&oldid=58579 5* 03Gamer 5* (+24) 10/* N Factorial */ < 1543937624 791381 :siraben!sirabenmat@gateway/shell/matrix.org/x-wifwvpemkbaofyie PART #esoteric :"Kicked by @appservice-irc:matrix.org : issued !quit command" > 1543937635 450002 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58581&oldid=58580 5* 03Gamer 5* (+24) 10/* Digital root calculator */ > 1543937789 81654 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58582&oldid=58581 5* 03Gamer 5* (+46) 10/* N Factorial */ > 1543937826 684289 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58583&oldid=58582 5* 03Gamer 5* (+36) 10/* Truth-machine */ > 1543937866 230879 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58584&oldid=58583 5* 03Gamer 5* (-40) 10/* GCD of two numbers */ > 1543937964 57367 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58585&oldid=58584 5* 03Gamer 5* (-45) 10/* Nth Fibonacci number */ > 1543937986 813219 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58586&oldid=58585 5* 03Gamer 5* (-34) 10/* GCD of two numbers */ > 1543938132 568044 PRIVMSG #esoteric :14[[07Element14]]4 10 02https://esolangs.org/w/index.php?diff=58587&oldid=58586 5* 03Gamer 5* (+76) 10/* Digital root calculator */ < 1543938251 744351 :myname!~myname@ks300980.kimsufi.com PRIVMSG #esoteric :talk about exeggerating < 1543938922 747913 :hexfive!~hexfive@50-46-223-124.evrt.wa.frontiernet.net JOIN :#esoteric < 1543939872 726369 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 QUIT :Quit: http://www.kiwiirc.com/ - A hand crafted IRC client < 1543943642 849453 :zzo38!~zzo38@24-207-47-161.eastlink.ca JOIN :#esoteric > 1543948153 160627 PRIVMSG #esoteric :14[[07414]]4 10 02https://esolangs.org/w/index.php?diff=58588&oldid=46060 5* 03Gamer 5* (-13) 10/* Hello World! */ < 1543949391 201056 :oren!~oren@ec2-18-212-11-99.compute-1.amazonaws.com PRIVMSG #esoteric :DYK? "lockheed" is pronounced /lɒxid/ < 1543949489 347525 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's the c doing in there? < 1543949774 859970 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1543950356 572176 :hexfive!~hexfive@50-46-223-124.evrt.wa.frontiernet.net QUIT :Quit: WeeChat 2.2 > 1543950642 187423 PRIVMSG #esoteric :14[[07Alphuck14]]4 10 02https://esolangs.org/w/index.php?diff=58589&oldid=57853 5* 03Gamer 5* (-28) 10/* Hello, world! program */ < 1543951105 258737 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu JOIN :#esoteric < 1543951185 874256 :arseniiv!~arseniiv@77.79.183.229.dynamic.ufanet.ru QUIT :Ping timeout: 252 seconds < 1543951879 142157 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu QUIT :Quit: Reconnecting < 1543951895 848116 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu JOIN :#esoteric < 1543954042 177745 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :`2 quote < 1543954043 169773 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :2/1: < 1543954046 291563 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :no no < 1543954060 744970 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :``` for x in 0 1; do quote; done < 1543954061 395144 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :120) cpressey, oh go to zzo's website. He is NIH AnMaster, really? I was strongly under the impression that zzo was invented here. \ 157) well i just ate some stuff and watched family guy and i own a piano and i'm not wearing socks < 1543954072 896887 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :``` for x in 0 1; do wisdom; done < 1543954073 763479 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​afk//Afk wrote a famous story about hang. \ lunacy//LUNacy is wisdom generated by a neu^Wlayered unit net. Ask Warrigal for details. < 1543954666 269392 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`n 2 quote < 1543954666 787078 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :2 quote/1:/bin/sed: -e expression #1, char 4: extra characters after command \ /hackenv/bin/n: line 1: 2 quote: syntax error in expression (error token is "quote") < 1543954681 439679 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hm < 1543954694 13494 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :that's not right < 1543954815 32925 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` \`^ 2 quote < 1543954816 285004 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :1/1:412) Non sequitur is my forte On-topic discussion is my piano Bowls of sugary breakfast cereal is my mezzoforte Full fat milk is my pianissimo On which note, I'm hungry \ 937) Are you sure this isn't the Sims can you get married to your variables? this is a feature I find lacking in most languages < 1543955193 947853 :Melvar!~melvar@dslb-002-203-087-130.002.203.pools.vodafone-ip.de QUIT :Quit: rebooting < 1543956086 675560 :Melvar!~melvar@dslb-002-203-087-130.002.203.pools.vodafone-ip.de JOIN :#esoteric < 1543956280 153709 :b!603d555c@gateway/web/freenode/ip.96.61.85.92 JOIN :#esoteric < 1543956288 336901 :b!603d555c@gateway/web/freenode/ip.96.61.85.92 QUIT :Client Quit < 1543958410 390641 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net QUIT :Remote host closed the connection < 1543958447 751751 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net JOIN :#esoteric < 1543958522 837561 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1543958581 734773 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does anyone know of a data structure which lets me do this?: we can add elements to the structure and it records when each element was added (new additions replace earlier additions of the previous element), and we can efficiently discover which elements have been added since a specific element was last added < 1543958608 952910 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :something like a linked deque + an index into it would work, I think, but I'm wondering if there's anything simpelr < 1543958684 338388 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`unidecode µ < 1543958684 913867 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​[U+00B5 MICRO SIGN] < 1543959432 502154 :gurmble!~grumble@freenode/staff/grumble NICK :grumble < 1543959677 10701 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net QUIT :Remote host closed the connection < 1543959688 951867 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net JOIN :#esoteric < 1543959822 491646 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :on another note, how many languages use "if … else" (with no "then" clause) for what Perl/Ruby call "unless"? < 1543960013 716520 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au JOIN :#esoteric < 1543960131 730595 :FireFly!znc@freenode/staff/firefly PRIVMSG #esoteric :huh, that's an interesting syntactic idea, and makes enough sense < 1543960298 831027 :zzo38!~zzo38@24-207-47-161.eastlink.ca QUIT :Ping timeout: 250 seconds < 1543960313 470868 :oren!~oren@ec2-18-212-11-99.compute-1.amazonaws.com PRIVMSG #esoteric :if(x == 30);else{ } < 1543960376 497452 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, it's easy enough to stick a dummy "then" part in < 1543960635 671344 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: hi. see logs for today about your rust question. < 1543960712 440691 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't see how a linked deque and index would work, you'd have to update a lot of indexes. a heap and indexes could work, because you can delete any element and you only have to update log(size) number of indexes. < 1543960748 718997 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :hm wait, what operations exactly do you want to do < 1543960892 71978 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the index would be a map from an element to the object representing that element inside the deque (that's why it has to be a /linked/ deque) < 1543960931 578413 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the operations I need that can't trivially be abstracted out into a separate structure are adding an element to the structure, and getting a list of all elements added more recently than a specific element < 1543960945 951683 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also if I add the same element repeatedly, earlier additions should be forgotten rather than leaking memory < 1543960961 879914 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in case it helps, I know all possible elements that could be added in advance < 1543960984 595098 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :elements can be compared for equality easily (in the situation I want to use this they're just integers) < 1543961002 142380 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was hoping that there'd be some existing structure which supports this so that I could look for an implementation in libraries < 1543961031 768457 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :re: the Rust question discussion in logs, I was expecting something that created an /initialised/ boxed slice, e.g. by copying a given element a given number of times (like vec! does) < 1543961107 904659 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: oh, you mean a deque plus an dictionary with the element value as key, and an iterator into the deque as the value. that works, I was confused by "index" then < 1543961124 344602 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :a linked list deque that is < 1543961129 389233 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :so that the elements have stable nodes < 1543961131 683506 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :yes, that works < 1543961132 11317 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I meant it in the sense of "database index" < 1543961144 608141 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :of course, databases are good at this, because they're basically a general-purpose data structure < 1543961151 585241 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it feels like something simpler should work too > 1543961157 919866 PRIVMSG #esoteric :14[[07+-14]]4 10 02https://esolangs.org/w/index.php?diff=58590&oldid=58559 5* 03Cortex 5* (+34293) 10/* Examples */ < 1543961171 750888 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also I'm writing this program in Rust, and a linked deque is one of the simplest things that Rust is /really/ bad at…) < 1543961189 564383 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I was thinking of a heap (such as a binary or quaternary heap) and a dictionary from the key to the index into the heap. I know you can efficiently maintain a dictionary from the element to the index in a binary heap, I've implemented that. < 1543961194 254511 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it's not clear which of these is better her < 1543961256 72768 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: no way. you never delete elements, so you can put the deque nodes in a Vec that will never shrink, and you never waste memory, and use indexes or 32-bit indexes into that Vec for the links. < 1543961288 777944 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: oh, that does work, it's weird to think about using indexes rather than pointers though < 1543961302 399917 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :especially as the bounds checks happen at runtime not compile-time < 1543961309 57532 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :using indexes is generally a good idea because it's easy to automatically bounds checked which catches some (not all) silly mistakes with pointer stupidity, and allows you to use 32-bit indexes in a 64-bit address space < 1543961329 665129 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :no need to allocate each node separately < 1543961370 564317 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :this is the main reason why I think x32 is a silly idea. if in the structures or loops where you really need to optimize for performance, you just use 32-bit indexes, then the 64-bit pointers never bother you. < 1543961403 597211 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :admittedly the rust std isn't too well-suited for that, but ideally if you wrote everything in machine language, that would work, and rust or C++ allow good enough approximations. < 1543961465 23348 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :rust is in a slight disadvantage here, but in the very rare cases when that causes a performance problem, you just optimze the inner loop by reimplementing it in something that isn't rust. < 1543961479 199384 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :or give dirty hints to rust to speed it up < 1543961507 816230 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :doesn't using pointers directly, rather than index + base pointer, reduce register pressure? < 1543961511 643291 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :probably eventually in future rust that won't be necessary, they just add enough stuff in the compiler and std < 1543961538 54356 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: perhaps, but usually register pressure is less of a problem on x86_64 than L1 cache and L2 cache throughput < 1543961545 848344 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and decoder throughput and stuff like that < 1543961566 784292 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :especially on modern x86_64 < 1543961629 125159 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now I'm wondering if simple dereferences like mov [reg], reg take up less instruction-cache pressure than complex ones like mov [base+index*4], reg < 1543961639 588950 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and register throughput problems is something that has some chance of automatically fixing themselves without changing your code when you install a new compiler with a better optimizer, whereas cache throughput is less likely to do that < 1543961673 99677 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: that really depends on the compiler < 1543961734 383068 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :but you aren't likely to get [base+index*4] or [base+index*8] indexes here unless you premultiply your indexes or use avx512, because your element size is greater than 8 bytes < 1543961738 115239 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what's "that" referring to? if it's my most recent comment, I'm talking about at the machine code → micro-op level of abstraction, well below the compiler < 1543961795 407592 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :instead, you'll get a silly 64-bit shift instruction to do the multiplication, and you won't be able to convince rust to optimize that a 32-bit multiplication, because you can't easily tell the compiler that the array size is less than 32 bytes. < 1543961835 555962 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, I see, you're claiming that the more condensed instructions might not even be generatable < 1543961838 318779 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :"that" is referencing "register throughput problems" < 1543961874 567145 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: they might be if you premultiply your indexes or use avx512, but you rarely care that much about performance < 1543961888 515971 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :microoptimize your code only when it's really the bottleneck < 1543961986 588078 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1543962111 204684 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I'd like to note that in this case, since you always insert new elements whose weights are larger than every existing element, inserting a new element takes constant time, you're not moving anything, just pushing an element with the next weight at the end of the array < 1543962124 82231 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :you probably need to keep a counter tha tracks the next weight separately < 1543962156 859477 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :if you rarely update elements, then that's the simplest one, but since you didn't mention deleting elements, I think you want to update elements often < 1543962199 170116 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :mind you, adding a new element to the front of a deque is about as simple < 1543962217 832284 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and the dictionary insert has about the same cost in either case < 1543962226 58334 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :hmm wait < 1543962233 756601 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can't just keep inserting at the end of an array < 1543962237 596990 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :the heap won't work at all < 1543962240 612551 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because then you'll end up growing the array forever < 1543962255 616002 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :or at least, not easily < 1543962275 809594 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: but you need to grow the array when you insert a new element, as opposed to updating an element with an existing key < 1543962327 588599 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ok, I think you're right. use a deque < 1543962333 701256 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :a linked list deque < 1543962468 783355 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :hmm wait, there's a trickier way < 1543962539 977506 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've been looking for existing Rust modules which have the right functionality; one of them uses a really clever trick < 1543962555 657178 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the elements I'm adding are small integers < 1543962589 204837 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and this data structure is designed for them; it basically has an array which stores the next integer and previous integer for each integer n at the nth slot < 1543962593 276507 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: trickier way, slower but less memory: use a singly linked list, with pointers towards older elements, and a dictionary with the value of an iterator to the previous element. when you remove an element, look up the next element by its value in the dictionary, and update that dict entry too as well as the dict entry for the element you move to the front. < 1543962628 243219 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :next /element/, previous /element/ rather than next /pointer/, previous /pointer/ (or simulating pointers using indexes) simplifies things a lot < 1543962642 509456 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: how many elements do you expect to have? if it's very small, like 8, then there are tricks < 1543962669 714424 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it scales based on the size of user input < 1543962670 925707 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: that works only if your elements (keys) are of small size < 1543962678 923371 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it's consecutive from 0 < 1543962688 736502 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: ok, so it's not like always less than 16 < 1543962702 841979 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, in practice it'll usually be small but I don't want a hard limit < 1543962725 835799 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the values themselves are `usize`s) < 1543962756 586572 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: there's a crazy structure used in hardware caches to handle the 8-way caching that stores binom(8,2) bits and lets the hardware update one of the eight slot to make it the newest one, and find the oldest slot so it knows which element to drop when it has to insert a new one < 1543962806 349694 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I probably won't use that, but am curious about how it works < 1543962825 579667 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: if it's between 8 and 64, then you might not care about asymptotic performance, and implement this as a simple vector of the integer values where you search the value with a linear search, and memmove part of the array to insert or delete something < 1543962848 631707 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: there's a bit for each pair of the 8 elements, and it tells whether the first one is newer than the other < 1543962917 526044 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :inserting a new element to a slot needs to update 8 of those 28 bits, which is somewhat easy and fast in hardware in this case < 1543962945 548419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh yes, I can see how that would work now < 1543962993 755473 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :so much that I guess the bottleneck is not that age array, but the dispatch logic to find one of the eight elements matching the 6-bit address < 1543963013 378125 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to be honest a linear search would probably be fast enough for me too, but it was a set of performance properties I hadn't seen before in a data structure, so it prompted me to ask here < 1543963085 972882 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :you need to do that address compare in each of the eight elements, then three layers of if-else to forward one of them, and then a comparison to the upper bits of the address when it arrives from the page table cache (it's not called "page table cache", it has a fancier name that I keep forgetting, but that's what it really is) < 1543963104 42867 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and all of that must go through within a clock cycle ideally < 1543963108 300129 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :in the L1 cache that is < 1543963116 77792 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :you get slightly more slack in the L2 cache < 1543963136 890186 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is a program I'm heavily optimising partly just for practice/curiosity/the sake of it (it's an esolang interpreter, people hyperoptimise those for brainfuck…) < 1543963146 934298 :AnotherTest!~turingcom@59-100-168-134.cust.static-ipl.aapt.com.au QUIT :Ping timeout: 272 seconds < 1543963147 847424 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :no wait < 1543963151 244940 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :that's not how it works < 1543963224 345716 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :first you find a 64-way dispatch for the right slot with 8 cache entries from the 6 middle bits of the address, and THEN when the address arrives from the page table, only then can you compare the upper lots of address bits to the eight slots and do the eight-bit dispatch < 1543963228 991689 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :sorry < 1543963233 591420 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :that sounds even harder < 1543963256 394206 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :that's why it's hard to make the latency low, since the page table cache also has a latency < 1543963271 217274 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :memory latency is a huge problem for today's computers < 1543963388 415806 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I think the big problem is that until we design an entirely new architecture where we can be sure that no software depends on that pages are allowed to be 4k sized, we can't have an L1 cache larger than 32K (4K times eight). we've had CPUs with 32K L1 data cache and 32K L1 code cache for almost a decade, even though the operating systems mostly want to use 8K pages, < 1543963413 358641 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and we can't fix this while we want x86 compatibility. < 1543963436 575820 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it's one of these stupid historical things. 4k pages made sense back in 386 when computers had a few megabytes of memory. < 1543963449 969340 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :sometimes just one or two megabytes < 1543963468 231055 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the issue isn't really so much the size of the pages, as the minimum granularity of the page table < 1543963478 990156 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and larger L1 caches would help a lot > 1543963479 605264 PRIVMSG #esoteric :14[[07Doreq14]]4 M10 02https://esolangs.org/w/index.php?diff=58591&oldid=58377 5* 03Unitan 5* (+35) 10 < 1543963494 320845 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: what do you mean by the granularity? the cache line size? I think that's fine being 64 bytes as is. < 1543963499 9190 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you said "the pages are 512 bytes but you can only map them in units of megabytes" people would be fine with that < 1543963505 621528 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: minimum size/alignment of a page map < 1543963529 12042 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: if you can only map them in units of megabytes, then what would the 512 byte mean? in what sense would it be a page? < 1543963600 77024 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :presumably it'd be used for things like bounds checks < 1543963620 989166 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: hmm, so you'd have a size entry in each page? why's that useful? < 1543963632 542005 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I mean, it could be done, but I don't see the point < 1543963670 89544 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, what's the purpose of a page? < 1543963689 182614 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sometimes it's for memory allocation purposes, sometimes it's to get useful side effects from the page faults < 1543963698 810628 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could divorce the two, I think < 1543963719 431413 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: for a cpu page, which is what we're talking about here, it's mapping from virtual memory address space (of a process) to "physical" memory address space in a way that the cpu dispatches the mapping automatically at every ordinary memory access < 1543963785 739791 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :"physical" address ideally means what's sent to the main memory, but it could be different if there's virtualization or legacy 32 bit large memory shenanigans involved < 1543963830 922965 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, and I don't see why virtual→physical mapping would need a small granularity nowadays unless you're intentionally overlapping pages in weird ways < 1543963893 6984 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: anyway, if you add a size field to a page, and you set it to less than maximum size, then you're probably wasting the rest of the physical page, because it's unlikely that you'll quickly find another partial page that you can allocate in the same place that has just the right page size alignment < 1543963943 317927 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: OK, so what about a setup that works like this: you can set up virtual→physical maps which have a large minimum size and alignment, but you can "mask" parts of a virtual page so that they pagefault when accessed < 1543963951 440898 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rather than going to the physical page behind < 1543963957 954676 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it could perhaps be useful for catching some stack overflows < 1543963977 143183 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then you can effectively split a physical page between multiple virtual pages as long as the low bits in the virtual addresses are all distinct from each otehr < 1543963980 756965 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :but I don't think that's likely useful < 1543963997 930790 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it would just make so that we have to automatically extend the stack more often than once every few pages < 1543964034 167243 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: make part of a page masked to unreadable? perhaps, but I don't really think it's worth the cost. < 1543964072 489966 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: well, the point is you have to pay this cost anyway when you have small pages < 1543964078 736763 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so this is saving part of the cost < 1543964084 822732 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: I mean, then you'll need extra bits in the page table cache, which is something that has to be really close to the L1 cache and core on the cpu die for latency < 1543964095 141841 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and it's definitely useful to be able to mask, say, the code section and data section of an executable map differently < 1543964103 840587 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, hmm < 1543964107 302179 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I just had an idea < 1543964124 77166 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: not really. if you actually use smaller pages, rather than just allow smaller pages, then you pay the page table cost < 1543964163 952147 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :make it so that the high bits of a pointer specify what sort of accesses can be used via it; then instead of having permissions specified separately in the page table, they're specified indirectly by what virtual address you mapped the physical page to < 1543964169 728264 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: but currently, the cpu allows 4k pages, but most pages are actually larger, megabyte sized (we don't have 8K or 16K pages on x86_64 I think, but we could in the future), which is better because they take up less space in the page table cache < 1543964179 520778 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :well, not yet, but OSes are getting better with large pages < 1543964190 526103 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :eventually we will be using mostly megabyte-sized pages on x86_64 < 1543964206 553502 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and then you don't pay for the cost of the small pages in the page table cache, but only in the L1 < 1543964252 454617 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and once you require larger pages, with no mask bits, you have a page table cache that is about as efficient as currently, only slightly more because it doesn't handle small pages at all, and an L1 cache that can finally break the 32 kilobyte barrier < 1543964288 640865 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it's still tricky, you can't just increase the L1 cache to as large as you want, because that also increases the latency of that cache < 1543964364 359386 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :you might even end up with an L1 cache and an L1.5 cache, the L1.5 cache being slower than the L1 cache, but still works like the current L1 cache in that it can tell which group of 8 elements to use before the page table cache tells the address < 1543964414 474077 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :you might even drop the L2 cache, and have only an L1 cache, and L1.5 cache, and what's currently called an L3 cache < 1543964420 553803 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :though that's not likely < 1543964431 681534 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I dunno really < 1543964437 701375 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :at this point I just don't have the hardware competence < 1543964440 391786 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I can't predict < 1543964560 245110 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think the future of hardware is mostly moving towards trying to make the memory structure less general so that it can be faster in special cases < 1543964584 497456 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for example, GPUs typically use batch memory transfer mechanisms and suspend threads while waiting for the memory values to arrive < 1543964601 95851 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and NUMA allows different CPU cores to have different RAM < 1543964656 160961 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I'm a software guy who wants to optimize stuff on existing or near future consumer PC cpus, and only trying to understand cpus and compilers from that direction < 1543964732 341308 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: sure, the point of NUMA is that if each half of the cpu is accessing the RAM that's close to him, then the two halves can do memory transfer faster, and possibly with slihghtly lower latency too < 1543964752 585581 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1543964810 184328 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :this is useful if you have processes that are really well parallelizable to twofolds, as in, two parts are very independent in what memory they use, which is common, then you get higher memory performance with cheaper hardware < 1543964828 32149 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and it's common to have tasks that partition to two easily < 1543964873 287458 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I've used a 2-way numa server to compress several videos in parallel, the bulk of each video compression runs on one core < 1543964888 41115 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :one cpu core that is, with some gpu magic involved too < 1543964940 783124 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and the raw video is read to the half of the main RAM that compresses that video, and then the intermediate storage used for the compression is in that half too < 1543964961 890955 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :well, ideally < 1543964971 990613 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :I sort of have to trust the OS to do the Sane Thing in the common case < 1543965093 743696 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :compressing half of several videos still takes too much memory that it probably overflows an L3 cache < 1543965123 35921 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :CPU → GPU memory transfers are really really slow (the other direction is IIRC even slower, but less useful) < 1543965250 620929 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :ais523: sure, but for video compression it's still worth, because a part of the video compression can be really sped up by a GPU < 1543965266 145306 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :assuming you have a modern GPU of course < 1543965297 621389 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :it's the kind of tasks GPUs are optimized for < 1543965394 785540 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :indeed < 1543965551 453427 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :and I think if you do both the finding the nearby similar square in previous frames thing on the GPU and the discrete cosine/wavelet/etc transform on the GPU too, then you can keep all the data in the deeper parts of the GPU between those two < 1543965621 800001 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :so ideally you only transfer each frame to GPU only once and do all the tasks there, then transfer the result back to CPU which does further processing on it and writes the file < 1543965665 114057 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :there's some other operations besides those two, like possibly partly decoding the frames from the input format if it's already compressed, subtraction, color space transform, etc < 1543965708 199142 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :or even resizing to lower resolution or other operations done at the same time as the encoding < 1543965727 979115 :b_jonas!~x@catv-176-63-24-247.catv.broadband.hu PRIVMSG #esoteric :or, heck, deinterlacing and resizing to lower resolution < 1543966829 632465 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Read error: Connection reset by peer < 1543967682 845127 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 250 seconds < 1543967784 320495 :Lord_of_Life!~Lord@46.217.126.230 JOIN :#esoteric < 1543967784 560811 :Lord_of_Life!~Lord@46.217.126.230 QUIT :Changing host < 1543967784 560863 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1543967958 740910 :sleepnap!~thomas@2603:3015:260e:1900:8319:87ab:f00:d5de QUIT :Quit: Leaving.