< 1631321150 907469 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :WDYT, if an IRC client send a periodic PING to avoid the dreaded "TCP connection was lost but the client has nothing to write" issue, should it bother to try to also verify the server responds with a corresponding PONG, or is that superfluous? It's definitely not necessary for the TCP thing, but hypothetically there might be a server that continues to speak TCP but not respond to commands. And < 1631321152 331698 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :often it's used to estimate latency, but that's a different feature. < 1631321324 636089 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :I check manually. I have the F2 key bound to PING and then I can see if PONG is received or not. (For automated IRC clients, it could check automatically) < 1631321421 663488 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Yes, this would be for an automaton. Just wondering if it's a failure mode that really needs worrying about, assuming I don't care about estimating the latency to try to jump servers if it's too high or w/e. < 1631321700 118897 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :At least in my experience, if I try to PING and it isn't working, there will eventually be a connection error anyways. However, it might be worth checking after some (configurable) timeout anyways. < 1631321769 616405 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :It has also happened to me that I was able to receive but not send. In this case, eventually the server will disconnect me due to a ping timeout. < 1631321776 240538 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :What if it continues to speak TCP and respond to pings, but not to other commands? < 1631321829 847322 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :Then I would think that the server is defective, probably. < 1631321867 121459 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I guess I could have it privmsg me to solve a CAPTCHA. But then what if the server sends that message to some other human who responds to it? < 1631321891 34097 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection < 1631321905 672552 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse < 1631321926 730374 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :You can write a question that you do not expect anyone else to know the answer < 1631323874 581994 :earendel!uid498179@user/earendel JOIN #esolangs earendel :Amore Fuenfter Stock < 1631325197 583415 :dutch!~DutchIngr@user/dutch JOIN #esolangs DutchIngraham :dutch < 1631338021 269828 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :fizzie I always thought client is exactly supposed to respond to PING with PONG, not just send periodic PING on their own < 1631338288 443931 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :also if believe this line https://github.com/Nakilon/nakiircbot/blob/43bf3dfa932e78f19b656520d29629c9bf94c5bc/lib/nakiircbot.rb#L99 Quakenet used this command for measuring the latency too < 1631338414 634307 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :I mean when I was making this comment I was reusing some old Quakenet bot that IIRC it had the timestamp parsing in it < 1631338437 533150 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :but as it says in case of Libera there is just server name there > 1631340529 916469 PRIVMSG #esolangs :14[[07School14]]4 10 02https://esolangs.org/w/index.php?diff=87989&oldid=87986 5* 03AceKiron 5* (+391) 10Added the PUSH and POP memory operants > 1631346855 706168 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 N10 02https://esolangs.org/w/index.php?oldid=87990 5* 03AceKiron 5* (+174) 10Created page with "A **matrix** is a data structure that can serve as an programming language's memory. The number of stacks may vary. Many languages have other methods of data storing as well." > 1631346867 175255 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87991&oldid=87990 5* 03AceKiron 5* (+3) 10 > 1631346943 770001 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87992&oldid=87991 5* 03AceKiron 5* (+105) 10 < 1631346977 856490 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: I check PONG replies anyway to know when the server has processed my previous commands, which I need to know to not send more commands to the server that fit in its buffer, or else it would quit me. < 1631346989 975603 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and at that point you probably want a timeout too > 1631347102 825580 PRIVMSG #esolangs :14[[07Category:Matrix-based14]]4 N10 02https://esolangs.org/w/index.php?oldid=87993 5* 03AceKiron 5* (+181) 10Created page with "Languages primarily using one or more [[Matrix_(data_structure)|matrix]]s for storage. ==See also== * [[:Category:Queue-based]] * [[:Category:Stack-based]] Category:Langu..." > 1631347155 634107 PRIVMSG #esolangs :14[[07School14]]4 10 02https://esolangs.org/w/index.php?diff=87994&oldid=87989 5* 03AceKiron 5* (+225) 10 > 1631347198 238876 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87995&oldid=87992 5* 03AceKiron 5* (+10) 10 > 1631347260 744418 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87996&oldid=87995 5* 03AceKiron 5* (+46) 10 < 1631347580 618591 :hendursa1!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat < 1631347731 614058 :hendursaga!~weechat@user/hendursaga QUIT :Ping timeout: 276 seconds > 1631348482 885807 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87997&oldid=87996 5* 03AceKiron 5* (+1) 10 > 1631350059 25815 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 10 02https://esolangs.org/w/index.php?diff=87998&oldid=87997 5* 03AceKiron 5* (+64) 10 > 1631350270 49272 PRIVMSG #esolangs :14[[07School14]]4 10 02https://esolangs.org/w/index.php?diff=87999&oldid=87994 5* 03AceKiron 5* (-2) 10 < 1631351137 771187 :spruit11_!~quassel@2a02:a467:ccd6:1:5542:2068:efaa:d531 QUIT :Quit: https://quassel-irc.org - Chat comfortably. Anywhere. < 1631351159 585555 :spruit11!~quassel@2a02:a467:ccd6:1:5542:2068:efaa:d531 JOIN #esolangs * :anon < 1631352700 569058 :Koen_!~Koen@77.192.201.77.rev.sfr.net JOIN #esolangs * :Koen < 1631352773 364510 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer > 1631353732 667369 PRIVMSG #esolangs :14[[07School14]]4 10 02https://esolangs.org/w/index.php?diff=88000&oldid=87999 5* 03AceKiron 5* (+15) 10/* Memory operants */ < 1631353890 611910 :Trieste_!T@user/pilgrim JOIN #esolangs pilgrim :T < 1631353906 337919 :Trieste!T@user/pilgrim QUIT :Ping timeout: 240 seconds < 1631354282 629927 :Oshawott!~archenoth@2604:3d09:681:f00:a4ca:327d:3946:a076 JOIN #esolangs Archenoth :archenoth < 1631354491 842338 :archenoth!~archenoth@2604:3d09:681:f00:3593:e920:b3b6:f6a4 QUIT :Ping timeout: 252 seconds > 1631358265 931216 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Bsoelch 5* 10New user account < 1631359240 620501 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631359561 726711 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Yes, I mean, the client does need to respond to PING with a PONG, but that's a different thing. < 1631359830 196424 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :does IRC need ping and pong? doesn't TCP already have this basically < 1631360044 329183 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :TCP has an *optional* keepalive option. But I don't think it's very popular compared to application protocol heartbeats. < 1631360304 585185 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :As for not sending too many things, I'm using a credit-based system (each byte costs so and so, some commands have an extra surcharge, the client gets credit at a fixed rate capped to some maximum value) to approximate that. That's what ircd (at least the real one, the one used at IRCnet) does on the server side. Of course it's not exactly exact due to network latency and so on, but it's been < 1631360306 332498 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :working just fine. < 1631360423 919360 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :On keepalive, IIRC the default timeouts tend to be huge (hours), and configurable only system-wide. > 1631360892 59480 PRIVMSG #esolangs :14[[07Meow14]]4 10 02https://esolangs.org/w/index.php?diff=88001&oldid=87959 5* 03Martsadas 5* (+20) 10/* fixed mistakes*/ > 1631360954 919645 PRIVMSG #esolangs :14[[07Meow14]]4 M10 02https://esolangs.org/w/index.php?diff=88002&oldid=88001 5* 03Martsadas 5* (+27) 10 < 1631362551 611615 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631364637 284708 :earendel!uid498179@user/earendel QUIT :Quit: Connection closed for inactivity > 1631364758 395881 PRIVMSG #esolangs :14[[07Matrix14]]4 M10 02https://esolangs.org/w/index.php?diff=88003&oldid=42721 5* 03PythonshellDebugwindow 5* (+50) 10Confusion > 1631364768 574816 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 M10 02https://esolangs.org/w/index.php?diff=88004&oldid=87998 5* 03PythonshellDebugwindow 5* (+50) 10Confusion > 1631364777 549351 PRIVMSG #esolangs :14[[07Matrix (data structure)14]]4 M10 02https://esolangs.org/w/index.php?diff=88005&oldid=88004 5* 03PythonshellDebugwindow 5* (-17) 10m < 1631365081 621661 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631365947 286739 :hendursa1!~weechat@user/hendursaga QUIT :Quit: hendursa1 < 1631365973 624355 :hendursaga!~weechat@user/hendursaga JOIN #esolangs hendursaga :weechat > 1631367619 409097 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 034gboframram 5* 10New user account > 1631368048 13171 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=88006&oldid=87982 5* 034gboframram 5* (+184) 10/* Introductions */ < 1631369837 646251 :delta23!~delta23@user/delta23 JOIN #esolangs delta23 :delta23__ < 1631370761 528988 :Koen_!~Koen@77.192.201.77.rev.sfr.net QUIT :Remote host closed the connection < 1631370802 157791 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631370840 920366 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631371211 50757 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631371229 920436 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631371315 855745 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631371333 921406 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631371528 816345 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631371651 254541 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631372585 567933 :normsaa!~normsaa@101.175.64.73 JOIN #esolangs * :[https://web.libera.chat] normsaa < 1631372602 583585 :normsaa!~normsaa@101.175.64.73 PRIVMSG #esolangs :https://pastebin.com/px6HUCLV how can this binary be decoded? < 1631372608 704412 :normsaa!~normsaa@101.175.64.73 PRIVMSG #esolangs :In any esoteric lang? < 1631372798 569145 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :normsaa: Where did it come from? < 1631372834 537777 :normsaa!~normsaa@101.175.64.73 PRIVMSG #esolangs :Corbin A friend < 1631372850 364107 :normsaa!~normsaa@101.175.64.73 PRIVMSG #esolangs :He wrote it < 1631372986 601521 :normsaa!~normsaa@101.175.64.73 PRIVMSG #esolangs :Any ideas? < 1631373806 155274 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( it's too bad that the flag doesn't identify the CTF this is from ) < 1631373819 605134 :int-e!~noone@int-e.eu PRIVMSG #esolangs :normsaa: tell your "friend" to solve the problem properly, by themselves. < 1631374744 88851 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :Also tell your friend to fix the overlapping assignment, which probably breaks the script. < 1631375499 615875 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631375792 713515 :hanif!~hanif@gateway/tor-sasl/hanif JOIN #esolangs hanif :hanif < 1631376217 539157 :Koen_!~Koen@77.192.201.77.rev.sfr.net JOIN #esolangs * :Koen < 1631376698 490358 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :riv: yes, IRC sort of requires PING and PONG for at least three reasons. some servers (not freenode, I haven't looked at libera yet) require that you send *one* pong after connecting, copying an unpredictable code from the PING that the server sends, as a sort of anti-spam measure. second, some servers, including freenode (again, haven't looked at libera yet) require that the client sends something < 1631376704 480903 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :every five minutes, to ensure that it can drop clients that are disconnected. it ensures that clients do this by sending pings, you don't need to reply to those technically, but replying to pings is an easy way to satisfy this requirement. < 1631376878 890010 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :thirdly, you can use pings for flow control. the way IRC works is that the server has a very small input buffer for each client, and if the client sends more than that input buffer over what the server has handled locally, it disconnects the client. the server handles commands for one client in series, so if you pay attention to local replies (replies from that server, not other servers), you can < 1631376884 898599 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :sometimes tell how much the server handled, and so how full the queue is. but not all commands have local replies, or the local reply isn't always easy to identify, so sometimes you want to send a command just to force a local reply. the best command for that is a local PING (as opposed to a PING to a different server), since that does nothing but send you a reply. < 1631377254 638700 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631377283 346744 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631377320 88776 :velik!~velik@nakilon.pro QUIT :Remote host closed the connection < 1631377337 356651 :velik!~velik@nakilon.pro JOIN #esolangs * :velik < 1631377439 144231 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :int-e: wait, do you actually recognize what that is, or do you just know it's homework from what it looks like and how they simultaneously cross-post on multiple channels? < 1631377829 332662 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :int-e: I was half-expecting doing a web search for the flag value would tell you where it's from (surely all of those have answers posted online?), but apparently it doesn't. < 1631377865 978863 :int-e!~noone@int-e.eu PRIVMSG #esolangs :fizzie: yeah. which /could/ indicate that it's an ongoing one, or just that it's very obscure < 1631377887 884915 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :"It looks like there aren't many great matches for your search. Tip: Try using words that might appear on the page that you’re looking for. For example, 'cake recipes' instead of 'how to make a cake'." < 1631377900 506179 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Mmm, cake. < 1631377977 538504 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o ( glados instead of cake ) < 1631378286 273406 :hanif!~hanif@gateway/tor-sasl/hanif PRIVMSG #esolangs :google gave me this video https://www.youtube.com/watch?v=JMrd8PoxvPc, but the author doesn't do this challenge in the video < 1631378286 610234 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it's a piece of cake to bake a pretty cake < 1631378316 790372 :hanif!~hanif@gateway/tor-sasl/hanif PRIVMSG #esolangs :and the ctf site linked is dead and unarchived < 1631378665 122722 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :normsaa < 1631378803 907405 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: there's technically a third, most unlikely case: that it's from a site like Advent of Code that gives every logged in user a different test input < 1631379598 61767 :Koen_!~Koen@77.192.201.77.rev.sfr.net QUIT :Remote host closed the connection < 1631379626 832458 :j-bot!~jbot@irc.supplies QUIT :Remote host closed the connection < 1631379640 822041 :j-bot!~jbot@irc.supplies JOIN #esolangs * :jevalbot < 1631380046 373473 :oerjan!oerjan@sprocket.nvg.ntnu.no JOIN #esolangs oerjan :Ørjan Johansen < 1631380883 589714 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv < 1631381435 433456 :normsaa90!~normsaa@101.175.64.73 JOIN #esolangs * :[https://web.libera.chat] normsaa < 1631381595 890679 :normsaa!~normsaa@101.175.64.73 QUIT :Ping timeout: 256 seconds < 1631381783 315287 :normsaa!~normsaa@101.175.64.73 JOIN #esolangs * :[https://web.libera.chat] normsaa < 1631381969 889920 :normsaa90!~normsaa@101.175.64.73 QUIT :Ping timeout: 256 seconds < 1631382012 607933 :hanif!~hanif@gateway/tor-sasl/hanif QUIT :Ping timeout: 276 seconds < 1631382099 256738 :normsaa91!~normsaa@101.175.64.73 JOIN #esolangs * :[https://web.libera.chat] normsaa < 1631382105 889839 :normsaa!~normsaa@101.175.64.73 QUIT :Ping timeout: 256 seconds < 1631383327 798958 :immibis!~hexchat@62.156.144.218 QUIT :Remote host closed the connection < 1631383543 787140 :immibis!~hexchat@62.156.144.218 JOIN #esolangs immibis :realname < 1631383547 550937 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1631383941 890248 :normsaa91!~normsaa@101.175.64.73 QUIT :Ping timeout: 256 seconds < 1631384099 820496 :Guest81!~Guest81@70.109.131.188 JOIN #esolangs * :[https://web.libera.chat] Guest81 < 1631384099 820530 :Guest81!~Guest81@70.109.131.188 PRIVMSG #esolangs :h < 1631384141 460548 :Guest81!~Guest81@70.109.131.188 QUIT :Client Quit < 1631384162 422355 :normsaa!~normsaa@101.175.64.73 JOIN #esolangs * :[https://web.libera.chat] normsaa < 1631385062 164925 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :"Site compatible with IE 10 or above, Mozila [sic], ..." is probably not a good sign. < 1631385210 666239 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :ow < 1631385254 527258 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :`? tlwtnt < 1631385257 365965 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :tlwtnt? ¯\(°​_o)/¯ < 1631385270 546866 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :ow! < 1631385424 431075 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wp ow < 1631385426 713781 :velik!~velik@nakilon.pro PRIVMSG #esolangs : OW -- Wikimedia disambiguation page https://en.wikipedia.org/wiki/OW < 1631385503 169589 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :looks like sometimes there is a default page and sometimes not < 1631385533 475014 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fizzie: does it also have a link to where you can download Acrobat Reader to view their PDFs and the Java and Adobe Flash plugins, without mentioning Oracle for Java? < 1631385571 40802 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :also do they recommend at an least 256 color and at least 1024x768 pixel resolution display for best view? < 1631385654 605469 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :very long ago I made a script to say "best viewed with Mozilla" or "best viewed with Internet Explorer", always the other one than the viewer is using < 1631385679 204363 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :lol < 1631385709 320587 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :b_jonas do you know who chukchas are? < 1631385719 224467 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no < 1631385742 827187 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :ethnic Siberians who live deep in tundra with deers < 1631385747 874719 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :there is a joke < 1631385782 762668 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esolangs :b_jonas: What will do if neither is use? < 1631385802 745417 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :smth like: "to keep chukcha busy give him a paper with 'read on the other side' written on both sides" < 1631385811 919460 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :b_jonas: lol, evil < 1631385880 857887 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wp chukcha < 1631385882 13194 :velik!~velik@nakilon.pro PRIVMSG #esolangs : Chukchi people -- ethnic group https://en.wikipedia.org/wiki/Chukchi_people < 1631385921 293568 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :oh, even not Siberia < 1631386260 385970 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :zzo38: one of them was the default. I don't remember which. < 1631386339 725726 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :It didn't have those other things. Maybe it would have elsewhere on the site. > 1631386633 34925 PRIVMSG #esolangs :14[[07School14]]4 10 02https://esolangs.org/w/index.php?diff=88007&oldid=88000 5* 03AceKiron 5* (-80) 10 < 1631386825 918611 :ais523!~ais523@213.205.242.171 JOIN #esolangs ais523 :(this is obviously not my real name) < 1631386868 234583 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I think the reason why some servers ping during connection, and don't connect until they receive a matching pong, is to prevent non-IRC-related programs being tricked into connecting to IRC < 1631386893 394360 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :if your ircd ignores invalid commands (and many do), it isn't hard to put a segment of valid IRC commands in the middle of, say, an HTTP POST request < 1631386899 842571 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :that is a good reason but only requires one PING right at the start < 1631386915 354675 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :I remember a spam attack on Freenode that worked by exactly that mechanism < 1631386921 99757 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :so you can create a web page with a script that causes the viewers to spam IRC, and this has been used to create IRC worms in the past < 1631386941 392036 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it would POST a set of IRC commands that cause the user to join a bunch of channels and spam them with the URL of the page < 1631386944 890692 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :right < 1631386945 862346 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :pretty funny really < 1631386963 716108 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :HAMRADIO < 1631386970 622976 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :Postel's Law sounds good but is absolutely terrible for security < 1631386985 722652 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :Postel's Law is bad < 1631386994 76856 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :also bad for long term maintainability < 1631387002 945217 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :i remember that spam attack, that was funny < 1631387014 91688 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :\wp Postel's Law < 1631387015 245044 :velik!~velik@nakilon.pro PRIVMSG #esolangs : robustness principle -- design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others" https://en.wikipedia.org/wiki/Robustness_principle < 1631387154 485715 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :as users expect the "best guess" behavior of implementations will continue working forever < 1631387171 173737 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :leading to the codification of insanely complex behavior as exemplified by the WHATWG HTML spec < 1631387208 251974 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I do actually like what that HTML spec has done, though < 1631387226 531850 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :because it means that there are now set boundaries for exactly what you are and aren't allowed to do in HTML < 1631387233 487239 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :right < 1631387249 241540 :keegan!~beehive@li521-214.members.linode.com PRIVMSG #esolangs :it's a regrettable necessity based on the early days of the web being dominated by ad hoc systems and postel's law < 1631387254 600096 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it is Postellish in some respects, too, e.g. saying that web pages must be in UTF-8 but giving long complicated instructions for what to do if they aren't < 1631387326 581906 :arseniiv!~arseniiv@136.169.204.31 QUIT :Ping timeout: 260 seconds < 1631387385 859796 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :actually, one related problem I've been having recently, which may be unsolvably difficult, and Stack Overflow has not been helpful: < 1631387406 369694 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :given a URL, which characters in it can be safely percent-decoded without changing the meaning of the URL < 1631387410 947854 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :? < 1631387502 174773 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I'm trying to write an HTML sanitizer and would prefer to avoid allowing people to put obfuscated URLs through it, but it's so hard to figure out the rules for what will and what won't work < 1631387548 802858 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :generate string of all chars and escape it with some very common library used for that need < 1631387555 96396 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :to see what chars it will process < 1631387650 557655 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :nakilon: that basically means assuming that the library is correct, which it probably won't be < 1631387655 202546 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :pretty sure all libraries will process different set of chars ) < 1631387668 675141 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :there is probably no correct library < 1631387672 804553 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :that said, I have been trying various test strings on various browsers and one httpd, to see what happens < 1631387686 491479 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :maybe some Chrome is implemented "correctly" but it won't provide a library < 1631387690 914681 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(testing a wide range of httpds would be frustrating) < 1631387722 523115 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :one thing I did learn throughout all this is that the URL path component %2e%2e is in fact equivalent to .. and will cancel out the previous component < 1631387738 957721 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :which seems like an unwise decision from a security point of view, that's just asking for path traversal vulnerabilities < 1631387743 552693 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :also the possible achievable "correctness" of your tool is limited by how correct the servers are < 1631387761 953645 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :many of them work differently about URL escaping < 1631387773 516404 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :right < 1631387790 696460 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I think the only real option here is to have a parameter for what sort of dubious-looking escapings the user wants to exclude < 1631387797 178577 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :also additional rules and bugs in redirects < 1631388128 905744 :nakilon!~nakilon@user/nakilon PRIVMSG #esolangs :teaching velik wolfram alpha, somehow it took the whole day to make 10 tests, and it's only a piece of Math examples; there are three other topics, maybe I'll make most of them tomorrow < 1631388737 750497 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: "prevent non-IRC-related programs being tricked into connecting to IRC" => yes, that might be part of the reason. < 1631388826 138964 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :"avoid allowing people to put obfuscated URLs through it" => yeah, that's probably impossible < 1631391235 39946 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Normally I don't pay *that* much attention to update sizes, but now updating blender wants to install "libembree3-3" that will take half a gigabyte of disk. < 1631391345 294936 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :that's a pretty big library! < 1631391378 853493 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: it just seems so wrong to let people post arbitrary URLs on, say, forums or the like, when you're supposed to be sanitising the content < 1631391400 525375 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :"Intel® Embree is a collection of high performance ray tracing kernels that helps graphics application engineers to improve the performance of their photorealistic rendering application." I feel like they've probably got versions specifically tuned for a bazillion different (Intel) CPU models. < 1631391501 605905 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Heh, it's a single 485223648-byte .so file. < 1631391527 171287 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: I'm not sure I see why, except for the part where you might sanitize the protocol part (the part before the first colon) and add a max length < 1631391583 88767 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :fizzie: I suspect that you only need around eight different versions of your code to get peak performance on all 64-bit Intel CPUs < 1631391589 441367 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: though most of the time you'd probably throw in that HTML attribute that hints to search engines that this is a link by a third party submission and the search engine shouldn't think your site is deliberately linking to kiddy porn < 1631391602 990197 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and maybe another four or five more for AMD < 1631391622 24250 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: I've already been looking through the list of rel= attributes < 1631391627 805473 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it won't take away all the responsibility about what links you host, but you can't generally fix that by just looking at the URL < 1631391642 180218 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I think probably at least nofollow and noreferrer should be in there for external links by default < 1631391677 243851 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :you absolutely want to whitelist protocols though because of javascript: links though < 1631391681 986223 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :although noreferrer is interesting because you can also set an HTTP header that tells the browser to noreferrer everything < 1631391700 777557 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I explicitly turned it off on my website (as in, I outright said in the headers that I know this header exists and I'm choosing not to use it), which makes some security checkers really annoyed < 1631391720 464813 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :lol "only need around eight different versions of your code to get peak performance on all 64-bit Intel CPUs" < 1631391733 605324 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: I mean that there isn't a combinatorial explosion < 1631391752 495200 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and then you want AMD and code running on GPU and a port for ARM64 etc < 1631391776 297627 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, that's because it's really hard to make CPUs so there are only two or three companies making x86 cpus at a time < 1631391787 190556 :oerjan!oerjan@sprocket.nvg.ntnu.no PRIVMSG #esolangs :. o O ( rel=dontclickfortheloveofgod ) < 1631391788 800069 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :although, in practice nowadays, I think you can get decent performance for CPU-bound code by writing a post-AVX2 version for most people, and a pre-AVX2 version (aiming for maximum compatibility) for people who are running on really old computers < 1631391802 511052 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and they mostly develop at most three lines of them in parallel each < 1631391813 858893 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :one expensive, one home, and one low-power laptop one < 1631391814 429367 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :optimising for AMD does seem to be significantly different from optimising for Intel, though < 1631391841 616743 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :in particular, if the program isn't memory-bound, the next most relevant bottleneck on Intel is normally instruction dispatch, whereas on AMD it's usually something else < 1631391847 799083 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: and more importantly, you only need to make different versions of a few performance-critical functions, not everything in your code < 1631391901 981210 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :there might still be a combinatorial explosion if you want versions of your code that differ in ways other than the CPU hardware < 1631391909 573714 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I came up against this in the fizzbuzz I've been writing over the last year or so < 1631391940 382881 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I want to read a vector from memory, then do two instructions with that vector as one argument and a vector in a register as a second argument < 1631391952 374677 :riv!~river@tilde.team/user/river PRIVMSG #esolangs :how is the fizzbuzz coming?? < 1631391954 419613 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :on Intel, it's optimal to read the vector from memory twice < 1631391968 216079 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :on AMD, you want to read it into a register and then use it from there < 1631391993 815975 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :this is because Intel is bottlenecked on instruction decode so simply using fewer instructions is a gain, the L1 cache can handle the second read < 1631392013 504301 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Well, yes. It is a C++ project. It's possible there's a combinatorial explosion of templates instead. There isn't that much code in terms of source code lexically. < 1631392020 843814 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :on AMD the instruction decode is faster but the L1 cache has less bandwidth, so you can spare an extra instruction to read into a register to spare the cache bandwidth < 1631392030 486372 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: that might change for future AMD cpus... < 1631392036 355641 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :riv: I think I have a plan, the issue is just finding the time to write this code < 1631392066 613401 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: it's possible, but AMD seem to have been going down the path of using hyperthreading to make use of the extra instruction dispatch capability < 1631392085 180082 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(sorry, I meant dispatch not decode, AMD is bottlenecked on decode too but that only matters if you aren't in a loop because of the µop cache) < 1631392102 107210 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that said, I agree that bottlenecking on either memory access or instruction dispatch is typical these days, the execution times don't matter as much, unless you are specifically writing matrix multiplication inner loops or things like that < 1631392148 458660 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :even matrix multiplication is bottlenecked on memory access, most of the fast techniques for it are based on trying to avoid cache spills < 1631392205 819234 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, so it's only the inner loops where you actually have to care about the execution times of these floating point multiplication-add instructions. < 1631392222 724363 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it's hard to think of something that wouldn't bottleneck on memory access – maybe things like prime factorization, or pathfinding < 1631392260 628829 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: oh, fused multiply-adds are fast, but that doesn't really matter, they're more beneficial in terms of accuracy than they are in terms of speed < 1631392295 52313 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :multiply then add is 2 cycles latency, fused multiply-add is 1 cycle latency, and they both have enormous throughput (values correct for recent Intel and also recent AMD) < 1631392435 309514 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, the current CPUs are so optimized for that that you basically can't run out of multiplication units. I remember there was a time when the CPU was better at fused multiply-add than additions < 1631392465 167008 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :integer additions do actually beat all the floating-point stuff on most modern CPUs, though < 1631392502 985730 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :on Intel, this is primarily because the execution unit that handles jumps and branches can be used to do integer additions/subtractions if it isn't needed for the jump < 1631392513 391756 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: while floating point multiplications beat integer multiplications, yes < 1631392519 573838 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(because it can handle fused compare-jump, fused subtract-jump, and friends) < 1631392538 931553 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and yes, floating point multiplication performance is better than integer multiplication (although normally not that much better) < 1631392545 598406 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :only 64-bit ones though, because the mantissa is bigger < 1631392554 370389 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :Intel actually has two different floating point multipliers with different performance characterstics < 1631392564 649365 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :one has higher throughput, the other lower latency < 1631392596 74949 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: used for the same instructions? I didn't know that < 1631392598 699669 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :actually, the main throughput bottleneck I tend to hit is vector shuffles < 1631392609 858857 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: I think they're mostly used for different instructions < 1631392625 847344 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :Intel normally has only one vector shuffler, it's fast but you can only use it once per cycle < 1631392634 547483 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and lots of useful instructions fall into the "vector shuffle" group < 1631392663 295002 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :yeah < 1631392710 83164 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :there's also the infamous lane-crossing penalty (especially on AMD, but I think it affects Intel too) < 1631392755 96679 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :where it costs something like 3 cycles to do anything that combines the top half of a register and the bottom half of the register, when the register is "sufficiently large" (normally a recently introduced vector size) < 1631392798 567986 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :this is why lots of vector instructions are incapable of mixing the top and bottom half of a YMM register, they're instead basically designed as two XMM instructions in SIMD (even if they aren't normally SIMD instrucitons) < 1631392824 637197 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yeah < 1631392895 554198 :arseniiv!~arseniiv@136.169.204.31 JOIN #esolangs * :the chaotic arseniiv < 1631392924 760456 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :VPSHUFB for ymm registers specifically < 1631392970 426881 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :that was the example I was going to use < 1631392997 217224 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I am following this because AVX2 is now available on lots of CPUs < 1631393018 778502 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and there's an annoying lack of backwards compatibility, too – even if Intel or AMD figure out how to make five bits of the index useful, they won't be able to make their VPSHUFB instructions actually handle them < 1631393021 121729 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :(including my new home computer) < 1631393023 789584 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :because it would break backwards compatibility < 1631393033 798404 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I've had an AVX2-capable computer for a few years now < 1631393096 589450 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: they just add a new instruction for that. they're adding lots of new vector instructions all the time anyway. < 1631393130 693840 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :but what do they even name it? < 1631393133 719795 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :VPSHUFB5? < 1631393141 298108 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, I think it's VPERMsomething < 1631393144 969761 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :rather than SHUF < 1631393146 55636 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(with a VPSHUFB6 coming in a few years after AVX-512 is more mature?) < 1631393149 433370 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it already exists < 1631393153 322493 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :or so I think < 1631393160 265864 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :let me look it up, I think it's later than AVX2 < 1631393160 636574 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :oh, the PERM stuff normally has worse granularity than SHUF, this will be confusing < 1631393198 343980 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, there is now a VPERMB that is a full byte level shuffle even on a zmm register < 1631393207 281149 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the lower granularity was a thing of the past < 1631393228 386085 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :knowing how AVX-512 is going, this is likely to have been specified by Intel but not actually implemented by anything < 1631393228 554913 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :well, thing of the past that's still in many CPUs that we're using now < 1631393230 908294 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but you know < 1631393235 243074 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs : very long ago I made a script to say "best viewed with Mozilla" or "best viewed with Internet Explorer", always the other one than the viewer is using => rofl oh my < 1631393244 481392 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :there's a lot of AVX-512 which was specified but with no implementations < 1631393254 229795 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: quite possible. < 1631393308 5547 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :this may end up leading to another FMA3/FMA4 debacle some time in the future < 1631393332 446348 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: there's even a VPERMI2B instruction to byte level permute *two* zmm registers < 1631393339 880184 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(FMA got specified prior to being implemented, with Intel and AMD proposing different plans; each then implemented the *other's* specification, leaving them incompatible) < 1631393340 638072 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :which means 128 slots < 1631393348 726806 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :wait what? < 1631393354 789077 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :each implemented only the other's specification? < 1631393355 206914 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I think AMD implemented Intel's specification because they wanted to be compatible < 1631393358 729967 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I didn't follow that < 1631393366 524113 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I know they implemented incompatible stuff < 1631393370 885200 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but I didn't know they swapped < 1631393372 935475 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and Intel implemented AMD's specification because they couldn't get their own to work, it needed too much internal rearchitecturing < 1631393374 86133 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that is odd < 1631393384 692958 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :wow < 1631393389 146752 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(presumably this is why AMD came up with their version in the first place, it would be easier to implement) < 1631393397 754168 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but 3DNow was AMD's specification that was never in Intel, right? < 1631393408 762281 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: yes, although a couple of 3DNow commands survived < 1631393434 406449 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :admittedly, SSE is much better-designed than 3DNow was, although both are dubious in terms of encoding < 1631393467 45239 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I never really looked into the details of what 3DNow does. it was obsolete by the time I could have cared. < 1631393491 637401 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :we already had SSE4.1 by the time I started to care about SIMD instruction stuff < 1631393520 174056 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: think SSE with 64-bit-wide vectors < 1631393537 345549 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, that's MMX < 1631393544 489575 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :well, not quite < 1631393547 463490 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I thought MMX wasn't vectorised at all < 1631393557 962366 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :3DNow is, as long as you want a pair of single-precision floats < 1631393597 362299 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it was the first vector unit; it simply just wasn't a very good one < 1631393605 310785 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :MMX has the drawback that it shares state with the FPU, and you have to do a slow switch of the FPU between MMX and traditional mode each time you want to use it, since the existing ABI expects the FPU to be in non-MMX mode < 1631393630 52386 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :MMX is "vectorized" in that it can handle two 32-bit floats in a 64-bit register < 1631393651 157209 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :hmm, maybe I got them muddled then < 1631393660 634204 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but two floats per register is still a big help < 1631393661 119401 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :or maybe 3DNow uses the MMX registers for its vectors < 1631393679 738152 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it also handles packed integers < 1631393692 587221 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :https://en.wikipedia.org/wiki/3DNow! < 1631393702 853080 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, I'm wrong < 1631393703 439716 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :right, 3DNow! seems to be an extension to use the MMX registers as vector registers < 1631393714 543769 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :apparently MMX *only* handles integers < 1631393731 942659 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that's even more useful < 1631393783 552641 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :oh, so MMX does int vectorisation and 3DNow! does float vectorisation? < 1631393785 339031 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I know these days MMX is only useful to get a few extra registers that you can sometimes access with shorter encodings than anything in the later instruction sets, and basically never worth to use < 1631393809 113762 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I have no idea what 3DNow does < 1631393815 585820 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I'm actually vaguely surprised that MMX didn't become the standard for non-vectorised floating point < 1631393835 705892 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: what do you mean "the standard"? < 1631393843 873254 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it is saner than x87, and supported by all 64-bit CPUs < 1631393847 793710 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: in the ABI < 1631393874 668703 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :like, the ABI passes floats in MMX registers, assumes MMX mode at call boundaries, and the like < 1631393885 484485 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: which ABI? we can't change the x86_32 ABI, it's too late for that, and x86_64 comes with always SSE2 so by that time the point is moot < 1631393897 62898 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: x86_64 < 1631393899 668644 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :also if MMX only handles integers then that can't work < 1631393914 562966 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :no, MMX definitely does floats < 1631393935 613450 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 260 seconds < 1631393939 155577 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :no, I'm wrong < 1631393941 638090 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it doesn't do floats, only ints < 1631393947 603248 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :that's why people don't use it for float maths :-) < 1631393959 387259 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1631393979 907397 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: also SSE2 is the standard for passing floats in the x86_64 ABI, and that's a good thing < 1631394002 405304 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :because with SSE2 there, MMX is almost never useful < 1631394021 782051 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and SSE2 adds advantages, both wider vectors and a better instruction set < 1631394023 779941 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :so it looks like we have three sets of registers: integer; x87/MMX/3DNow!; and XMM/YMM/ZMM < 1631394035 683335 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :oh, 3DNow also uses the x87 registers? < 1631394043 662242 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(also random special-purpose stuff like flags, but I'm not counting those) < 1631394045 191528 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: right < 1631394056 882935 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :also (sigh) we also have AVX512 mask registers. < 1631394081 416657 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :on AVX512-capable CPUs that is < 1631394089 286491 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :x87 interprets the registers as one of three float formats (long double, plus formats which are almost but not quite the same as float and double); MMX as 64-bit integer vectors; and 3DNow! always as two floats < 1631394103 958695 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: to be fair those are really helpful for some applications < 1631394162 891704 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: no, x87 specifically stores 80-bit floats, not long doubles. there's a difference because long double is 64-bit floats in the MSVC ABI < 1631394188 142414 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :well, yes, but they're what has been known as "long double" for ages on Intellish processors < 1631394203 641173 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :but they got deprecated with the change to 64-bit < 1631394220 97044 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :because SSE2 handles 64-bit floats, yes > 1631394343 370810 PRIVMSG #esolangs :14[[07Cabra14]]4 M10 02https://esolangs.org/w/index.php?diff=88008&oldid=81202 5* 03PythonshellDebugwindow 5* (+0) 10/* Language Definition */ Fix typo < 1631394346 691432 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :Wikipedia says that 3DNow! invented SFENCE < 1631394347 337767 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :wtf there's a KADDBB/KADDW/KADDD/KADDQ AVX512 instruction? I never noticed that < 1631394390 49753 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: I admit I don't follow how the fence instructions work. I leave them to slightly higher level libraries. < 1631394391 776278 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :but that seems unlikely to me, because my understanding of the x86 memory model is that an SFENCE is only useful with non-temporal writes or write-combining memory, and I didn't think those were implemented at that point < 1631394420 36470 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: I can describe the general (non-x86-specific) implementation fairly easily < 1631394435 353583 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :imagine loads and stores as not happening instantly, but being spread out over time < 1631394466 259454 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :an lfence stops a load crossing it (it has to happen entirely before if it's before the lfence, or entirely after if it's after the lfence) < 1631394471 596522 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :likewise, an sfence stops a store crossing it < 1631394493 27741 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I think PPC conventionally has a double-double as its `long double` type. < 1631394524 612781 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :if one thread is storing two pieces of data, and another thread is loading them, then you need to sfence between the stores and lfence between the loads if you want to prevent the loading thread seeing the new value of the second store, but the old value of the first store < 1631394585 482650 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :spread out over time how? you mean they happen at different times to different layers of the cache hierarchy, going down the hierarchy if either the smaller caches need to free up space or to make the value known to other CPUs? < 1631394614 60477 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: imagine that you send a "request to write memory" but then continue executing before the request has been handled < 1631394620 968176 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :and let the motherboard respond to the request at some later time < 1631394621 104459 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: "stops a load crossing it" at what levels of the hierarchy? < 1631394661 160903 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it's a logical rather than physical barrier, it's not bound to a specific level of hierarchy < 1631394668 972490 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :so you have to match an lfence on one thread with an sfence on another < 1631394671 320000 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ok < 1631394692 580428 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I still think I don't need to know the details of this, what I do need to know is the atomic and mutex abstractions over them that libraries provide me < 1631394710 843627 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :on x86-64 specifically I think it's handled as part of the cache coherency mechanism < 1631394716 473880 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :because I don't think I write inter-thread (or inter-process) communication code that is at a lower level than those < 1631394729 743805 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :right < 1631394754 17573 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :nor CPU-level code that handles memory mapped to the video card or other memory-mapped IO < 1631394763 912436 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :one way to think about it is that sfence is one of the two main mechanisms for implementing the "release" atomic ordering, and lfence is one of the two main mechanisms for implementing the "acquire" atomic ordering < 1631394800 983846 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :atomic release is sfence then write; atomic acquire is read then lfence < 1631394843 392253 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :only, x86 has extra guarantees that most processors don't, so sfence is usually a no-op and I think many atomic libraries leave it out there on x86-64 (even though they would use it on other processors) < 1631394858 905247 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :(lfence is not a no-op, though, and is important in atomic code) < 1631394919 663046 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and as far as I understand, the compilers need to know about both fences and atomics, because they have a meaning not only on the CPU level, but for what the optimizer isn't allowed to do, and current compilers indeed do this. (in contrast, I think the compiler needn't know about mutexes directly.) < 1631394982 7627 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :the compiler does need to know about the acquire/release rules on mutexes, but either it can see the atomic read/write in the function, or else it can't see anything at all and thus has to assume the worst < 1631395011 143956 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :oh, this reminded me of a weird case of wanting a compiler barrier specifically < 1631395033 583681 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :yes, the fast (non-contented) cases mutex functions must be fast so the optimizer will see into the functions when necessary < 1631395039 663676 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :s/cases/cases of/ < 1631395041 244381 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :the idea would be in functions that undropped permissions, did a system call with checks, then dropped them again < 1631395063 107771 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :to do the checks with permissions raised, and to compiler-barrier to ensure that the undropping is done before the checks < 1631395081 591310 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :this sounds like it violates the least-permissions principle, but the point is to protect the checks from return-oriented programming < 1631395091 787204 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :in order to get permission to do the system call, the code would need to run through the checks too < 1631395126 449510 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: what kind of permission checks? aren't those undropping, permission checking, and dropping three system calls, and the compiler already mustn't reorder system calls? < 1631395141 416471 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it also reminds me of something similar by the way < 1631395169 888092 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: say, you want an mprotect() wrapper that checks that you aren't making anything executable if it was previously nonexecutable < 1631395195 830656 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: ah, so by permission checking you just mean accessing memory that may or may not have read/write/execute permissions? < 1631395207 983298 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :hmm, that might be difficult < 1631395218 715178 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I didn't mean permission checking, just checking in general < 1631395242 442237 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but even so, can't a system call basically write anything to anywhere in your user memory, so you usually can't reorder memory accesses around them anyway? < 1631395271 380653 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :oh, that's interesting – the point being that compilers wouldn't optimise system calls anyway due to not knowing what they do? < 1631395290 382945 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yes, except maybe a few specific system calls of which they know the meaning < 1631395311 622951 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :there are system calls like pread that can write even to memory that you didn't pass a pointer to to the system call < 1631395318 77638 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I know there are some functions that can system call, and that the compiler treats specially < 1631395321 885975 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :malloc, for example < 1631395350 237841 :delta23!~delta23@user/delta23 QUIT :Quit: Leaving < 1631395387 890539 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :no, not pread, sorry. < 1631395395 985993 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :preadv < 1631395475 283818 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :preadv can write anywhere, and a compiler has to assume that an unknown system call can do things worse than that < 1631395493 12195 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :preadv seems so specific < 1631395518 856366 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I can see why it could be useful – it saves the overhead of making multiple system calls when you want to do that operation specifically – but I'm unclear on how common that particular operation would be < 1631395525 378082 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it's specific in that it's a particularly badly behaving system call, that's why I'm giving it here as an example < 1631395537 938527 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :most system calls are tamer than that, but the compiler can't easily rely on that < 1631395574 772171 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I meant, I was thinking on a different line of thought when you mentioned preadv < 1631395585 641685 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :like, what was the motivation behind adding that to the kernel? who needed it, and what do they do with it? < 1631395612 396341 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't really know. < 1631395641 941096 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :99% of programs would just read into a large buffer and then copy the data into the appropriate final locations, rather than spending time coming up with a big description for preadv < 1631395649 501646 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :although, preadv is faster because it reduces cache pressure < 1631395701 631625 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I think it might be there because they wanted to get asynchronious regular file reading to work, which turned out quite hard and they're still struggling with it, but anyway the interface of the async reading allows similar scatter-gather read because it has to allow multiple reads at the same time, so they added a normal non-async interface at that point < 1631395743 575786 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :but maybe someone just used a cyclical buffer and wanted to micro-optimize the number of system calls, since the context change for system calls used to be slower than now < 1631395759 218723 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :preadv is very old, you have to remember that < 1631395765 132633 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so it can have some odd historical reason < 1631395773 950736 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :…now I'm wondering if preadv is faster than mmap + memcpy < 1631395787 535199 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :it could be, I guess? because the physical memory you mmap into has to be cached < 1631395884 865524 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: yeah, look, the manpage says "these system calls first appeared in 4.2BSD" < 1631395894 483169 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :so old it's hard to speculate about it < 1631395975 24148 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: readv is older than pread if the system call numbering can be believed < 1631396005 48350 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :b_jonas: while searching about uses of preadv, I found some mailing list archive mentions which implied that readv was newer < 1631396011 568382 :oerjan!oerjan@sprocket.nvg.ntnu.no QUIT :Quit: Nite < 1631396246 15052 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: anyway, what this reminded me of is the SSE floating point control word. these control the rounding mode, the exception mask, and two bits to change denormal inputs and results to zero in floating point instructions because those denormals would cause a big slowdown on certain CPUs. anyway, the compiler *should* know about the semantics of the SSE floating point control word to the extent that < 1631396252 22693 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :it's not allowed to reorder floating point arithmetic around changing the control word, but current compilers don't yet know this, so it's not quite clear how you can write to the floating point control in a useful way without potential undefined behavior. < 1631396266 888444 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the situation is similar to the atomic operations back when multithreading was new and compilers didn't yet know much about it < 1631396282 618713 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :or when SMP was new. < 1631396389 110561 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :what's the performance of changing the floating-point control word like? < 1631396397 335630 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I can easily imagine algorithms which want to change it a lot < 1631396420 892226 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and no, you can't just change the floating point control word in a non-inlinable function, partly because the ABI says that the rounding mode etc has to be in its default state between function calls, and more importantly because the compiler is normally allowed to reorder a floating point operation around an unknown function call. < 1631396434 199483 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :IIRC AVX-512 dedicates a couple of bits of the instruction to override parts of the FPU control word < 1631396477 131716 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :fwiw, on gcc you could probably get away with an asm voltatile that takes the results of previous FPU instructions and inputs of subsequent FPU instructions as read-write parameters and then doesn't change them < 1631396498 91172 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :would be annoying to write, but gcc would be forced to put the control-word-changing operation in the right place < 1631396509 974001 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: there are two cases when you want to change the floating point control word a lot. one is if you want to use a non-default floating point control word, but also do function calls or returns to code that you don't control since technically you have to restore the default control word because any library function is allowed to do floating instructions; the other is interval arithmetic which can < 1631396515 983146 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :change the rounding mode a lot < 1631396529 444720 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: but more likely you just want to change the control word once, then do a lot of float operations < 1631396615 831635 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :well, admittedly there's a third case, if you want to read the exception flags and have to reset them for that reason < 1631396625 430721 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I was thinking of interval arithmetic < 1631396632 480448 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :exception flags might also be relevant in some algorithms < 1631396653 198658 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :and I don't know about what performance writing the control word has, I'm mostly concerned about cases when that doesn't matter < 1631397007 784206 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :apparently you can get slowdowns for denormal results in both Intel and AMD, and the optimization manuals for the two brands detail when these can and can't happen and what you should do about them < 1631397035 31290 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :the actual rules do differ between Intel and AMD, at least for some of their CPUs < 1631397135 690078 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :I think for many float operations, denormals are emulated in firmware rather than having dedicated hardware < 1631397139 776067 :ais523!~ais523@213.205.242.171 PRIVMSG #esolangs :so the performance is terrible < 1631397178 285805 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :ais523: that's the gist of it, but the details are complicated. not all instructions with a denormal input or output give a slowdown. < 1631397204 163816 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :that's why there's an optimization manual < 1631397210 663352 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I don't claim to really understand the rules < 1631397235 887041 :normsaa!~normsaa@101.175.64.73 QUIT :Ping timeout: 256 seconds < 1631397237 162526 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :I just have to know where to look if this becomes important < 1631397267 733399 :b_jonas!~x@catv-176-63-3-104.catv.broadband.hu PRIVMSG #esolangs :fungot, does a circle have no end? < 1631397268 200304 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :b_jonas: yeah you said that geographic location has to do with the code than by using only the functional aspects of scheme systems support arbitrary-size vectors... < 1631398579 847643 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :fungot: alright, but at least it should have a coend, does it? (I don’t know what a coend is, that’s something from category theory) < 1631398580 100646 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :arseniiv: for example because it pollutes the default namespace < 1631398651 236831 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :hm that’s a bit too philosophical < 1631398735 849072 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :fungot: What is a coend but a colimit over a bifunctor? < 1631398736 16790 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :Corbin: i suppose fnord is the original? < 1631398761 356637 :Corbin!~Corbin@c-73-67-140-116.hsd1.or.comcast.net PRIVMSG #esolangs :fungot: Bi-fnord-tor? < 1631398761 614319 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :Corbin: no, he refuses to give me access to your harddrive.) < 1631398836 439592 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :fungot always tries to fool you with words when you ask significant questions < 1631398836 872383 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :arseniiv: even the ' web-sivu' in the xvid format... would it be for me making return values in your helper function seem to always be using fd3 itself, though < 1631398891 611095 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :fungot: at least tell me this: xvid or divx? < 1631398891 937528 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :arseniiv: what, thin and unnecessarily bendy? and!... but is that what you recorded was to later evaluate ( quux zot) < 1631398914 187837 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :exactly as I said, no definite answer :′( < 1631399034 38801 :arseniiv!~arseniiv@136.169.204.31 PRIVMSG #esolangs :> fix fungot < 1631399034 330376 :fungot!fungot@2a01:4b00:82bb:1341::a PRIVMSG #esolangs :arseniiv: what with my poor grammar and ' be's all over the state. so you can do < 1631399035 607317 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : *Exception: Can't be done < 1631399768 57456 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com QUIT :Remote host closed the connection < 1631399917 834990 :Cale!~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com JOIN #esolangs Cale :realname < 1631399956 666972 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Write error: Connection reset by peer < 1631399956 713203 :hendursaga!~weechat@user/hendursaga QUIT :Write error: Connection reset by peer > 1631403968 95013 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 M10 02https://esolangs.org/w/index.php?diff=88009&oldid=87590 5* 03PythonshellDebugwindow 5* (+18) 10rd > 1631403998 236500 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 M10 02https://esolangs.org/w/index.php?diff=88010&oldid=88009 5* 03PythonshellDebugwindow 5* (+1) 10Rd > 1631404011 100308 PRIVMSG #esolangs :14[[07Esolang:Sandbox14]]4 M10 02https://esolangs.org/w/index.php?diff=88011&oldid=88010 5* 03PythonshellDebugwindow 5* (+1) 10: