2022-04-16 11:40:25 <MrMobius    > KipIngram, did you show him the game of life in apl?
2022-04-16 11:40:56 <KipIngram   > No, but I did show him the Lisp running on CGoL.
2022-04-16 11:41:13 <KipIngram   > I haven't seen an APL CGoL - did that get linked here and I missed it?
2022-04-16 11:41:33 <eris[m]     > there's a few
2022-04-16 11:41:38 <eris[m]     > all one liners
2022-04-16 11:41:56 <eris[m]     > apl.wiki/wiki/Stencil
2022-04-16 11:42:00 <eris[m]     > should have one
2022-04-16 11:43:31 <MrMobius    > another thing is how fast APL is even though it's interpreter
2022-04-16 11:43:57 <MrMobius    > when there's so little to interpret the percentage of time spent interpreting vs calculating drops to almost nothing
2022-04-16 11:44:18 <eris[m]     > apl has to spend time parsing
2022-04-16 11:44:24 <eris[m]     > means dfns are quite slow
2022-04-16 11:46:00 <KipIngram   > I also saw a mention in the last day or two that APL is well-structured to take advantages of the vector processing capabilities the processor has.
2022-04-16 11:46:08 <KipIngram   > I've never used those - it's on my list of things to learn.
2022-04-16 11:46:18 <KipIngram   > Read a couple of things on it a day or two ago.
2022-04-16 11:46:53 <KipIngram   > eris: that Stencil link is out of date or something.
2022-04-16 11:47:11 <KipIngram   > I found it, though.
2022-04-16 11:47:21 <KipIngram   > https://aplwiki.com/wiki/Stencil
2022-04-16 11:47:26 <KipIngram   > Oh, you left out the  .com.
2022-04-16 11:52:43 <KipIngram   > So, the CGoL imp on that page doesn't immediately want to work on my Dyalog install.
2022-04-16 11:54:02 <KipIngram   > Oh, the implementation is K, not straight APL.  I'm not good enough to convert yet.
2022-04-16 12:00:16 <KipIngram   > Found this:
2022-04-16 12:00:18 <KipIngram   > https://www.youtube.com/watch?v=a9xAKttWgP4
2022-04-16 12:00:41 <lagash      > Not APL but Futhark is quite interesting, especially if you're into GPGPU.. https://futhark-lang.org/
2022-04-16 12:01:25 <KipIngram   > Oh, I am interestedin GPU coding.  That's also on the list.
2022-04-16 12:12:10 <lagash      > There a FORTH that targets the GPU?
2022-04-16 12:19:25 <KipIngram   > I'm not aware of one.
2022-04-16 12:19:40 <KipIngram   > But that seems like an obvious thing to eventually tackle.
2022-04-16 12:20:21 <KipIngram   > My reading on the SSE and AVX instructions gave me the impression that they pay off the best when you have a calculation you need to do a large number of times, like on all of the data in an image or something like that.
2022-04-16 12:20:33 <KipIngram   > It's not clear to me that you gain much on "one shot" calculations.
2022-04-16 12:21:01 <KipIngram   > And how you lay out your data in RAM seems critically important.
2022-04-16 12:24:04 <KipIngram   > It also adds a TON of state that needs to be saved on context switches.
2022-04-16 12:29:34 <KipIngram   > I think for either that stuff or a GPU interface I'd be tempted to just make the thing a lockable resource so only one process could use it at a time.
2022-04-16 12:29:52 <KipIngram   > And then not worry those things on context switches.
2022-04-16 12:30:24 <KipIngram   > It's already a little annoying to me that I've pretty much punted Forth's usual "very inexpensive context switching" by making use of so many registers.
2022-04-16 12:31:21 <KipIngram   > There used to be 'pusha' and 'popa' instructions, but those fell by the wayside somewhere as the instruction set evolved.
2022-04-16 12:32:12 <KipIngram   > I wrote macros 'mpush' and 'mpop' in my nasm source, but of course all they do is hide the effort.
2022-04-16 12:32:32 <KipIngram   > I'm pretty impressed with nasm's macro facilities.
2022-04-16 12:33:07 <KipIngram   > I was able to *completely* hide all the dirty work of creating Forth's required dictionary structure.
2022-04-16 12:33:57 <KipIngram   > And also the details of that "address -> offset" relocation stuff.
2022-04-16 12:53:48 <KipIngram   > I've also found the Chapel language interesting.
2022-04-16 12:54:01 <KipIngram   > It was developed by Cray and is targeted at massive parallelism.
2022-04-16 12:54:25 <KipIngram   > It's supposed to be a step beyond "message passing" approaches which expose more of the underlying architecture.
2022-04-16 12:54:43 <KipIngram   > Supposedly it just "takes care of things" for you; like if a node fails, it just works around it, and so on.
2022-04-16 12:54:47 <eris[m]     > do you have any links?
2022-04-16 12:55:09 <KipIngram   > https://chapel-lang.org/
2022-04-16 12:55:45 <KipIngram   > Completely different from all of the thoughts I've had about multi-core and thread work in Forth - my kneejerk approach to it involved planning rather carefully what each thread would be doing.
2022-04-16 12:56:06 <KipIngram   > Which threads would run on which cores, and so on.
2022-04-16 12:56:17 <KipIngram   > I guess that's like an "assembly language" approach to parallelism.
2022-04-16 12:56:41 <KipIngram   > That shows up in my preference for structural Verilog over behavioral as well.
2022-04-16 12:56:50 <KipIngram   > I just gravitate toward "control."
2022-04-16 12:57:38 <KipIngram   > I'm installing Chapel now.  I couldn't get it to use my pre-installed LLVM, but it can be built using a bundled one as well; just takes longer.
2022-04-16 12:58:08 <KipIngram   > I installed llvm and llvm-devel first though, so I don't know why it's not seeing them.
2022-04-16 12:58:14 <KipIngram   > Need something on my path, I guess.
2022-04-16 13:00:50 <KipIngram   > Yeah - it's slowly grinding through the compilation of all the bundled LLVM stuff.
2022-04-16 13:03:40 <KipIngram   > BTW, I raised the font size one notch in my Dyalog window (just ctrl-+'d it).  Much better.
2022-04-16 13:05:43 <KipIngram   > Chapel looks an awful lot like C, but has some extra "parallel constructs."
2022-04-16 13:08:32 <KipIngram   > Oh, you know, we were talking last weekend or so about how legacy software has "steered" the evolution of CPUs.  I realized last night that virtualization has added yet another layer to that.  Early  OS's had security needs - the CPU vendors responded by adding "privilege rings."  The OS writers said "yippee" and duly ran their OS code in ring 0.  Then someone wanted virtualization, so bam - the CPU vendors
2022-04-16 13:08:35 <KipIngram   > add hypervisor support.
2022-04-16 13:08:41 <KipIngram   > Move over, old gods - there's a new god in town.
2022-04-16 13:09:02 <KipIngram   > But this had to be done in a way that let the legacy OS code continue to believe that it was the one true god.
2022-04-16 13:09:45 <KipIngram   > I can't think of what yet another layer would be, but if someone does think of it, then the CPU guys will probably extend to that too.
2022-04-16 14:33:53 <KipIngram   > Geez guys, this Chapel build is still just 2/3 finished.  Holy cow.
2022-04-16 14:34:11 <KipIngram   > My fan's singing  like an opera star.
2022-04-16 14:34:28 <KipIngram   > cclplus: 95% CPU.
2022-04-16 14:35:03 <KipIngram   > (I keep a tiny little box in the bottom left of my console screen that shows me my charge status and my top 5 cpu gobblers.)
2022-04-16 14:35:43 <KipIngram   > The CPU percentage seems to be "of one core," because sometimes it goes over 100%.
2022-04-16 14:40:21 <KipIngram   > Oh, this is cute:
2022-04-16 14:40:23 <KipIngram   > https://www.amazon.com/Quimat-Oscilloscope-BNC-Clip-Assembled-Finished/dp/B07QML4LJL/ref=sr_1_3?crid=WMT8I1TLC4V3&keywords=oscilloscope&qid=1650134352&sprefix=oscilloscope%2Caps%2C98&sr=8-3
2022-04-16 14:40:35 <KipIngram   > Low performance, but looks damn handy for a lot of things.
2022-04-16 14:40:57 <KipIngram   > And cheap.
2022-04-16 14:45:56 <KipIngram   > Hmmm.  Several low reviews, all citing "worked great one or two times, then didn't work any  more."  That's a shame.
2022-04-16 19:24:35 <KipIngram   > So, I'm trying to figure this futhork thing out.  It says you can "easily use it" to create a Python importable module that will use pyopencl to do computations on your GPU.
2022-04-16 19:26:26 <KipIngram   > I was able to pip3 install pyopencl, but haven't tested it.  Online research said that my graphics hardware (Intel CometLake GT2) is supported as of OpenCL 3.0.
2022-04-16 19:26:31 <KipIngram   > So, fingers crossed on that.
2022-04-16 19:26:55 <KipIngram   > Now I've got to figure out the futhark pyopencl targeting.
2022-04-16 19:27:26 <KipIngram   > So, in the futhark tutorial, there's an example of a line that computes the dot product of two vectors, u and v:
2022-04-16 19:27:28 <KipIngram   > reduce (+) 0 (map2 (*) x y)
2022-04-16 19:27:37 <KipIngram   > I immediately found myself seeing
2022-04-16 19:27:43 <KipIngram   > +/ u*v
2022-04-16 19:27:45 <KipIngram   > there.
2022-04-16 19:27:59 <KipIngram   > And realized there must be some similarities between futhark and APL.
2022-04-16 19:28:10 <KipIngram   > futhark is supposed to be related to Haskell.
2022-04-16 19:28:16 <KipIngram   > Which I don't know at all.
2022-04-16 19:44:29 <eris[m]     > in apl, dot product is +.×
2022-04-16 19:52:32 <eris[m]     > f.g is roughly f/a g w
2022-04-16 19:52:49 <eris[m]     > but thrres some weird corner cases that adam refuses to make clear
2022-04-16 19:56:08 <KipIngram   > That's one of those "tacit" functions, right?
2022-04-16 19:57:55 <eris[m]     > its a combinator
2022-04-16 20:00:48 <KipIngram   > Ok.  I was just looking at it's superficial appearance.  I was reading about tacit functions last night.
2022-04-16 20:01:24 <KipIngram   > You say "refuses to make clear" - does he actually duck certain questions?
2022-04-16 20:01:38 <eris[m]     > no
2022-04-16 20:01:49 <eris[m]     > im being coy here
2022-04-16 20:02:23 <eris[m]     > essentially f.g has semantics that are indescribable and not easily replicable
2022-04-16 20:02:51 <eris[m]     > `f/a g w` isnt accurate in the nested case for instance
2022-04-16 20:02:58 <eris[m]     > and so on
2022-04-16 20:03:27 <eris[m]     > it's the semantics of the f/ that simply arent present in f.g
2022-04-16 20:04:14 <eris[m]     > apl has a lot of stuff that turns out like this
2022-04-16 20:04:31 <eris[m]     > for instance, f/ has to reduce rank
2022-04-16 20:05:31 <eris[m]     > but im not sure if this limitation applies in f.g
2022-04-16 20:06:13 <KipIngram   > Ok, I kinda sorta followed that.  I progressed a fair bit for just a couple of days, I think, but a long way to go still.
2022-04-16 20:06:29 <eris[m]     > basically
2022-04-16 20:06:51 <KipIngram   > I just thought it was interesting that on a completely different front (futhark / GPU) I ran into an expression that had such a similar look.
2022-04-16 20:06:59 <KipIngram   > Just used a wordy verbose notation instead of symbols.
2022-04-16 20:07:11 <eris[m]     > futhark is an array language
2022-04-16 20:07:18 <eris[m]     > at least, they say it is
2022-04-16 20:07:27 <KipIngram   > Yes - "pure functional array language," in their words.
2022-04-16 20:07:44 <eris[m]     > running functional-ish languages on a gpu isnt that strange either :p
2022-04-16 20:07:44 <KipIngram   > I guess that makes sense for a gpu "harnesser."
2022-04-16 20:07:48 <eris[m]     > co-dfns
2022-04-16 20:07:57 <eris[m]     > is an APL for the gpu
2022-04-16 20:08:45 <KipIngram   > I've always been resistant, historically, to functional languages.  I think it's because of my embedded background - I think in terms of poking hardware and things like that.
2022-04-16 20:09:03 <KipIngram   > But this "tight connection to math" is wildly appealing to another part of my mind.
2022-04-16 20:09:23 <KipIngram   > So I think I've suddenly become a lot more open-minded.
2022-04-16 20:10:12 <eris[m]     > thats fair!
2022-04-16 20:10:30 <eris[m]     > i quite like array languages because they pick abstractions close to the CPU
2022-04-16 20:11:11 <eris[m]     > and then they dont let you build more abstractions
2022-04-16 20:11:21 <KipIngram   > Heh heh.
2022-04-16 20:11:26 <KipIngram   > I like "close to the cpu."
2022-04-16 20:11:30 <KipIngram   > Feels right.
2022-04-16 20:12:00 <eris[m]     > a good apl is cache and branch predictor friendly in a way that imperative code simply cannot be
2022-04-16 20:12:30 <eris[m]     > well
2022-04-16 20:12:38 <eris[m]     > simply isnt comfortable to write
2022-04-16 20:13:17 <KipIngram   > And when I was reading about the x86 vector instructions, it was advocating that same general style - stay away from branches that might affect some elements one way and others another way.
2022-04-16 20:13:32 <KipIngram   > Find a way to "calculate" the choice.
2022-04-16 20:13:56 <eris[m]     > calculate, dont choose!
2022-04-16 20:13:57 <eris[m]     > the forth motto
2022-04-16 20:13:58 <KipIngram   > Which looked like it could often involve doing both of the conditional cases - then use masks to apply one or the other.
2022-04-16 20:14:10 <KipIngram   > Yes - I noticed that.  :-)
2022-04-16 20:14:23 <eris[m]     > apl sometimes does that
2022-04-16 20:15:00 <KipIngram   > See, if we'd embraced that idea at the beginning, we wouldn't have NEEDED branch prediction, speculative execution, etc., and all that logic that gets used for it could be doing real work for us instead.
2022-04-16 20:22:00 <KipIngram   > I've been thinking a lot the last few days about how "legacy" and the marketplace steered us down this particular path, which probably isn't "optimal" in the long run.
2022-04-16 20:22:29 <KipIngram   > Guess it depends on how you define optimal.
2022-04-16 22:41:40 <KipIngram   > Ok, I think I've got all the pieces of this futhark / opencl toolchain working except the actual hardware drivers required for my particular GPU.
2022-04-16 23:26:12 <KipIngram   > I found a site, hardware.org, that had instructions for how to install a package that creates a "probe" of your system.
2022-04-16 23:26:22 <KipIngram   > It uploads it to their website and gives you back a URL.
2022-04-16 23:26:31 <KipIngram   > You can then share the id of that probe when you ask questions.
2022-04-16 23:26:48 <KipIngram   > So I've asked for guidance on getting the right driver installed.