< 1631492556 943140 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 265 seconds < 1631494217 780223 :normsaa!~normsaa@101.175.64.73 QUIT :Quit: Client closed > 1631494224 425740 PRIVMSG #esolangs :14[[07User talk:Fmbalbuena14]]4 M10 02https://esolangs.org/w/index.php?diff=88035&oldid=87892 5* 03Fmbalbuena 5* (-28) 10 < 1631495181 457059 :delta23!~delta23@user/delta23 QUIT :Quit: Leaving < 1631497408 701268 :imode!~imode@user/imode PRIVMSG #esolangs :are there any data structures that are like a trie but aim for compressing really wide trees vs. very deep ones. < 1631497549 673493 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :I don't know of any. < 1631497609 12183 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Isn't one of the lemmas leading to Huffman's encoding basically a proof that trie alphabet size doesn't matter asymptotically? (So that the alphabet size should be tuned, as in B-trees.) < 1631497866 807271 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :I don't know what those lemmas are, but I can see how it might make sense with such a question < 1631497930 35280 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :I only dimly remember. Something about how alphabet size ends up in the base of a logarithm, which is then washed away with a big-O. < 1631497938 202270 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I have a tree question. < 1631497957 978007 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :What sort of data structure should you use for an ordered key-value map that doesn't need to be modified? < 1631498001 381745 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Insertion-ordered or ordered by key comparison? Or IOW custom traversal order? < 1631498004 739760 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :B-trees seem like a natural answer -- maybe B-trees with nodes biased toward completely full if possible, rather than up to half-empty -- but is there something better? < 1631498012 382471 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I mean ordered by key comparison. < 1631498072 86917 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :B-trees/HAMTs are where I would start research. < 1631498098 577010 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Isn't HAMT unordered, since it's based on hashing? < 1631498260 948056 :imode!~imode@user/imode PRIVMSG #esolangs :Corbin: I should be more specific: I'm compressing lists of string rewrite rules by throwing them in a trie, only to realize that the actual trie will be very wide. my intent is building a format for these tries to be loaded and read (no modification after the fact). < 1631498274 631213 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Speaking of hash tables, how about this idea for hash tables without linear-time resize behavior: < 1631498287 189475 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :You reserve the maximum amount of addres space up front, but only use a little bit of it at first. < 1631498313 193567 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :To double the hash table, you double the amount of committed memory, but still keep entries where they are. < 1631498332 459364 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Then you incrementally start moving entries over to the "right" spot in the new region as you do more operations. < 1631498363 668225 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Before that's done, lookups that land in the new region have to check the old region too. < 1631498370 38435 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Do people do that sort of thing? < 1631498374 500682 :imode!~imode@user/imode PRIVMSG #esolangs :I could use huffman encoding, but because the interpreters that deal with these rules need to have a common symbol table to "latch" on to to do things like I/O, it won't be easy, as the reserved symbols could change their encoding relative to how they're used in the rule set. < 1631498381 947284 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :imode: You could steal a technique from the ordered-by-default doubly-indirect hashtables used in Python and a few other Smalltalk relatives. Each rewrite rule probably only uses a small number of tokens in total, right? It's only the entire dictionary that's big. < 1631498406 51106 :imode!~imode@user/imode PRIVMSG #esolangs :https://slack-files.com/T0191PWV41E-F02EC4E66P6-aceccd9554 < 1631498426 325562 :imode!~imode@user/imode PRIVMSG #esolangs :here's a compiled trie from a ruleset that deals with stacks and unary math. < 1631498438 626755 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Oh, all I needed to do was thinking of the word "incremental", and look up hash table incremental resizing. < 1631498439 64308 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :So you could put the dictionary into a single global array and also put indices from that global array into a rule-specific local array. Then compress the trie relative to the local array instead of the global array. < 1631498505 988661 :imode!~imode@user/imode PRIVMSG #esolangs :not sure I follow, but another way to approach it would be to simply supply auto-generated mappings for each of the reserved symbols on every compilation. < 1631498508 850976 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :I'm not explaining it well; here's a better explanation: https://www.pypy.org/posts/2015/01/faster-more-memory-efficient-and-more-4096950404745375390.html < 1631498629 914349 :imode!~imode@user/imode PRIVMSG #esolangs :I've got to step away for a bit, but were you the one that I handed the 500MiB dot file containing a mandlebrot renderer in string rewriting rules transpiled from BF? < 1631498672 396974 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :No, although (1) that sounds *hilarious* and (2) I definitely have generated DOT files around that size. < 1631501409 612211 :imode!~imode@user/imode PRIVMSG #esolangs :back. yeah it's uh, ugly af. < 1631501567 275711 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :With what I have, I might need to sort a linked list (although there might be another way). < 1631502000 459581 :Taneb!~Taneb@runciman.hacksoc.org QUIT :Quit: I seem to have stopped. < 1631502067 235186 :Taneb!~Taneb@runciman.hacksoc.org JOIN #esolangs Taneb :Nathan van Doorn < 1631502067 825707 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com QUIT :Ping timeout: 252 seconds < 1631502620 405705 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com JOIN #esolangs Cale :realname < 1631505963 866336 :mla!~mla@162.253.176.229 QUIT :*.net *.split < 1631505964 407783 :dnm!sid401311@id-401311.lymington.irccloud.com QUIT :*.net *.split < 1631505965 170194 :Soni!~quassel@autistic.space QUIT :*.net *.split < 1631505965 238204 :ski!~ski@remote12.chalmers.se QUIT :*.net *.split < 1631505972 986388 :ski!~ski@remote12.chalmers.se JOIN #esolangs * :Stefan Ljungstrand < 1631505996 561892 :Soni!~quassel@autistic.space JOIN #esolangs SoniEx2 :♾️No, that is not a cloak/vhost. < 1631506013 58268 :dnm!sid401311@2a03:5180:f:2::6:1f9f JOIN #esolangs * :dnm < 1631506244 955066 :ski!~ski@remote12.chalmers.se QUIT :Ping timeout: 265 seconds < 1631506816 380299 :esolangs!~esolangs@techne.zem.fi JOIN #esolangs esolangs :esolangs.org < 1631506816 903839 :fizzie!irc@selene.zem.fi JOIN #esolangs fizzie :Heikki Kallasjoki < 1631506818 804419 :ChanServ!ChanServ@services.libera.chat MODE #esolangs +v :esolangs < 1631506859 287844 :Deewiant!~deewiant@2001:470:69fc:105::2fd3 JOIN #esolangs Deewiant :@deewiant:maon.fi > 1631507283 970209 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Aidenbc 5* 10New user account > 1631507501 788959 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=88036&oldid=88006 5* 03Aidenbc 5* (+191) 10/* Introductions */ < 1631507518 575068 :jryans!~jryans@2001:470:69fc:105::1d JOIN #esolangs jryans :@jryans:matrix.org < 1631508650 647965 :Trieste!T@user/pilgrim QUIT :Ping timeout: 260 seconds < 1631509813 343799 :sprock!~sprock@user/sprock JOIN #esolangs sprock :Maeve Sproule < 1631511640 672637 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631511712 831003 :hanif!~hanif@gateway/tor-sasl/hanif PRIVMSG #esolangs : What sort of esolang is this? https://cs.nyu.edu/pipermail/fom/2021-September/022861.html => cool thanks for sharing < 1631512616 451711 :hanif!~hanif@gateway/tor-sasl/hanif PRIVMSG #esolangs :wow martin davis is the moderator for the mailing list < 1631513832 626403 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds > 1631513924 971384 PRIVMSG #esolangs :14[[07SUB14]]4 N10 02https://esolangs.org/w/index.php?oldid=88037 5* 03Hakerh400 5* (+5521) 10+[[SUB]] > 1631513928 667871 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=88038&oldid=87951 5* 03Hakerh400 5* (+10) 10+[[SUB]] > 1631513944 475167 PRIVMSG #esolangs :14[[07User:Hakerh40014]]4 10 02https://esolangs.org/w/index.php?diff=88039&oldid=87722 5* 03Hakerh400 5* (+10) 10+[[SUB]] > 1631514412 989506 PRIVMSG #esolangs :14[[07SUB14]]4 10 02https://esolangs.org/w/index.php?diff=88040&oldid=88037 5* 03Hakerh400 5* (+16) 10 > 1631514492 999369 PRIVMSG #esolangs :14[[07SUB14]]4 10 02https://esolangs.org/w/index.php?diff=88041&oldid=88040 5* 03Hakerh400 5* (+2) 10 < 1631515470 626691 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631517508 842059 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1631517924 147721 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User < 1631518482 999712 :immibis!~hexchat@62.156.144.218 QUIT :Ping timeout: 265 seconds < 1631519268 519625 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :shachaf: for an ordered key-value map? a sorted array generally, if it fits within the RAM < 1631519422 804815 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :b_jonas: Surely something like a B-tree is better than a sorted array. < 1631519437 370320 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Binary search on a sorted array makes pretty bad use of cache. < 1631519458 65075 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :shachaf: it isn't really because you're always starting to compare with the same elements, so those stay in the cache < 1631519474 770137 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :just make sure it's not power of two sized so you don't get stupid cache collisions < 1631519488 650962 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :nor anything close to power of two < 1631519570 330533 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :perhaps pad it out to fibonacci sized by padding with infinities on an end or something < 1631519584 48172 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :do you have variable key sizes or fixed? < 1631519634 725774 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :hmm no, probably not fibonacci < 1631519957 878287 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :-- do you have a clue in DB indexing? -- yeah, I've implemented indexing -- what?! -- ... < 1631520070 212916 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :-- I saw "DevOps" in your CV, what devops tools do you use? -- I use no tools, devops is a methodology... -- what?! -- ... < 1631520081 955898 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :job interviews be like < 1631520128 990136 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :-- what hobbies do you have? how do you have fun? -- I made an esolang -- what?! < 1631520189 144464 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :lol < 1631520371 653333 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :sorry, I'll need to think about what size you should use for cache-friendliness (still it the table fits in RAM) < 1631520378 638260 :hendursa1!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat < 1631520381 562915 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :somehow I never thought about that, even though it is an important enough basic question < 1631520511 714647 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so thanks for the question actually < 1631520522 433224 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :(RAM vs disk matters here because their caching differ) < 1631520540 639349 :hendursaga!~weechat@user/hendursaga QUIT :Ping timeout: 276 seconds < 1631521149 826406 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :ACTION has already borrowed money from two people to survive in this stupid world that can't give a job < 1631521239 112831 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :b_jonas: But you're wasting a whole cache line on one element. < 1631521247 789858 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Rather than using the entire root of the B-tree. < 1631523465 626419 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631523569 937650 :ais523!~ais523@213.205.242.163 JOIN #esolangs ais523 :(this is obviously not my real name) < 1631523720 177578 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs : What sort of esolang is this? https://cs.nyu.edu/pipermail/fom/2021-September/022861.html ← that's almost literally Thue (the version which is nondeterministic in the mathematical/declarative sense rather than the randomness sense), the only difference is in the startup state and a different model for halting < 1631523779 442999 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :actually, if you think of the operands of R being the other way round, there isn't even a difference in the startup state, "is this string in GEN(R)" becomes equivalent to "can this Thue program reach the empty string and halt?" < 1631523786 360695 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :(so the "reach the empty string and") is the difference < 1631523797 661826 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :oh, also it's limited to an alphabet of {0,1} but this doesn't matter for Thue at all < 1631523831 359807 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs : I do like sudo's "This incident has been reported to the authorities" message. ← I actually received one of those reports once (after typoing my password in sudo one too many times), I was shocked it actually went somewhere < 1631523857 164946 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :apparently it just sends local email to root, so it depends on whether you have an email stack that a) understands local email and b) has root's mailbox linked up to something < 1631523987 577607 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :b_jonas: the funny thing about the power-of-two sizes is that they're sometimes the worst size but sometimes the best size, depending on the exact algorithm you're using < 1631524050 442412 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :there are two basic problems, false aliasing (some parts of modern processors speculatively assume that if the bottom few bits of addresses match they'll be the same as each other, and need to rewind if htey turn out not to be) < 1631524077 862120 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :and the fact that modern caches are effectively lossy hash tables and if you find collisions in the hash function, they'll end up losing a lot more data than they should < 1631524101 901884 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :that said, I think the hash functions powering the caches are generally non-public, and more complex than "bottom N bits" < 1631524106 907888 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs * :[https://web.libera.chat] wob_jonas < 1631524129 886967 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :shachaf: sorry, let me try to give a better answer to this\ < 1631524218 527120 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so basically this question is complicated because the ugly real world comes in, and the full answer is probably more or less to read the entire future third edition of TAOCP third volume. < 1631524247 505153 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :the main culprit for false aliasing is read-after-write, if you write 0x5000000 and then read 0x5001000 some processors will delay the read until after the write because it cautiously assumes that they might overlap < 1631524255 139166 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wp taocp < 1631524257 404421 :velik!~velik@nakilon.pro PRIVMSG #esolangs : The Art of Computer Programming -- series of tomes by Donald Knuth https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming < 1631524295 730239 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :first, in the unrealistic case when you have fixed size keys that are so opaque you can only compare them, yet they are fast to compare, then here's what you want\ < 1631524318 547796 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :so, power-of-two sizes are good if you're reading one element and then writing the corresponding element, because that gives you a guaranteed write-after-read (which doesn't stall) and reduces the chance of a read-after-write randomly happenign with some other pair of addresses < 1631524327 157151 :Robdgreat_!~rob@wurst.1606inc.com NICK :Robdgreat < 1631524335 910574 :Robdgreat!~rob@wurst.1606inc.com CHGHOST ~rob :user/robdgreat < 1631524402 752332 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :make a sorted vector, pad it to size that's a power of r minus one where each cache line can fit r-1 keys, do the search with r-way comparisons so you effectively traverse a complete r-ary tree, but without pointers because the fixed size keys let you elide all the pointers. < 1631524431 672416 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you can permute the cache lines, and sometimes you have to to avoid a really bad L1 cache pattern, but most arrangements are good enough: < 1631524460 183200 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :in all usual programming languages code is 1-dimentional; in many esolangs it's 2 or more dimensional; but all those "lines of code" are parallel; there should be a language with no parallel lines < 1631524471 313564 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :eg. the case that's really bad is a binary tree (one key per cache line) that's exactly power of two plus one size; < 1631524493 108255 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :a permutation that's probably good enough is to just place each level of the tree contiguously and one after another < 1631524502 727994 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :some code notation that would have the "code" either lined up randomly or along the curves < 1631524513 298705 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :or in compound ways < 1631524550 183119 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if you don't want to just find the first key less than your query key, then can use any permutation; if you want to access some subsequent nodes after each query then you want to permute as little as possible < 1631524581 307113 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :for a binary tree (one key per node) I think you can get away with a sorted vector that's size 2**n/63, and I know that sounds sillyi < 1631524605 89376 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :now the problem is that the case when your keys are fixed size and opaque yet you can do fast ordered comparison is unrealistic < 1631524665 586352 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :because if you can do fast ordered comparisons and want an ordered structure, then you may also be able to do arithmetic on the key and do the sort of accelerated search where if your query starts with Z then you go to the last 1/26 of the book < 1631524687 81858 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but the good news is, in practice unless your distribution is even, I don't think this helps too much, and just an r-ary tree works well enoguh > 1631524697 492715 PRIVMSG #esolangs :14[[07Talk:Mogus14]]4 10 02https://esolangs.org/w/index.php?diff=88042&oldid=87976 5* 03ArthroStar11 5* (+247) 10 < 1631524726 93108 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :by the way there's an unlikely exception from this, which is when you have prior information about the distribution of your queries and they're VERY skewed, like the query is always the same fixed word, and in that case you can do better, but this is rare\ < 1631524761 937746 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if your comparisons are very slow, then you want a binary tree, or fibonacci tree if you can only do 2-way comparisons, because you're dominated by the comparisons and the memory access doesn't matter, < 1631524784 715196 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but you may have a comparison speed in between the two which is one of the ugly real world parts < 1631524791 345570 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :now all this so far was about fixed size keys < 1631524806 714112 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in reality if you need an ordered structure, you are more likely to have variable sized keys < 1631524883 645346 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if your key sizes are variable, then you still want a complete tree with each node branching one plus as many ways as many keys you can fit to the cache line (or page on a disk), but this number of branches can differ in each node < 1631524899 241083 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this is similar to a b-tree, but you may be able to do somewhat better,\ < 1631524916 454417 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :because if you don't have to modify your structure, then you may be able to encode your pointers somewhat more efficiently < 1631524972 829255 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :as in, if each level of the tree is stored in a sorted order, then the first few levels can already tell you the first bits of the pointers on each of the subsequent levels, so you needn't encode those bits in all the later nodes < 1631525010 592506 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this ends up in an ugly tradeoff between memory access speed versus computation speed, so it's hard to tell how much you want to compress those addresses and how exactly\ < 1631525035 520868 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :typical real world optimization problem where you won't get a once and for all simple theoretical solutino < 1631525155 218066 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :also an ugly part is, even in the fixed size, that if your tree is large enough but still within memory, then you may want nodes larger than a cache line, beacuse you may be able to read from memory faster if it's adjacent cache lines, < 1631525174 494598 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but how exactly the caches and memory work in this respect I admit I don't understand, so I can't tell what you actually want to do < 1631525340 281458 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so sadly this is the kind of hard problem where the final TAOCP edition will help us a lot\ < 1631525377 626588 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631525523 897599 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and it's hecking far in the future because it's volume 3 < 1631525609 376175 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I got the sudo message (in local email inbox to root, on the workstation that doesn't normally handle emails) lots of times < 1631525621 918099 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and yes, that's the default < 1631525636 899940 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :if humanity make an elixir of longer life they should give it to Knuth < 1631525656 633768 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"the funny thing about the power-of-two sizes is that they're sometimes the worst size but sometimes the best size, depending on the exact algorithm you're using" => yeah. I did a lot of bitmap image processes, where my rule of thumb is to make rows a size in bytes that is 64 modulo 128 < 1631525688 627538 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631525701 604930 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: the hash function of the L1 cache is the bottom 12 bits (of the address of bytes) by necessity on x86, < 1631525713 373843 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wa Knuth age < 1631525714 589582 :velik!~velik@nakilon.pro PRIVMSG #esolangs : Result: 83 years 8 months 3 days < 1631525716 687601 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and there's always 8 cache lines per fixed bottom of 12 bits < 1631525756 962494 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this is by necessity because the L1 cache has to be so fast (within very few clock cycles) that it needs to select the cache line before the linear address translated by the cache table to physical address is known, < 1631525806 448413 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and x86 can have 2**12 byte sized pages, with no architectural way that all pages are larger, so you can't use more than 12 bits of the address; < 1631525842 415845 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the same page can be mapped to multiple linear addresses (whether within the same process or different processes) and often will be, so you can't just cache by linear address and roll back everything if that goes wrong < 1631525890 473660 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :all this applies ONLY to the L1D and L1C caches, of which there's one per CPU core, no other cache I think < 1631525896 650092 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631525944 712072 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you may be right that the hashing methods of some of the caches aren't known, but because those caches are slower, they can also do more elaborate things and so it's harder to accidentally stumble into a bad pattern just by choosing the wrong address < 1631526171 770766 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :by the way this means that the L1D cache is always 32k size in any modern x86 cpu < 1631526198 244421 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :while the size of the L2 cache and L3 cache varies widely depending on how much you pay < 1631526239 988800 :int-e!~noone@int-e.eu PRIVMSG #esolangs :haha. "should not be depicted with a zipper mouth" < 1631526243 668243 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`unidecode 😬 < 1631526247 260938 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​[U+1F62C GRIMACING FACE] < 1631526270 874245 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(character details for that one... can HackEso display character details?) < 1631526354 20850 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: https://unicode.scarfboy.com/?s=U%2b1F62C , which parts do you want? they won't all fit into an IRC message < 1631526406 164842 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :plus you also need to follow the "PDF on unicode.org" link, here to http://www.unicode.org/charts/PDF/U1F600.pdf < 1631526457 965207 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :because that PDF is what has the comments like that zipper mouth thing < 1631526467 364599 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and the see alsos to other characters, which is often useful < 1631526482 297082 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wob_jonas: the "comments", https://www.fileformat.info/info/unicode/char/1f62c/index.htm < 1631526499 284013 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(the former doesn't work for me, says the code point is unknown?) < 1631526506 395095 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(maybe some javascript requirement) < 1631526557 75189 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yaeh, it doesn't work for some reason < 1631526579 637861 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it was helpful enough to provide further links < 1631526600 777861 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I think the maintainer did some changes to the page and broke some things temporarily < 1631526608 84731 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :IIRC there was a message to that effect < 1631526623 613665 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I've always been annoyed by the fact that UnicodeData.txt doesn't include those comments. But they're in NamesList.txt of the UCD. < 1631526628 925507 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah, "Notice: I'll be updating the information in the next weeks. It'll be broken occasionally." that's been there for months but you know how that goes < 1631526632 862941 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you get what you pay for < 1631526657 275278 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway, I found this particular comment funny. So specific... < 1631526675 638500 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah < 1631526707 847188 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I generally don't care about all the ininite smiley faces and other emoticons added < 1631526731 277849 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the only smiley faces that matter are the ASCII ones like :-) and the two in cp437 < 1631526860 500359 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wob_jonas: I'm not studying the smileys; sometimes I encounter a smiley on Twitter that I don't understand and care enough to look it up. < 1631526916 13239 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Oh and in the meantime I'm waiting for Unicode modifiers to become accidentally TC. ;) < 1631526928 748990 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :.oO("hmm, is that smiley supposed to be a zipper mouth? let me look it up in the unicode database.") < 1631526987 802812 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"Unicode modifiers" => I think the bidirectional rendering and line breaking algorithm might get TC first < 1631526994 311348 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I imagine that it works as advice to font designers... who really have to go through unicode points one by one < 1631526994 350521 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs : by the way this means that the L1D cache is always 32k size in any modern x86 cpu ← there are some that advertise "64k per core", I wonder if the hyperthreads have separate L1 caches? < 1631527048 600530 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: are those x86 cpus, and are you sure it's not the L2 cache of a cheap cpu? I'd like to see this < 1631527081 164177 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :do you know at least a brand? < 1631527094 550116 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :eg. Intel or AMD < 1631527122 158882 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: that strikes me as silly? except maybe as a separation feature, where you (optionally) tag entries by hyperthread in a way that they map to different cache sets < 1631527140 655907 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: AMD Ryzen 9: https://www.amd.com/en/products/cpu/amd-ryzen-9-3900x < 1631527149 238381 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :thanks < 1631527159 962812 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :64KiB of L1 cache per core, but 32KiB per hyperthread < 1631527172 110121 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :oh, it's combining L1C and L1D < 1631527174 162309 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :sorry for the false alarm < 1631527183 85868 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :that's sneaky, adding the two together < 1631527192 261394 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah, that's evil < 1631527194 951841 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :marketing < 1631527198 702311 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: I mean, I don't know... it's just so opposite to the core idea behind hyperthreads as I understand it, which is to have a single core but fill its idle time by keeping track of two PCs and register sets. < 1631527226 914873 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I mean sure, both L1D and L1C are very important, but they're separate caches, and they're separate partly because each can only be 32k so this way you get 32k each instead of 32k total < 1631527231 734814 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :int-e: it'd be plausible to use "hyperthread on which we accessed this" as an extra bit of address, I guess < 1631527262 438269 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: in particular you'd want to be able to use the full cache when hyperthreads are disabled... < 1631527269 543414 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :yes < 1631527289 754167 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I don't think you can do that in L1. you could in theory have two separate L1 caches, but that gets very close to not being hyperthreading but two separate cores, so it's sort of poinless, takes away the point of hyperthreading < 1631527349 980300 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :or, cynically speaking, the people who want high performance for computation that cares about L1 cache, such as those AI researchers, they will just turn off hyperthreading (or not turn off but the OS guesses well enough to put their 12 processes to 12 separate cores) and then the double L1 caches would be a waste < 1631527401 133712 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I don't want to say that hyperthreading is always useless, because sometimes people run windows and a browser and have a ton of processes scheduling around each other in wild chaos and the whole thing together is bound on main memory or L3 cache, < 1631527410 109331 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so in that case hyperthreading can help to reduce context switch overhead, < 1631527434 3431 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wob_jonas: yeah it would only make sense to me in a isolated container setting (VPS), assuming that /some/ of the hyperthreading benefit survives the effective reduction in cache sizes < 1631527436 733321 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but for the cases when I actually care for performance, on my computer, not on the boss's laptop when it's running a virus scan, I think hyperthreading is a waste < 1631527491 355108 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it would mitigate L1 cache based side channels (which probably have a nice name but I don't currently remember) < 1631527501 88189 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: um, if you have an isolated container, don't you want to not run it on the same core hyperthreaded, because on the same thread timing attacks can cause security bugs? or what kind of isolated containers do you want? < 1631527516 779699 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :s/AI researchers/casual users of trendy specialised machine learning tools < 1631527522 338665 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: ok, but is that enough? there's still all sorts of possible timing attacks even if the L1 cache is separate < 1631527562 592200 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I'm imagining "small" VPSs with 1 virtual core. If you offer hyperthreading then sure, you can give the whole core to the VPS. < 1631527594 761599 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wob_jonas: I don't know whether it's enough. Probably not... some of the more interesting attacks actually work with the shared branch prediction data. < 1631527595 667190 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: no, I mean separating the L1 cache isn't enough to isolate the two processes enough for security purposes I think < 1631527710 100171 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And in the end, the scheduling decisions for individual instructions is so delicately intertwined in hyperthreading... there will be remaining side channels where you can see what kind of stuff the other thread is doing. < 1631527726 115369 :int-e!~noone@int-e.eu PRIVMSG #esolangs :So yeah, it's probably a losing fight. < 1631527742 201193 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Up until the point where you have two separate cores ;) < 1631527774 164053 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but maybe some VPS providers just don't care about the security of their clients? < 1631527783 843993 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I don't know the market there < 1631527784 706103 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Oh that's for sure. < 1631527826 815694 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Remember https://www.cloudatcost.com/ ? < 1631527895 250946 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"virtual crypto miners" wait what? < 1631527908 84921 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Yeah they found a way to become even more scammy < 1631527928 426402 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I don't remember because I haven't researched the VPS market much < 1631527931 833281 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"we're mining crypto but you can help us finance the hardware" < 1631527948 769806 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so far I don't even have a hosted server (virtual or not) that I pay for < 1631527987 344844 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I thought you might remember from the old days when HackEgo used to crash once every one to two weeks because the CaC VPS it was on was so great(ly unreliable). < 1631527991 169769 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I just have a computer at home behind a dynamic IP cable internet that often cuts out, and I'm vaguely wondering if it's even possbile to run a https server behind dynamic IP < 1631528017 37889 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh, is that the old hosting provider for the wiki? < 1631528024 813788 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Yeah < 1631528036 737741 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :wow < 1631528106 593580 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"virtual crypto miners" is impressive in the sense that it's hard to write a short webpage headline that dodgy. < 1631528143 599841 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the investment scam ads need more words than that to communicate their scammyness < 1631528148 872872 :int-e!~noone@int-e.eu PRIVMSG #esolangs :They evolved a bit. The good old $35/lifetime VPS offer is gone. Or was it $70 and permanently 50% off. I forgot :) < 1631528171 520813 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :meh, permanently 50% off is normal, people do that here too < 1631528182 750337 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :even for basically legitimate services < 1631528229 635884 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :I wonder why I have $ in RASEL < 1631528240 617719 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :if I can do just 0/- < 1631528241 457601 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esolangs :The old RASEL-dazzle < 1631528258 420703 :int-e!~noone@int-e.eu PRIVMSG #esolangs :0/- doesn't look like money < 1631528271 592281 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :um < 1631528274 393427 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :what is 0/- ? < 1631528279 583835 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :I can change / with $ to have lots of money < 1631528294 436117 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :wob_jonas division by zero gives zero < 1631528318 936548 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok < 1631528323 199865 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :or :-- < 1631528445 168855 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :really, the $ is almost not used actually < 1631528561 953906 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :only 4 times in brainfuck interpreter < 1631528614 642681 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :are there any built in or popular unix utility for char stats? < 1631528687 343865 :spruit11_!~quassel@2a02:a467:ccd6:1:bdee:99d8:9af:602f JOIN #esolangs * :anon < 1631528710 671679 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :https://dpaste.org/QmjQ/slim < 1631528786 639504 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :37 is \n < 1631528896 843053 :spruit11!~quassel@2a02:a467:ccd6:1:a09c:5ae1:45f8:7ffe QUIT :Ping timeout: 252 seconds < 1631528920 531905 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :(and fungot for comparison https://dpaste.org/ExRY/slim) < 1631528920 831245 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :nakilon: grab the fnord bus. not familiar though. -g is fine as long as people don't delete) < 1631528995 552640 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :oh and there are english comments in both files ( < 1631529060 193489 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :but still I suppose 1 with g are the most used instructions in fungot and 1 with \ are the most used in my program < 1631529060 619549 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :nakilon: a celebrity of some sort, a human readable spec, but there's an exact address for chead on that " visual_iterate ( chead=0x804c318) at mm_visual.c:13 < 1631529113 914931 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :on the subject of hyperthreading, I assumed that it started out as "let's run unrelated programs on alternating CPU cycles to halve the effective pipeline length, helping to hide our long pipelines" (that may be incorrect), but it's turned into "it's wasteful to have a fixed number of instruciton decoders, etc., let's split six decoders between two core-equivalents so that they can do four-and-two or five-and-one, rather than forcing them to have only < 1631529115 337692 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :three each" < 1631529183 868418 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: I'm trying to work out whether there's any actual distinction between a virtual cryptominer and a subscription service for buying bitcion < 1631529187 268088 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :* buying bitcoin < 1631529247 19494 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I thought it started like "the programmers can't write programs that use the cache efficiently, so the CPU is mostly waiting for memory (or L2 or L3) accesses. if we're memory-bound all the time then we don't need so much of everything else, run two threads together, running whichever thread can proceed because the data from memory arrived" < 1631529295 805848 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: it could be, sort of, except that the hyperthreads share the L2/L3/memory bottleneck < 1631529314 263518 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :so this is only useful in the rare case that the program is bottlenecked specifically on memory latency rather than memory throughput < 1631529323 450730 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm < 1631529332 832366 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :(this can happen, e.g. with linked lists, but throughput is much more likely to be a bottleneck) < 1631529337 948626 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you might have a point < 1631529355 551510 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so it's more about pipeline than memory, beacuse it doesn't help with memory? < 1631529364 194913 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :unless it's memory latency < 1631529364 921452 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm < 1631529434 644243 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: can hyperthreading also be because the programs use too many unncessary context switches, so you may want to run two *related* processes that are communicating and syncrhonizing in one thread? < 1631529448 539164 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :no, probably not, cpus are probably not optimized for the latest stupid fad of bad programmers < 1631529471 595824 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :at least the x86 ones aren't < 1631529480 509806 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: when working on this FizzBuzz, I've concluded that algorithms often care a lot about which threads are siblings < 1631529497 579808 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :so it's possible < 1631529535 847709 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :um ok... but your optimized FizzBuzz is also not what the cpus will be optimized for < 1631529542 556638 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :the FizzBuzz doesn't benefit much from the sibling relationship because it's bound on cache write speed and that's something that's shared between siblings < 1631529548 689560 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: well, it is, sort-of in reverse < 1631529555 594118 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's true that if you have a hyperthreading cpu then the programmer may care on where they bind the threads < 1631529559 512651 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :in that it's being optimized to try to fit the CPUs as accurately as possible < 1631529564 477530 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :same on a NUMA cpu < 1631529597 74924 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :if the CPUs had different performance characteristics it might well change the entire algorithm < 1631529627 299903 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yes, if you have 12 important threads on a 12*2 hyperthreading cpu then you want to run them on 12 separate cores < 1631529632 719915 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :the funny thing is, I'm not sure you even benefit much from multithreading if you're trying to write the fizzbuzzed output to memory < 1631529655 213204 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :because the bottleneck will be the memory write speed and I think you can go fast enough to saturate that with even one core < 1631529661 836145 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :so the only benefit from a second thread is to run your system calls on it < 1631529671 27698 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yeah, unless it's a NUMA machine, because you can do the computation fast enough that it's bound on memory speed < 1631529691 164575 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :oh, good point, NUMA probably means extra memory bandwidth because you can access it from multiple places < 1631529693 954317 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but if it's a NUMA machine then you'll have two threads, one per NUMA node < 1631529699 928590 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, that < 1631529724 573300 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wp numa cpu < 1631529725 734301 :velik!~velik@nakilon.pro PRIVMSG #esolangs : Non-Uniform Memory Access -- computer memory design used in multiprocessing https://en.wikipedia.org/wiki/Non-uniform_memory_access < 1631529727 453256 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that said, in the odd case of fizzbuzz, you also won't be harmed much by running as many threads as you have cores < 1631529728 611720 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :anyway, the mechanism for reading speed in the original CGCC question doesn't actually require the fizzbuzz to be written to memory, just to a memory address < 1631529748 417267 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :for writing to memory that is < 1631529751 780097 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :which is a huge distinction, because it lets you keep your fizzbuzz output in cache and just discard it when it gets written to /dev/null < 1631529756 994027 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yaeh < 1631529758 584506 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :so it never touches main memory < 1631529787 164581 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :this means running on as many CPUs as possible to give yourself as much L2 cache as possible to store the output in (I only realised this a few days ago) < 1631529790 896374 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :I feel like adding references at the bottom of the page, velik you are handy < 1631529802 773298 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :unless by "memory address" they mean a memory-bound IO device, like one that behaves like a really fast serial port that actually throws the data away < 1631529807 915110 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :implemented in hardware < 1631529817 504836 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: nah, it's defined in terms of system calls < 1631529831 97826 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :system calls? wow < 1631529835 496322 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :specifically, requiring it to be possible to read the data from a pipe (but not actually doing the read, it just gets piped to /dev/null) < 1631529865 500027 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :which means that you can vmsplice your own address space into the pipe and not actually copy the generated data at all < 1631529874 847970 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so you'd fill most of the L1 cache, except that the kernel uses to do the write, then call the write? < 1631529888 710571 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"copy the generated data" to /dev/null? < 1631529893 573510 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: right, although I'm currently planning to use the L2 cache for the purpose < 1631529903 916086 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok < 1631529921 409592 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :L1 might be doable, but then the system call overhead gets really large < 1631529940 730015 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :why do you need vmsplice if the speed is measured when the output handle is /dev/null ? doesn't writing to that elide the copy? < 1631529953 964899 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :also, my current algorithm uses most of L1 cache as it is for lookup tables; I could make those smaller but at the cost of using unaligned access < 1631529958 635455 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I mean I don't know, maybe the kernel doesn't optimize taht and it does copy before discarding < 1631529967 138817 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: so the command is (./fizzbuzz | pv > /dev/null) < 1631529973 726161 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :what is pv? < 1631529978 305969 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Do unaligned accesses actually matter much these days? < 1631529981 218613 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :pv is like cat with a progress bar < 1631529987 748035 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ah, you mean dd < 1631529997 788885 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :but in this configuration, it internally calls splice repeatedly, with stdin and stdout as arguments < 1631530021 297518 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :shachaf: not in normal configurations, but this one is sufficiently abnormal that I think they might < 1631530052 745479 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :shachaf: unaligned access matters if (a) it's across a cache line, or (b) you've optimized your program to an older CPU or at least for potentially running on an older CPU < 1631530053 12603 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :e.g. it wouldn't surprise me if an unaligned 32-byte read that crossed a cache line boundary would require twice the L1 read bandwidth < 1631530072 695728 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :and this doesn't matter in most cases, because most programs aren't bottlenecked on L1 read bandwidth < 1631530089 239854 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :but this one is, it bottlenecks L1 read, L1 write, and L2 write simultaneously < 1631530101 75826 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :shachaf: if you read an unaligned integer within a cache line it's as fast as aligned, but aligning everything is a good heuristic to avoid that < 1631530135 983537 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :the really horrible case is an unaligned access across a *page* boundary; cache line boundaries don't cost much nowadays, but they may be a little slower < 1631530153 463006 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Unless it also increases wasted cache space, in which case it might be less clear, I suppose. < 1631530166 950858 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Page boundaries are a bad case, sure. < 1631530179 301092 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But they're pretty uncommon, especially if you use huge pages. < 1631530206 792075 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :shachaf: also sometimes you *want* unaligned access, even across cache lines, eg. to memcpy with unaligned difference, and for that the guideline is that if you have a choice between unaligned reads and unaligned write, do aligned write and unaligned read < 1631530248 194012 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :wob_jonas: aligned write, unaligned read is usually better, but apparently not always < 1631530251 806780 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :processors are weird < 1631530264 817142 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :here too the unaligned only matters across cache lines, but reading unaligned is better than reading aligned and then shifting, and is also better than reading aligned and writing unaligned < 1631530274 836393 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yes, it's just a guideline < 1631530276 427144 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :I think someone benchmarked all the possibilities (including one where you do both reads and writes aligned and use double vector shifts to adjust) < 1631530305 932029 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :also the top element can be discarded with '? ' < 1631530320 793189 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :so there are three ways already, what are others? < 1631530392 289515 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: in bitmap image processing, we often have patterns similar to the Wolfram style cellular automaton, where the output is the same size as the input but depends on three adajcent input pixels. and in that case, aligned reads and shifts may be better. < 1631530396 920554 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :with aligned writes that is\ < 1631530402 865220 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :aligned reads and aligned writes and shifts < 1631530452 935658 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :though sometimes the bottleneck is something else and it doesn't matter what you do < 1631530474 258257 :ais523!~ais523@213.205.242.163 PRIVMSG #esolangs :well, that algorithm would naturally want unaligned reads at the bit level, but there's no way to express those < 1631530500 539099 :ais523!~ais523@213.205.242.163 QUIT :Quit: quit < 1631530521 961908 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"the really horrible case is an unaligned access across a *page* boundary" => especially if you want to write a strlen where reading one byte past the nul byte is undefined behavior if it crosses a page boundary < 1631530537 956202 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and yes, that's a bit different than what you are talking about < 1631530603 204413 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I would like a malloc-like API that takes four parameters instead of the usual two: size of allocated block, alignment, how many bytes must be readable before it, how many bytes must be readable after it. (you can have two variants of this, one where you know the paramters when you free and one where you don't) < 1631530616 505961 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :usually mallocs only provide two parameters, the size and the alignment < 1631530671 895872 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :unaligned reads at bit level? what algorithm? < 1631530893 904147 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh, you're talking about the cellular automaton? well, in the image processing our pixels are large that we don't need that, and even in the Wolfram case you can store the CA such that you don't need finer than byte granularity if you wish, by breaking your space (or large enough pages of it) to eight parts, storing each eighth in a specific bit of < 1631530894 393684 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the bytes, and putting the eight on top of each other and then manipulating them together. this only works if your neighborhood is small enough, like in Wolfram, not for larger data, but often if the bit level shifts cause a problem (they don't always do) you can avoid them < 1631530947 135059 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :though I'm not too confident in that < 1631531192 815974 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok no < 1631531205 219059 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the Wolfram CA is different in that you want to iterate your operation a lot of times < 1631531217 239470 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :unlike in the pixel bitmap case, where you want much fewer iterations < 1631531229 488242 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :so for the CA you don't want to rearrange the pixels < 1631531489 501140 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it was a bad analogy < 1631531761 343181 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv < 1631535239 990580 :dyeplexer!~dyeplexer@user/dyeplexer JOIN #esolangs dyeplexer :t b k ky jt h bc > 1631536656 526961 PRIVMSG #esolangs :14[[07Kolmogorov14]]4 M10 02https://esolangs.org/w/index.php?diff=88043&oldid=88024 5* 03Kaveh Yousefi 5* (+0) 10Added a linebreak to simulate a paragraph, removed a superfluous empty line, and amended an occurrence of ascii to its capitalized form. < 1631537420 934278 :pikhq!sid394595@user/pikhq QUIT : < 1631537436 139281 :pikhq!sid394595@user/pikhq JOIN #esolangs pikhq :Ada Worcester < 1631538901 774537 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631538932 340212 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631539194 320823 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631539211 340866 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631540179 754636 :aarchi!sid486183@id-486183.highgate.irccloud.com QUIT : < 1631540195 123365 :aarchi!sid486183@id-486183.uxbridge.irccloud.com JOIN #esolangs aarchi :aarchi < 1631540330 387399 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631540358 339470 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631542458 626806 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631542530 122957 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1631543062 343290 :src!~src@user/src JOIN #esolangs src :realname < 1631543630 643735 :faxlore!sid505520@highgate.irccloud.com QUIT : < 1631543646 149708 :faxlore!sid505520@id-505520.uxbridge.irccloud.com JOIN #esolangs faxlore :faxlore < 1631544107 340195 :sprock!~sprock@user/sprock QUIT :Ping timeout: 268 seconds < 1631544303 627379 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631544327 780281 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631544654 915801 :wob_jonas!~wob_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1631545532 331 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User < 1631545836 649551 :hanif_!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631545929 640663 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631546520 504006 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :it happens that in factorial example I put on wiki both $ are safely replaceable with -, because in both cases there is 0 on top < 1631549732 961609 :sprock!~sprock@user/sprock JOIN #esolangs sprock :Maeve Sproule < 1631550390 364378 :vyv!~vyv@76.68.6.254 JOIN #esolangs vyv :vyv verver < 1631550644 586898 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631551038 626384 :hanif_!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds > 1631551766 254584 PRIVMSG #esolangs :14[[07RASEL14]]4 10 02https://esolangs.org/w/index.php?diff=88044&oldid=87906 5* 03Nakilon 5* (-71) 10spec v2: deprecated '$' > 1631551896 451771 PRIVMSG #esolangs :14[[07Velik14]]4 M10 02https://esolangs.org/w/index.php?diff=88045&oldid=87985 5* 03Nakilon 5* (+38) 10note that it runs spec v1 < 1631552087 153745 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User < 1631552099 891719 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :s/on wiki/in README < 1631552265 310314 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :'$' has appeared to be in most cases replaceable with just '-' because it is usually used when if you leave the loop and you need to pop the nullified counter that was used there < 1631552394 655658 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I'm confused by matrices again. When a mathematician sees m_12, does that usually refer to row 1 column 2, or row 2 column 1? < 1631552410 815657 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Or does it refer to entry 12?! < 1631552437 258094 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Presumably the diagram at https://en.wikipedia.org/wiki/Matrix_(mathematics) can help. < 1631552484 949243 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :So DOMMatrix does it the other way around, because...? https://drafts.fxtf.org/geometry/#DOMMatrix < 1631552656 636105 :hanif_!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631552949 626630 :hanif_!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631552963 941538 :sprock!~sprock@user/sprock QUIT :Ping timeout: 265 seconds < 1631553095 755540 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631553377 560540 :sprock!~sprock@user/sprock JOIN #esolangs sprock :Maeve Sproule < 1631553968 627194 :hanif_!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631554233 977163 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :ij = rowcolumn < 1631554285 528388 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :wow, that DOMMatrix thing is surprising < 1631554710 296136 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :That's a bold move to change convention like that, but tbh, I think column/row makes more sense if we were doing it all over again, and seems especially appropriate if you only have the geometric usage of matrices as linear maps in mind. The ith column of a matrix are the coefficients (in terms of the basis on the codomain) of where it sends the ith basis vector (of the domain). < 1631554753 444491 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :The convention doesn't matter; what matters is not changing the convention midway through a module. < 1631554756 963118 :immibis!~hexchat@62.156.144.218 JOIN #esolangs * :realname < 1631554765 623456 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :there are like three or four orthogonal arbitrary convention choices for how matrixes work < 1631554817 196235 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Cale: WTB a matrix-maths library which encapsulates matrices without the ability for programmers to witness the internal indexing. < 1631554854 254604 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Is that just linear? < 1631554890 869028 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :one for when you multiply do you match the column index of the first factor with the row index of the second or backwards (most people agree on the former); one for whether your covariant vectors are row vectors or column vectors (this one has much more variance); one for what order you write the two indices; one for whether you represent the matrix row-major or column-major; and one for which factor < 1631554896 891544 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :you conjugate when you compute an inner product < 1631554898 495919 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I guess that's five mostly independent choices < 1631554941 946964 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Some of those are not entirely orthogonal < 1631554944 219206 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Cale: Ha, I'd forgotten it exists, thanks: https://hackage.haskell.org/package/linear < 1631554989 34105 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: yeah, you may have to do a basis change on these to get them orthogonal, < 1631554995 625487 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but they are five linear independent choices < 1631555008 870674 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :In the sense that while you can flip some of those conventions relative to each other, you'll also make the notation worse by doing so < 1631555060 661749 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Like, it's very important that matrix-matrix multiplication corresponds to function composition of linear maps, and matrix-vector multiplication corresponds to function application < 1631555076 300757 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: function composition in which direction? < 1631555086 967655 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :In whatever direction you write function composition < 1631555098 622042 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Which should match with function application < 1631555104 392435 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the matrix multiplication always correspond to function composition and function application, you just have to write the two factors of the matrix multiplication in the right way < 1631555119 186520 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: yes, but people never agree which way function compositions and applicatio ngo. < 1631555134 233277 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :algebraists sometimes put the function on the right, analysis the function on the left < 1631555136 470516 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :For some value of "never" where 99.9% of people agree < 1631555168 743807 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and those same algebraists may put the covariant vectors on the right, so it's backwards from function application < 1631555175 343417 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :(and some are just agreeing more begrudgingly than others) < 1631555187 16795 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :some people even write function composition backwards compared to function application < 1631555188 560744 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :If you want the opposite convention, I recommend using exponents < 1631555218 656142 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :i.e. (x^f)^g = x^(fg) < 1631555223 355210 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: the exponents are mostly for non-linear functions though < 1631555234 62325 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :inspired by how conjugation is sometimes notated by an exponent < 1631555240 746436 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Yeah, it happens with group actions, but not so much with linear maps < 1631555256 849649 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and some morphisms behave sort of like conjugations, so much that they call them outer conjugations < 1631555377 387443 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :But like, choosing one direction for composition and the opposite for matrix multiplication would just be bad. Also, choosing to have vector-matrix multiplication be the opposite way around from matrix-matrix multiplication would be really perverse < 1631555410 276108 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :It's possible to be much more confusing than necessary if you pick the combination of conventions badly < 1631555463 633502 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: ok, but I didn't count function composition among the five, so is that a problem? < 1631555479 134547 :Koen_!~Koen@77.192.201.77.rev.sfr.net JOIN #esolangs * :Koen < 1631555482 172754 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I mostly didn't count it because it doesn't really just concern matrices or vectors, but still < 1631555504 823171 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so wouldn't that be just the one convention about which side of the product the covariant vector goes? < 1631555549 644026 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :as in, if you write function applications with the function on the left, then you likely consider column vectors covariant, unless you use the rare backwards matrix multiplication convention < 1631555588 502122 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :So yeah, you can write your vectors as the "wrong" type of matrix for the matrix multiplication rule, which would be needlessly confusing < 1631555622 44385 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :and you could also define vector/matrix multiplication in a way which didn't agree with how you defined matrix/matrix multiplication, in another sense < 1631555653 745605 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Cale: er no, I certainly don't consider defining vector/matrix multiplication the opposite way from matrix/matrix multiplication < 1631555658 878676 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I've never heard of anyone attempting that < 1631555667 489903 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com PRIVMSG #esolangs :Yeah, it would be extremely dumb < 1631555767 962426 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but still, there's the choice where you write (covariant) vectors as row vectors and put a matrix on the right of the vector in matrix multiplication, and the convention where you write (covariant) vectors as column vectors and put the matrix on the left side for a matrix multiplication, and both of those are non-rare < 1631555877 379485 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :what killed you there? < 1631556425 868406 :dutch!~DutchIngr@user/dutch QUIT :Quit: WeeChat 3.2 < 1631556790 541527 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Ping timeout: 240 seconds < 1631556808 401195 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Ping timeout: 252 seconds < 1631556811 637147 :Argorok!sid195487@id-195487.stonehaven.irccloud.com QUIT : < 1631556825 152995 :Argorok!sid195487@id-195487.hampstead.irccloud.com JOIN #esolangs * :Argorok < 1631557268 155168 :dutch!~DutchIngr@user/dutch JOIN #esolangs DutchIngraham :dutch < 1631557574 959121 :dyeplexer!~dyeplexer@user/dyeplexer QUIT :Ping timeout: 265 seconds < 1631558029 244301 :hanif_!~hanif@gateway/tor-sasl/hanif QUIT :Quit: quit < 1631560044 991549 :oerjan!oerjan@sprocket.nvg.ntnu.no JOIN #esolangs oerjan :Ørjan Johansen < 1631560562 559652 :sprock!~sprock@user/sprock QUIT :Ping timeout: 260 seconds < 1631562002 826567 :Koen_!~Koen@77.192.201.77.rev.sfr.net QUIT :Quit: Leaving... < 1631562134 143576 :delta23!~delta23@user/delta23 JOIN #esolangs delta23 :delta23__ < 1631563007 136635 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1631563141 182644 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1631563245 937925 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User < 1631563771 118562 :sprock!~sprock@user/sprock JOIN #esolangs sprock :Maeve Sproule < 1631564077 652772 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631564180 478321 :riv!~river@tilde.team/user/river QUIT :Quit: Leaving < 1631564278 4185 :riv!~river@tilde.team/user/river JOIN #esolangs river :river < 1631564857 570415 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User < 1631565492 261784 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631566098 367951 :vyv!~vyv@76.68.6.254 QUIT :Quit: Konversation terminated! < 1631566306 602510 :immibis_!~hexchat@62.156.144.218 JOIN #esolangs * :realname < 1631566477 970994 :immibis!~hexchat@62.156.144.218 QUIT :Ping timeout: 265 seconds < 1631566505 125734 :sprock!~sprock@user/sprock QUIT :Ping timeout: 268 seconds < 1631566859 14303 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1631566906 406803 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds < 1631567022 605348 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1631567410 661308 :tromp!~textual@dhcp-077-249-230-040.chello.nl JOIN #esolangs * :Textual User > 1631567982 17796 PRIVMSG #esolangs :14[[0714]]4 M10 02https://esolangs.org/w/index.php?diff=88046&oldid=88018 5* 03Camto 5* (-2) 10Well I mean it is, isn't it? > 1631568070 592117 PRIVMSG #esolangs :14[[07Subreal14]]4 M10 02https://esolangs.org/w/index.php?diff=88047&oldid=88027 5* 03Camto 5* (-2) 10Now there is an implementation. < 1631568945 99236 :sprock!~sprock@user/sprock JOIN #esolangs sprock :Maeve Sproule > 1631570284 728078 PRIVMSG #esolangs :14[[07Matrixfuck14]]4 10 02https://esolangs.org/w/index.php?diff=88048&oldid=87501 5* 03Heptor 5* (-41) 10/* Notes */ < 1631570826 123276 :riv!~river@tilde.team/user/river QUIT :Quit: Leaving < 1631570851 731913 :tromp!~textual@dhcp-077-249-230-040.chello.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1631570932 121492 :riv!~river@tilde.team/user/river JOIN #esolangs river :river < 1631572918 42620 :hendursa1!~weechat@user/hendursaga QUIT :Quit: hendursa1 < 1631572978 633903 :hendursaga!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat < 1631574705 772085 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :I worry about Discord culture sometimes. I think that more than one contributor over there has missed the idea that esoteric PLT/PLD is not just "lol silly syntax" or "gl writing real programs" but an attempt to enrich mainstream language design by exploring unexamined avenues. > 1631574880 484039 PRIVMSG #esolangs :14[[07Matrixfuck14]]4 10 02https://esolangs.org/w/index.php?diff=88049&oldid=88048 5* 03Heptor 5* (+74) 10Add interpreter > 1631575027 618374 PRIVMSG #esolangs :14[[07Matrixfuck14]]4 10 02https://esolangs.org/w/index.php?diff=88050&oldid=88049 5* 03Heptor 5* (+8) 10/* Syntax */ < 1631575150 343430 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 268 seconds < 1631575711 762634 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :Corbin: a lot of articles on the wiki are like that too < 1631575786 933405 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Yes. The wiki seems to be balanced by an unwritten rule that some pages are actively maintained by their authors, and that there should not be a single unified style or presentation. This isn't bad, but it will make the situation more obvious. < 1631575799 143120 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :Well, esoteric programming can involve many things, although it is not very good if they missed the idea like you say < 1631575817 922493 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I hope you're interpreting "enrich" and "exploring unexamined avenues" in a general enough sense < 1631575825 19999 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :or else lots of good esolangs fail it too < 1631575835 707323 :oerjan!oerjan@sprocket.nvg.ntnu.no QUIT :Quit: Nite < 1631575870 700573 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :I don't know about Discord, but I see the wiki. I suppose, like they say, ninety percent is no good (I haven't actually counted, though) < 1631575935 237412 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :I think that e.g. the Trivial Brainfuck Substitutions are a much better critique of the situation than I could give. < 1631575959 340266 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :well sure < 1631576053 980204 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :I just wish that it were possible, through wiki nudges alone, to inspire a healthier PLT environment. At least it's not a barren tribalist wasteland where everybody's arguing over which Lisp is best. < 1631576218 841821 :j-bot!~jbot@irc.supplies QUIT :Ping timeout: 252 seconds < 1631576232 127886 :j-bot!~jbot@irc.supplies JOIN #esolangs * :jevalbot