00:44:34 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
01:29:51 <esolangs> [[Fsx]] M https://esolangs.org/w/index.php?diff=152916&oldid=152829 * Robotosaurus6502 * (+3)
02:13:46 -!- ais523 has joined.
03:04:37 <esolangs> [[SLet/algo]] https://esolangs.org/w/index.php?diff=152917&oldid=152839 * I am islptng * (+154)
05:33:57 -!- sprock has quit (Ping timeout: 252 seconds).
05:34:37 -!- sprock has joined.
05:37:34 <ais523> hmm, after seeing how bad compilers are at vectorising code, I think the world needs a shader language that interoperates really neatly with existing programming languages
05:38:03 <ais523> like, you can just call a function written in the shader language and it goes and does the same computation on all the elements of an array, or whatever
05:39:06 <ais523> shader languages naturally vectorise because it's their entire purpose for existence – and they'd make it possible to transparently move code execution to a GPU (GPUs are of course also very SIMD)
05:51:22 <korvo> Sure. I've been thinking about this recently because I keep wanting to emit GPU assembly. Or rather I want to talk about the category implied by GPU assembly.
05:51:47 <korvo> They used to be nicely monoidal, back before call-and-return behaviors were added.
06:09:17 <korvo> ais523: TBH also existing shader languages just don't look like the underlying ISAs.
06:09:30 <korvo> They're all flavored after whatever was popular at the time, mostly C++.
06:11:20 <ais523> I guess I care more about the semantics matching the underlying architecture, rather than the syntax matching
06:11:33 <ais523> but yes, most shader languages are very C++-like
06:34:43 -!- Hooloovoo has quit (Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in).
06:39:20 <korvo> ais523: Dunno how much GPU assembly you've seen. It's mostly SIMD with masking, but the MD-ness is abstracted; the programming model only sees one vertex/fragment/etc at a time, which is why the C++-ness fits well enough.
06:40:41 -!- Hooloovoo has joined.
06:42:11 <korvo> Honestly sometimes I think that Futhark is the best that we will get for GPU programming.
06:42:42 <ais523> I've seen plenty of shader source code, but not what it compiles to
06:45:39 -!- Hooloovoo has quit (Ping timeout: 248 seconds).
06:47:26 -!- Noisytoot has quit (Remote host closed the connection).
06:47:48 -!- Hooloovoo has joined.
06:47:52 -!- Noisytoot has joined.
06:48:23 <korvo> It's a lot like DSP code, but instead of varying in time, we're varying in some sort of fragment space. So the assembly program has a bunch of GPRs, some of which have the fragment's precomputed values like color and depth, and a designated output register.
06:49:46 <korvo> In the olden days, you could do a texel lookup but only in-between programs; the programs acted as "texture combiners". But these days the program can use a dedicated assembly op to request a texel lookup with programmable coords.
06:50:33 <korvo> The punchline is that the program is never executed over fewer than four fragments. There are ops that e.g. take the *difference* between registers in a fragment; these are used to compute screen-space partial derivatives.
06:51:32 <korvo> And each little square of four fragments is recursively scheduled on ever-more-vectorized pipelines. AMD and Intel don't expose much of this, but nVidia loves to make programmers tune their "threads" and "warps" and etc.
06:53:32 -!- Hooloovoo has quit (Ping timeout: 252 seconds).
06:55:15 <ais523> korvo: I know about the whole thread/warp thing, that matters at the source level when writing shaders, in addition to the asm level
06:55:31 <ais523> (I used to teach this stuff, although I'm not sure I still remember the whole syllabus…)
07:09:55 -!- Lord_of_Life_ has joined.
07:10:45 -!- Lord_of_Life has quit (Ping timeout: 248 seconds).
07:11:16 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
07:38:32 <korvo> ais523: I implemented the assemblers for a couple GPU drivers. I'm familiar with the ISAs but not with CUDA or etc.
07:40:34 <korvo> Transparently moving code to the GPU requires that calls and returns are transparent, or else the GPU can't really call back into CPU-only code. Combine that with the limited memory bandwidth, and GPU programming really has to be all-or-nothing in terms of where it's executing.
07:43:37 -!- Hooloovoo has joined.
07:46:15 <ais523> korvo: right, GPU-to-CPU calls really don't make sense with the programming model (and CPU-to-GPU calls often have a large amount of overhead so you don't want to make very many of them)
07:47:18 <korvo> ais523: Have you ever heard the tragedy of BARth AGP? It's not a story the PCI bus would tell you.
07:47:39 <ais523> I guess I'm currently thinking along the line of "a restricted language subset designed to SIMDify well" (e.g. via restricting the use of control flow statements)
07:47:52 <korvo> Everybody focuses on the "GiB/s" part of GPUs and not the context of "GiB/s of pixels on HDMI out".
07:48:19 <ais523> and requiring the memory access patterns to be well-behaved
07:48:47 <korvo> That latter bit is the key, I think. Athas (Futhark's author) had similar points of discussion.
07:49:29 <korvo> nVidia realized this early. They have device-specific texel layouts to optimize access, usually based on Z-ordering with Morton curves.
07:50:34 <ais523> last time I checked (which was a while ago now), Intel processors were able to handle badly-behaved SIMD memory accesses much more efficiently than AMD processors – that said I think there were probably tradeoffs made to make that happen and I'm not sure they were worth it
08:25:32 <esolangs> [[BitChanger Busy beaver/Proof]] https://esolangs.org/w/index.php?diff=152918&oldid=152815 * C++DSUCKER * (+2676)
08:35:07 -!- Sgeo has quit (Read error: Connection reset by peer).
08:35:29 <esolangs> [[Fsx]] https://esolangs.org/w/index.php?diff=152919&oldid=152916 * 47 * (+23)
08:39:12 -!- craigo has joined.
08:50:06 <esolangs> [[User:BrainFuckGirl]] https://esolangs.org/w/index.php?diff=152920&oldid=152786 * BrainFuckGirl * (+39) /* Code */
08:52:43 <esolangs> [[User:BrainFuckGirl]] https://esolangs.org/w/index.php?diff=152921&oldid=152920 * BrainFuckGirl * (+64) /* Heart in a Heart */
08:55:09 <esolangs> [[User:BrainFuckGirl]] https://esolangs.org/w/index.php?diff=152922&oldid=152921 * BrainFuckGirl * (+487) /* Hello, world! */
09:05:13 <b_jonas> korvo: wait, you wrote GPU drivers? wow
09:06:26 <b_jonas> “and not the context of ‘GiB/s of pixels on HDMI out’” => I heard they solved that problem by switching from HDMI to DisplayPort
09:07:25 -!- Hooloovoo has quit (Read error: Connection reset by peer).
09:11:09 -!- Hooloovoo has joined.
09:11:39 <b_jonas> ais523: yes, if you want vectorized code from the compiler you have to write code that explicitly handles vectors, with either the intel intrinsics (that both MSVC and gcc supports) or the gcc intrinsics, or these days with the vector intrinsics in the rust standard library. For some code you can use an existing higher-level library to do this. Most of those libraries have a general enough interface
09:11:45 <b_jonas> that they can operate on any aligned raw memory region, rather than only on objects that you allocate and manage with that library. That means you can mix and match different libraries and hand-written assembly.
09:14:09 <b_jonas> I've done that mix and match at my previous job for calculations on raw pixel image data, with OpenCV doing most of the image operations, but eigen and at least two pieces of hand-written vectorized loops involved for when OpenCV didn't have the right operations, then Cairo used for rendering, and ffmpeg and sometimes ImageMagick used for decoding/encoding/displaying images or videos.
09:14:58 <ais523> ais523: yes, if you want vectorized code from the compiler you have to write code that explicitly handles vectors ← I agree that you are correct on this, but am upset that it's the case
09:16:36 <b_jonas> Most of that code that I wrote was compiled for x86. At least one snippet involving OpenCV plus Eigen was compiled for an ARM processor, but that was done by some other co-worker who was hard to get information out of so I'm not sure of the details.
09:18:29 <b_jonas> There were multiple other libraries involved that I hadn't mentioned above.
09:20:46 <b_jonas> I should get a job where I can write more of this nonsense because it's fun.
09:21:39 <b_jonas> And I should perhaps learn some basic GPU programming too. I would prefer to specialize to CPU, but there are just tasks where GPUs are so much better I can't ignore them.
09:24:08 <b_jonas> I'm curious about the unsolved geometry problem that Tom7 is trying to solve, but I expect we won't get details about it tomorrow, we'll have to wait for Sigbovik
09:24:20 <ais523> GPU programming and CPU SIMD programming are very reminiscent of each other (although not exactly the same)
09:24:40 <b_jonas> he didn't give specifics other than one terrible pun
09:25:38 -!- Hooloovoo has quit (Ping timeout: 248 seconds).
09:32:29 <b_jonas> hmm, let me ask a question about GPUs then. so you know for 3D graphics you want to do this texture mapping thing where you have an array of texture coordinates for every pixel on screen, and another bitmap array that has the texture, and you want to look up the pixel in the texture for every coordinate, ideally with antialiasing by interpolating values when the texture is grown in size or averaging
09:32:35 <b_jonas> values when the texture is shrunk in size. it's not supposed to be possible to do this fast, yet programs with 3D graphics seem to do it all the time. how do programs cheat to do it nevertheless, what support do GPUs provide for this, and what are the limits of what you can do this way?
09:34:47 <b_jonas> I know that's very broad and I can't expect a complete answer on IRC, but I have to start somewhere
09:35:16 <b_jonas> A better question might be, what's a good introductory book for me that answers GPU programming questions like this?
09:36:14 <ais523> the short answer to the original question is "the various relevant scalings of the texture are precalculated, and doing the other operations for each pixel on each frame is actually fairly fast for modern processors"
09:36:17 <b_jonas> Ideally one that's not focused only on machine learning and bitcoin mining
09:37:14 <ais523> the reason the texture scalings are precalculated is for the scalings down to smaller sizes, to save on memory reads – correctly scaling down a texture to (say) 1/16 of its size means reading 256 times as many pixels
09:37:26 <b_jonas> ais523: ok, but like what kind of cache do the precomputed texture values have to fit so that this can stay fast enough?
09:38:02 <b_jonas> and how much do GPUs help in this?
09:38:09 <ais523> so the nice thing about it is that the only precomputed values are scalings down (a scaling up + interpolation only requires looking at, like, 4 or so pixels from the original)
09:38:30 <ais523> so you store the texture at original size, half size, quarter size, etc. and that's only a fairly small increase in the amount of texture memory
09:39:38 <ais523> GPUs are pretty much required to do this at speed, they have enough parallelism that running the same code for every pixel on every frame is quite doable as long as the code is no more than moderately complicated (and by modern machine standards, that can be quite complicated)
09:39:47 <b_jonas> that sounds nice but I don't think it can work because if you want affine transform the images squishing it down to very narrow in any possible directions then you have to cache something close to every angle, because you have to be able to average a thin paralellogram in any direction
09:40:32 <ais523> b_jonas: I guess a program could do that? but mostly they just produce inaccurate results in that sort of corner case and rely on human vision to not notice
09:40:39 <b_jonas> "running the same code for every pixel on every frame is quite doable" => yes, but the problem here is not the code but that you have to do memory lookups into the texture memory for every pixel, and that's the part that shouldn't be possible to parallelize even for a GPU
09:41:11 <ais523> something that's distant and foreshortened due to being at an angle (which is the only case in computer graphics where that could plausibly happen) isn't particularly visible and isn't likely to be perceived as particularly relevant, so if the color is slightly off people won't notice
09:41:29 <b_jonas> (wait, which l is doubled... the first one. I can never remember.)
09:42:12 <ais523> b_jonas: you're right that fitting all the textures into cache is one of the primary bottlenecks in GPU programming
09:43:03 <ais523> I think this is the main reason for the loading screens you get in computer games – GPUs make much heavier use of explicit prefetching (including over long time periods) than CPUs do
09:45:08 <ais523> IIRC GPU memory mapping is also much simpler than on a CPU, so the GPU has to do less work calculating physical addresses and the like
09:47:25 <b_jonas> for GPUs I'm more interested for the kind of computations that you want in 3D graphics than the neutral net machine learning or bitcoin mining aspects
09:47:54 -!- Hooloovoo has joined.
09:48:06 <ais523> the GPU side of the neural net stuff actually mostly isn't interesting, it's basically just embarrassingly parallel SIMD
09:48:10 <b_jonas> even if I understand why the bitcoin mining aspect is important for others to study for cryptanalysis
09:49:17 <ais523> and I think the bitcoin mining is similar (you're just calculating a load of hashes in parallel, and hashing algorithms tend not to have any control flow so that can be pure SIMD too)
09:49:48 <ais523> GPUs doing control flow is some of the most interesting things about them but I don't fully understand how it works myself, so I'm not going to attempt to explain it
09:52:07 <b_jonas> yes, symmetric crypto primitives basically have to be designed in such a way that it's easy to run them in parallel on a GPU
09:52:40 <ais523> the other interesting aspect is when they read memory from one part of the computation that was written in another, there are some synchronisation tricks that you couldn't do with regular CPU threads
09:53:20 <b_jonas> and even public key crypto is like that to some degree: in particular you want to have no control flow in the primitives because control flow generally leaks sensitive data on side channels
09:53:25 <ais523> b_jonas: well, the world of cryptocurrency includes people who were annoyed at GPU miners and aimed to intentionally break them, normally by coming up with crypto primitives that required a lot of memory to implement and were hard to parallelize for that reason
09:53:59 <ais523> but it's not something I really care about or follow
09:56:19 <b_jonas> ais523: yes, IIUC there are two versions of these: password hashing is designed to require lots of memory, which means you can't run many of them on parallel no matter what hardware you have;
09:58:44 <b_jonas> and then there's the time locking thing where you don't need a lot of memory so in theory you could parallelize things, but there's a long sequence of operations that depend on each other so you need a lot of time to complete an operation, and this is set up either for time locking such that you can compute the encryption quickly but decryption necessarily takes a lot of time, or you can do the inverse
09:58:50 <b_jonas> where you have proof of a computation that must have taken a lot of time in sequence for you but you save the intermediate results so anyone can verify quickly by computing parts in parallel.
09:59:35 <b_jonas> for password hashing both the original setup and the verification are slow
10:03:44 <ais523> apparently many modern GPU programs get extra texture cache performance by storing textures compressed and decompressing only after they're read out of the cache, so the textures are cached in compressed form and thus more fits in there
10:04:44 -!- rodgort has quit (Quit: Leaving).
10:15:19 -!- rodgort has joined.
10:48:58 <esolangs> [[User:BrainFuckGirl]] https://esolangs.org/w/index.php?diff=152923&oldid=152922 * BrainFuckGirl * (+1120) /* Code */ added the big "Hello, world!"
10:53:30 <esolangs> [[User talk:BrainFuckGirl]] https://esolangs.org/w/index.php?diff=152924&oldid=152863 * BrainFuckGirl * (+254) /* Question */
11:13:56 -!- ais523 has quit (Quit: quit).
11:16:57 -!- Guest46 has joined.
11:17:19 -!- Guest46 has quit (Client Quit).
11:21:15 <esolangs> [[Sembly]] M https://esolangs.org/w/index.php?diff=152925&oldid=152892 * Hotspot5 * (+14) changed flip description
11:27:29 <esolangs> [[Sembly]] https://esolangs.org/w/index.php?diff=152926&oldid=152925 * Hotspot5 * (+1)
11:44:11 <esolangs> [[User:PrySigneToFry/Sandbox/PsiLine History]] N https://esolangs.org/w/index.php?oldid=152927 * PrySigneToFry * (+3896) Created page with "Everything before 19th century is same as OTL universe. = 19th century = * 1800: Ming Dynasty found again, and has no progress ---- It missed the industrial revolution. * 1805: Opium wars start. * 1812: Opium wars end, Ming Dynas
11:44:51 <esolangs> [[User:PrySigneToFry/Sandbox]] https://esolangs.org/w/index.php?diff=152928&oldid=152765 * PrySigneToFry * (+65)
11:50:33 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=152929&oldid=152904 * PrySigneToFry * (+930)
11:57:23 <esolangs> [[UserEdited]] https://esolangs.org/w/index.php?diff=152930&oldid=152929 * PrySigneToFry * (+1493)
11:58:56 <esolangs> [[EternalGolf]] https://esolangs.org/w/index.php?diff=152931&oldid=152465 * PrySigneToFry * (+0)
12:01:39 <esolangs> [[Mutzerium]] https://esolangs.org/w/index.php?diff=152932&oldid=152791 * PrySigneToFry * (+240)
12:03:44 <esolangs> [[Mutzerium]] https://esolangs.org/w/index.php?diff=152933&oldid=152932 * PrySigneToFry * (+63)
12:04:25 <esolangs> [[Mutzerium]] https://esolangs.org/w/index.php?diff=152934&oldid=152933 * PrySigneToFry * (+70)
12:20:21 <esolangs> [[Special:Log/newusers]] create * Jackmhny * New user account
12:24:13 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=152935&oldid=152883 * Jackmhny * (+129) /* Introductions */
12:24:33 <esolangs> [[Talk:Onechar]] N https://esolangs.org/w/index.php?oldid=152936 * Jackmhny * (+2) Was this page written by an English speaker? I don't understand it at all
12:40:45 <esolangs> [[User:None1]] https://esolangs.org/w/index.php?diff=152937&oldid=151406 * None1 * (+40)
12:48:59 <esolangs> [[Vector]] N https://esolangs.org/w/index.php?oldid=152938 * None1 * (+923) Created page with "'''Vector''' is an [[OISC]] invented by [[User:None1]], it uses a 3-dimensional vector. ==Data== As said above, Vector uses a 3D vector called ''A'', it is initially (0,0,0). A vector literal is represented by 3 real numbers separated by spaces. ==Command== ''B'' ''c'' ''
12:51:02 <esolangs> [[Vector]] https://esolangs.org/w/index.php?diff=152939&oldid=152938 * None1 * (+240)
12:58:08 <esolangs> [[Vector]] https://esolangs.org/w/index.php?diff=152940&oldid=152939 * None1 * (+629)
12:59:00 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=152941&oldid=152912 * None1 * (+13) /* V */
12:59:24 -!- wib_jonas has joined.
13:00:06 <esolangs> [[User:None1]] https://esolangs.org/w/index.php?diff=152942&oldid=152937 * None1 * (+43) /* My Esolangs */
13:08:12 <wib_jonas> Is there a computable version of the Cantor-Schröder-Bernstein theorem? For example, f and g are both injective functions from the natural numbers to the natural numbers, imagine them as compilers both ways between two programming languages if you wish. You are given f and g as oracles only that you can call multiple times, but you also get a
13:08:12 <wib_jonas> primitive recursive function b as a bound for how fast they grow, so for any x, f(x)<s(x) and g(x)<s(x). Is there an oracle algorithm that implements a bijection m from naturals to naturals such that for any x, either m(x) = f(x) or g(m(x)) = x?
13:08:33 <wib_jonas> I'm not sure this is the exact right statement, I'm just looking for something similar to this
13:08:57 <esolangs> [[Mutzerium]] https://esolangs.org/w/index.php?diff=152943&oldid=152934 * PrySigneToFry * (+375)
13:19:10 <esolangs> [[Talk:UserEdited/that long command]] N https://esolangs.org/w/index.php?oldid=152944 * PrySigneToFry * (+382) Created page with "Actually, I don't think it's a big deal to pronoun people, and I even allow people to call me "this/that". But religious beliefs and national dignity should not be stigmatized or discriminated against (hence my disgust and dissatisfaction
13:33:20 <esolangs> [[Talk:UserEdited/that long command]] https://esolangs.org/w/index.php?diff=152945&oldid=152944 * Hotcrystal0 * (+180)
13:35:36 -!- chomwitt has joined.
14:11:21 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=152946&oldid=152792 * Hotcrystal0 * (+23)
14:11:52 <esolangs> [[User:PrySigneToFry/Sandbox/Users that is also on other place]] https://esolangs.org/w/index.php?diff=152947&oldid=152946 * Hotcrystal0 * (-24)
14:14:13 <esolangs> [[User:Hotcrystal0/My esolang ideas]] https://esolangs.org/w/index.php?diff=152948&oldid=152710 * Hotcrystal0 * (-43)
14:14:35 -!- wib_jonas has quit (Quit: Client closed).
14:28:43 <esolangs> [[PoeticChicken]] https://esolangs.org/w/index.php?diff=152949&oldid=152889 * Hotcrystal0 * (+23)
14:50:28 <esolangs> [[User:PrySigneToFry/Sandbox/PsiLine History]] https://esolangs.org/w/index.php?diff=152950&oldid=152927 * Ractangle * (+0) did you mean:Out universe
14:50:32 -!- Sgeo has joined.
15:27:32 -!- craigo has quit (Quit: Leaving).
16:48:08 -!- amby has joined.
17:19:35 <esolangs> [[GaoErFu]] N https://esolangs.org/w/index.php?oldid=152951 * Hotcrystal0 * (+23) Redirected page to [[]]
17:39:29 -!- Noisytoot has quit (Quit: ZNC 1.9.1 - https://znc.in).
17:39:53 <esolangs> [[Fishheads]] https://esolangs.org/w/index.php?diff=152952&oldid=103636 * Hotcrystal0 * (-12)
17:41:11 <esolangs> [[Fishheads]] https://esolangs.org/w/index.php?diff=152953&oldid=152952 * Hotcrystal0 * (-12)
17:43:23 -!- Noisytoot has joined.
17:57:53 -!- ais523 has joined.
19:10:29 <esolangs> [[ASMM]] N https://esolangs.org/w/index.php?oldid=152954 * Chillaxe * (+2045) Created page
19:15:02 <esolangs> [[Talk:Golfuck]] N https://esolangs.org/w/index.php?oldid=152955 * UrnEn * (+261) Created page with "== Why does that quine works == Well it seems just repeatedly copying itself forever but it can't print. Dumb me if there's something I didn't noticed. --~~~~"
19:25:02 <esolangs> [[Stairlang]] N https://esolangs.org/w/index.php?oldid=152956 * * (+2281) Started the page
19:25:13 <esolangs> [[Compass]] https://esolangs.org/w/index.php?diff=152957&oldid=152679 * 47 * (+8) /* Hello, world! */
19:27:18 <esolangs> [[BitChanger Busy beaver/Proof]] https://esolangs.org/w/index.php?diff=152958&oldid=152918 * C++DSUCKER * (+1217)
19:27:22 <esolangs> [[Stairlang]] M https://esolangs.org/w/index.php?diff=152959&oldid=152956 * * (+103) Added two commands
19:56:57 <int-e> Hmm... alternative Sea magic objective? https://int-e.eu/~bf3/tmp/seamin.png (probably not too interesting except for ice 2; I'm mainly doing this because I want to see if finishing with ~2k points is somehow interesting)
19:58:34 <zzo38> Do you have description of the rules of the games?
19:59:20 <int-e> Not really; there are spells and those are hard to describe in text. https://epicpikaguy.itch.io/sea-magic is the game
19:59:42 <int-e> runs in browser, and there's a windows download that works with wine
20:00:49 <int-e> Trying https://epicpikaguy.itch.io/bee-magic is probably helpful if the spell mechanic is too confusing.
20:00:57 <zzo38> The game is not work in my computer (and neither does Wine, due to package manager conflicts), although I can see that there is screenshots
20:01:34 <int-e> You unlock spells that require a certain sequence of moves. But the spells have levels and for some spells that affects the sequence of moves.
20:01:42 <int-e> So it's complicated.
20:11:00 <int-e> Yay I hit 2000 exactly: https://int-e.eu/~bf3/tmp/sea2000.png
20:15:44 <zzo38> (A game I like to play is Hero Hearts, and recently I had figured out one level that I had not figured out before. I think it is good to have all of the rules known, and I think Magic: the Gathering does better than some similar games that do not explain as well.)
20:16:27 <zzo38> (The rules for Pokemon have unfortunately not even been fully documented and not always entirely clear, but much of it is documented much better than the people who made the game did so, fortunately. I would hope that it can be improved further, too.)
20:18:58 <zzo38> (But I know about the rules of Hero Hearts because I had written my own implementation of it, and in doing so, found mistakes and incomplete stuff in the documentation.)
20:30:44 <zzo38> I had tried to write some rules of some games on http://esolangs.org/wiki/User:Zzo38/Game_rules but some only have brief descriptions since they are much more complicated than can be explained there. (Probably someone with more to write about Magic: the Gathering and its relation with esolangs should mention that too)
20:33:26 <zzo38> (Also, many explanations of game rules usually mention the goal of the game first; I find it more helpful to explain the rules first, since the goal of the game is a consequence of the rules and can be understood better if the rules are understood.)
20:39:50 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=152960&oldid=152941 * Buckets * (+14)
20:40:04 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=152961&oldid=152913 * Buckets * (+13)
20:40:21 <esolangs> [[Imbored]] N https://esolangs.org/w/index.php?oldid=152962 * Buckets * (+2113) Created page with "{{Lowercase}} imbored Is an Esoteric programming language created [[User:Buckets]] in 2022, To be specific, imbored Is not the real nsme, there was no real name except the singular phrase "imbored" at the top of the Document. {| class="wikitable" |- ! Commands !! Instru
20:40:45 <esolangs> [[Imbored]] M https://esolangs.org/w/index.php?diff=152963&oldid=152962 * Buckets * (+2)
20:41:44 <esolangs> [[Imbored]] M https://esolangs.org/w/index.php?diff=152964&oldid=152963 * Buckets * (+2)
20:55:59 -!- chomwitt has quit (Ping timeout: 265 seconds).
20:56:17 <esolangs> [[ABBa]] N https://esolangs.org/w/index.php?oldid=152965 * Buckets * (+21) Redirected page to [[aBBa]]
21:15:22 <b_jonas> yeah, I think that's not enough, we need stronger conditions if we want a computable version. the problem is that you can have two small numbers such that you eventually reach one from the other by applying f and g alternatingly a lot of times, but only through a long chain that goes through very large numbers, and you can never exclude that this is the case if you don't have a *lower* bound for how
21:18:13 <b_jonas> but it should be possible to give reasonable stronger conditions, like if x<f(x) and x<g(x) always then every chain has a start and rises from there, and you can find this start by trying all numbers less than your target
21:58:55 -!- Everything has joined.
22:05:12 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
22:08:42 -!- Lord_of_Life has joined.
22:24:16 <korvo> b_jonas: From the backlog: Yeah, I wrote portions of the Radeon drivers in Mesa3D, specifically `r500`, `r300g`, and `r600g`, in the late 2000s. I also turned down two opportunities to do it as a long-term career.
22:24:43 <korvo> You might want to look up "mipmaps", which are a big part of how that multi-level-of-detail texture-lookup is made efficient.
22:25:24 <korvo> The other secret part is that a texture has to be in a specific part of the GPU's address space. The details are encapsulated by "texture binding", which is relatively expensive compared to sampling.
22:27:08 <korvo> That computable-bijection question is good nerd-sniping. Gonna be thinking about that for a while.
22:28:27 <b_jonas> I think I answered it in a way that's satisfactory for me above
22:31:03 <b_jonas> by the way if you can modify the compilers then you can make them easily invertible by embedding the original source code as a comment in the compiled version in a way that it can be extracted easily. then you just have to extract the comment, recompile it, and check if it matches.
22:31:25 <zzo38> I would want to have something more like Checkout for GPU programming, although for some uses (such as some types of graphics) it would be helpful to include trigonometric functions as well, including arctangent function (and exponents can also be helpful).
22:31:45 <b_jonas> that way you can even make a quickly computable bijective compiler between programming languages
22:32:08 <zzo38> Also, is there C compilers that you can compile more quickly if the binary is already present (just to ensure that it matches, or if it does not match to be able to avoid recompiling parts that are unnecessary even within the same source file)?
22:49:33 <esolangs> [[Talk:aBBa]] N https://esolangs.org/w/index.php?oldid=152966 * Aadenboy * (+393) Created page with "couldn't you just use <code><nowiki>{{DISPLAYTITLE:aBBa}}</nowiki></code> instead of a zero width joiner? ~~~~"
23:44:42 -!- Sgeo_ has joined.
23:46:45 -!- Sgeo__ has joined.
23:47:44 -!- Sgeo has quit (Ping timeout: 252 seconds).
23:49:12 -!- Sgeo_ has quit (Ping timeout: 252 seconds).