2023-10-20 02:25:03 <KipIngram   > Wow, it's pretty straightforward using AVX instructions in C.
2023-10-20 02:25:10 <KipIngram   > Discussion here:
2023-10-20 02:25:12 <KipIngram   > https://www.codeproject.com/articles/874396/crunching-numbers-with-avx-and-avx
2023-10-20 02:25:24 <Zarutian_iPad> via intristics?
2023-10-20 02:25:28 <KipIngram   > Yes.
2023-10-20 02:25:44 <KipIngram   > Looks like cleverly arranging your data is a key  part of it.
2023-10-20 02:26:17 <Zarutian_iPad> well, does avx have scatter and gather vectors?
2023-10-20 02:27:03 <Zarutian_iPad> basically an vector of addresses to gather data from or writing data to
2023-10-20 02:33:46 <KipIngram   > They do appear to have something along those lines.  Still reading.
2023-10-20 02:37:03 <Zarutian_iPad> if it also has the equiv of conditional move but in vector form then implementing an multi instance dual stack machine virtual machines like I described many moons ago is possible.
2023-10-20 04:52:09 <KipIngram   > Well, that's a little disappointing, though not wholly surprising.
2023-10-20 04:52:44 <KipIngram   > Cores will downclock when the start to overheat.  They heat faster when you make heavy use of the AVX instructions (no surprise there).
2023-10-20 04:53:00 <KipIngram   > So when it's all said and done it's hard to know exactly how much performance you gain.
2023-10-20 04:53:11 <KipIngram   > From the instructions, I mean.
2023-10-20 04:54:05 <KipIngram   > I saw a blurb once that implied thermal performance was the big advantage of going to graphene as a substrate rather than silicon.
2023-10-20 04:54:15 <KipIngram   > apparently it conducts heat much, much better than silicon.
2023-10-20 04:54:33 <KipIngram   > The blurb mentioned 100x clock speed potential.
2023-10-20 04:54:46 <KipIngram   > Just from better ability to remove heat.
2023-10-20 04:55:02 <KipIngram   > I guess that didn't mean we'd know how to go that fast - just that from a cooling perspective we could imagine it.
2023-10-20 05:14:23 <KipIngram   > Geez.
2023-10-20 05:14:51 <KipIngram   > I remember the good old days, when I could pick up a book that documented cycles per instruction and tell you EXACTLY how fast a piece of code would run.
2023-10-20 05:15:33 <KipIngram   > But these days, what with cache and downclocking based on temperature, etc. etc. etc...
2023-10-20 05:15:42 <KipIngram   > It's more or less just impossible to know.
2023-10-20 05:25:08 <KipIngram   > I always admired the "precision timing" aspect of digital electronics.  Quartz crystal, man.  It was just one of the perks.
2023-10-20 05:26:19 <KipIngram   > Of course, interrupts could dicker with it some, even then, but you could turn those off in the most real-time critical bits of your work.
2023-10-20 05:28:42 <KipIngram   > Looks like my processor supports avx2 but not avx512.
2023-10-20 05:46:52 <KipIngram   > Zarutian_iPad: looks like there are quite a few GATHER instructions.
2023-10-20 05:49:12 <KipIngram   > Looks like they're calling the latest round AVX-10.  It was announced in August.
2023-10-20 07:25:18 <KipIngram   > https://cs.stanford.edu/people/shadjis/blas.html
2023-10-20 13:24:40 <xcombelle   > about sectorforth: nand is shitting, with only nand gates you can build any logical circuit.
2023-10-20 13:25:17 <xcombelle   > heat dissipation is one of the major limitations in designing a ship
2023-10-20 14:06:35 <gordonjcp   > you *can* but it's easier if you use other types of gates
2023-10-20 14:06:50 <gordonjcp   > building a register out of just NAND gates is tedious
2023-10-20 14:15:29 <veltas      > You can program in brainf*** but it's not recommended
2023-10-20 15:49:03 <KipIngram   > xcombelle: Yeah, NAND is a "universal logic group" all by itself.
2023-10-20 15:49:22 <KipIngram   > NOR is too.
2023-10-20 15:50:15 <KipIngram   > To prove that you can just show how to implement AND< OR, and NOT using NAND only or NOR only.
2023-10-20 15:50:39 <KipIngram   > DeMorgan's theorem helps with a formal proof.
2023-10-20 15:52:51 <GeDaMo      > https://www.nandgame.com/
2023-10-20 15:54:27 <KipIngram   > Also, heat dissipation is one of the major limitations in the performance of electrical machinery (motors and generators) too.
2023-10-20 15:54:38 <KipIngram   > That heat - it's always getting in the way.
2023-10-20 15:56:12 <GeDaMo      > I was just reading "Look ma, no fans: Mini PC boasts slimline solid-state active cooling system" https://www.theregister.com/2023/10/20/mini_pc_boasts_slimline_solidstate/
2023-10-20 15:57:07 <thrig       > better than users sticking a pencil into the rattling fan that was annoying them
2023-10-20 15:58:32 <KipIngram   > Oh, that's neat.
2023-10-20 16:14:00 <lispmacs[work]> 12
2023-10-20 16:14:10 <lispmacs[work]> sorry, wrong window
2023-10-20 16:36:06 <KipIngram   > xcombelle: That thermal limitation - that's really what I was reminded on last night while looking into AVX and particularly AVX512 instructions.  They're hugely powerful instructions, but if you start using them heavily your processor is apt to downclock to keep temperature in bounds.  So if the main limit on your performance is thermal, then to some extent using more powerful instructions doesn't do you a
2023-10-20 16:36:08 <KipIngram   > whole lot of good.
2023-10-20 16:36:53 <KipIngram   > It's going to help some, because at least with the vector instructions you're getting more "data work" done per unit of "control work," but you're definitely not going to just multiply your performance by N.
2023-10-20 16:38:59 <KipIngram   > I read some stuff last night about how that frequency scaling works.  Apparently the algorithm is very complicated.  Doesn't just see you use the heavy instruction once and snap your frequency down.  It's a gradual thing, so it has to do with what portion of your instruction stream is "high energy."
2023-10-20 16:39:23 <KipIngram   > And it's per core, so if you can segregate your AVX work to one core, the others can still run at full speed.
2023-10-20 18:27:08 <KipIngram   > So, re: AVX and APL style vector processing, APL supports arbitrary size vectors, which will necessarily be in RAM.  Each "chunk" would need to be passed through the AVX hardware, iteratively.
2023-10-20 18:28:10 <KipIngram   > But, if you happen to know you're solving a 3D or 4D problem, like maybe doing something physics related, then you could potentially just keep your "vector top of stack" in the AVX registers, much like we cache our TOS currently.
2023-10-20 18:28:53 <KipIngram   > I.e., we could implemenT a "vector stack," up to 4D (I'm assuming we'd like to use double precision).
2023-10-20 18:29:03 <KipIngram   > Up to 8D single precision.
2023-10-20 18:48:12 <zelgomer    > i've been playing around with a forth in my head. how sacreligious would you consider it if words were tokenized and then compiled rather than compilation occurring the moment a space is encountered after each word?
2023-10-20 18:48:31 <zelgomer    > tokenized and compiled when the semicolon is encountered, i mean
2023-10-20 18:48:37 <zelgomer    > is it no longer forth at that point?
2023-10-20 18:49:07 <zelgomer    > and i'm wondering what ramifications this might bring about that i haven't thought of
2023-10-20 18:52:12 <KipIngram   > I think "Forth" gives you a lot of latitude for experimentation.
2023-10-20 18:52:21 <GeDaMo      > There are optimizing, native code generating Forth compilers
2023-10-20 18:52:39 <KipIngram   > Chuck Moore, Forth's creator, once said that "Forth" basically means "uses a data stack" and "has colon definitions."
2023-10-20 18:52:46 <KipIngram   > That leaves you quite a lot of room to play.
2023-10-20 18:52:54 <KipIngram   > And besides, sacrilige is fun...
2023-10-20 18:53:12 <GeDaMo      > You could have compile, adding each token to a tree or other similar structure and then ; would generate the code
2023-10-20 18:53:31 <KipIngram   > s/sacrilige/sacrilege/
2023-10-20 18:54:25 <zelgomer    > GeDaMo: that's pretty close to where i'm going. the key is still keeping with the spirit of making it simple
2023-10-20 18:56:20 <KipIngram   > zelgomer: I've also spent some time thinking about how to bring a bit more parsing sophistication to Forth.  A driving reason for me is the desire to support more complicated "literals."  If you think about it, Forth already "special cases" literal numbers.
2023-10-20 18:56:33 <KipIngram   > it's just a special test it does after a dictionary search fails.
2023-10-20 18:56:49 <KipIngram   > But that's just one kind of literal.  What about quoted strings, literal lists, literal arrays, etc.?
2023-10-20 18:57:05 <rendar      > there are Forths which use multiple stacks, right? e.g. iirc in the old days floats belonged to a second stack?
2023-10-20 18:57:13 <KipIngram   > They really aren't any "different" conceptually from numbers, except that you can't put one of them into a single stack item.
2023-10-20 18:57:37 <KipIngram   > rendar: Quite a lot of multiple data stack efforts have been made over the years, but none of them ever "caught on."
2023-10-20 18:57:47 <rendar      > why not?
2023-10-20 18:57:55 <KipIngram   > One of Forth's key advantages is that you know precisely where the operands for each operation are.
2023-10-20 18:58:12 <KipIngram   > I.e., the top of the stack.  If there are more than one stack, then you'd have to somehow specify.
2023-10-20 18:58:32 <KipIngram   > They call it "implicit addressing."
2023-10-20 18:58:32 <rendar      > yeah
2023-10-20 18:58:42 <KipIngram   > And it contributes to code compactness.
2023-10-20 18:59:16 <KipIngram   > I think mostly, though, is just that having multiple stacks didn't really provide a lot of advantage - no one ever pointed out a "killer app" for it.
2023-10-20 18:59:16 <GeDaMo      > Normally the words you use would specify which stack they work on e.g. f@ uses an address on the data stack but fetches to the floating point stack
2023-10-20 18:59:26 <KipIngram   > Yes.
2023-10-20 18:59:39 <KipIngram   > That is done fairly often (separate floating point stack).
2023-10-20 18:59:48 <KipIngram   > It make sense when it's always clear what to do.
2023-10-20 19:00:04 <rendar      > wait, nowadays Forth still has a separate floating point stack?!
2023-10-20 19:00:14 <KipIngram   > You can probably find some that do.
2023-10-20 19:00:22 <KipIngram   > There's no universal rule about it.
2023-10-20 19:00:24 <GeDaMo      > I believe gforth does
2023-10-20 19:00:33 <thrig       > you can find some that don't support floats
2023-10-20 19:00:36 <KipIngram   > Well, I shouldn't say that - the standard may have something to say on the topic.
2023-10-20 19:00:48 <rendar      > i see
2023-10-20 19:00:58 <GeDaMo      > https://gforth.org/manual/Stack-Manipulation.html
2023-10-20 19:01:33 <KipIngram   > A big reason it was done that way in the past is because the HARDWARE had a separate floating point stack.  Back when we used the 8087 co-processor.
2023-10-20 19:01:44 <KipIngram   > it had an internal stack, which encouraged people to recognize that stack in Forth.
2023-10-20 19:01:53 <KipIngram   > Only eight items deep, though.
2023-10-20 19:02:26 <KipIngram   > Eight is actually a lot - I got all the way through college with an RPN calculator sporting a four-deep stack.
2023-10-20 19:03:02 <rendar      > yes indeed
2023-10-20 19:03:10 <KipIngram   > It's an interesting little challenge to write a quadratic equation root taker that works completely in a four-item stack.
2023-10-20 19:03:17 <KipIngram   > i.e., uses no "scratch registers."
2023-10-20 19:03:28 <KipIngram   > It's possible, but hard enough to make it interesting.
2023-10-20 19:03:38 <rendar      > heh
2023-10-20 19:03:57 <KipIngram   > Yeah, I'm just such an exciting guy - that's the kind of stuff I spend my time on.  :-)
2023-10-20 19:04:17 <KipIngram   > Drives the ladies crazy...
2023-10-20 19:04:26 <rendar      > KipIngram, i see you as very enthusiast and passionate supporter of Forth, when I'll publish my Forth version, could I link the docs to you, so you can give me some feedback? if you want..
2023-10-20 19:04:43 <KipIngram   > I would be happy to take a looks.
2023-10-20 19:04:47 <rendar      > thanks!
2023-10-20 19:07:00 <KipIngram   > I think what I'm really into is simplicity and absence of "waste."  Forth just exhibits those things, so... I'm a fan.
2023-10-20 19:07:47 <KipIngram   > And also, that calculator I mentioned was the first thin I ever programmed, so my brain got "tuned" to stack machines right from the start.
2023-10-20 19:08:32 <KipIngram   > It was really its RPN operation that first drew me to  Forth - I only appreciated the simplicity and efficiency of it later on, after I'd scratched around under the hood for a while.
2023-10-20 19:15:19 <KipIngram   > Ha!  This conversation ^ got me to thinking about Forth "parsing" in general, and suddenly it occurred to me that my Forth would probably crash if I typed a : alone on a line.
2023-10-20 19:15:32 <KipIngram   > I tried it, and sure enough - adios, folks.  Hung.
2023-10-20 19:16:04 <KipIngram   > What that does is create a new definition for the null word, and then that displaces the old definition and I'm no longer able to "terminate" lines.
2023-10-20 19:16:40 <KipIngram   > It's immediately broken, since I don't have a smudge bit.  That new definition takes effect the minute it's added to the dictionary.
2023-10-20 19:18:22 <KipIngram   > The existing null word basically just executes an rdop exit, which breaks me out of INTERPRET's infinite loop.
2023-10-20 19:19:36 <KipIngram   > I assume that it a) parsed out a null and created a new definition with it, then b) parsed null again, and executed that unterminated definition.
2023-10-20 19:19:55 <KipIngram   > But at any rate, even if it hadn't flown off into never never land, it would have just continued to parse that null otu forever.
2023-10-20 19:20:35 <KipIngram   > My WORD won't advance past a null termination.  If it's begun peeling out a word when it hits null, then that completes that word.  Then subsequent calls to WORD will just return null over and over, forever.
2023-10-20 19:34:00 <KipIngram   > Ok, I think this picture I have in mind for an "improvable" file system is pretty clear now.  It will be immediately usable, but low-ish performance, with hooks that will let me accelerate it with more advanced methods later.
2023-10-20 19:34:19 <KipIngram   > And that low-ish performance version is SIMPLE.
2023-10-20 21:07:21 <KipIngram   > https://www.nature.com/articles/d41586-023-03267-0
2023-10-20 21:07:26 <KipIngram   > Yay team...
2023-10-20 21:08:55 <KipIngram   > Also of interest:
2023-10-20 21:08:57 <KipIngram   > https://www.scientificamerican.com/article/grammar-changes-how-we-see-an-australian-language-shows/
2023-10-20 21:09:16 <KipIngram   > Newspeak, anyone?
2023-10-20 21:15:59 <thrig       > plusgood
2023-10-20 21:29:20 <KipIngram   > Honestly the whole notion of Newspeak struck me as one of the most frightening things I'd ever read, the first time I read 1984.
2023-10-20 21:29:28 <KipIngram   > That's a totally chilling idea.
2023-10-20 21:34:29 <thrig       > orwell did "simple english" translations during The War
2023-10-20 21:34:42 <KipIngram   > Wow - that language article is fascinating.
2023-10-20 21:36:22 <KipIngram   > Totally unrelated, but you mentioned "the war" and it made me think of it.  Johnny Cash, the country music singer, was the first person in the West to know that Stalin had died.  He was a Morse code operator for the Air Force, and was assigned to copying Soviet radio traffic.  He found out that way, and his report was how others in the military found out.