2023-05-28 11:08:33 <KipIngram   > You know, computer science lectures amuse me.  They really go whole hog with the whole "big O" thing; the nonchalance with which they wave off those constant factors is marked.  Ultimately those details DO matter - do they ever get around to actually talking about implementation efficiency?
2023-05-28 11:09:04 <KipIngram   > SOMEONE eventually has to think about those bits.
2023-05-28 11:10:22 <KipIngram   > It's very similar to physicists just tossing out constant factors from equations.  Leonard Susskind is quite bad about that.
2023-05-28 11:17:11 <thrig       > 
ACTION removes * G from a hot loop

2023-05-28 11:57:00 <unjust      > not a computer scientist, but i'm sure nowadays there's a mindset of who cares about implementation efficiency when you can just burn more cash on extra resources from amazon web services when your code starts to crawl
2023-05-28 12:01:03 <KipIngram   > I think that's a pervasive mindset.  The actual efficiency related aspects are just taken for granted.  Someone will provide...
2023-05-28 12:01:46 <KipIngram   > So this is kind of interesting.  The normal approach when starting a system up from the OS would be to have a load effective address instruction to establish "where you are" in RAM when you start executing.
2023-05-28 12:02:11 <KipIngram   > But exactly what that instruction does depends on where you've loaded the image, so it can't be set until runtime.
2023-05-28 12:02:47 <KipIngram   > The way I'm planning this is that I'll use BLOCK to bring the block range holding the image into contiguous buffers, and then will just call the zero offset of the first block.
2023-05-28 12:03:09 <KipIngram   > Which basically means I put that address on the stack and run a primitive that does call <tos reg>.
2023-05-28 12:03:37 <KipIngram   > So when *that* starts up, TOS holds the base address of the load image, so I just use that to get my bearings.  It's the only data available at that point.
2023-05-28 12:03:49 <KipIngram   > So, no lea instruction in this code.
2023-05-28 12:06:27 <KipIngram   > I just recognized that fact and replaced the one lea instruction I had (the very first instruction, and which had been "lea r15, ...") with "mov r15, rcx."
2023-05-28 12:18:17 <KipIngram   > Anyway, this launch code is nominally designed.  Now I need to write a "Forth way" of generating it into blocks and it ought to run - if I stick a ret instruction in it somewhere it should come back.  Then I can start "growing it."
2023-05-28 12:19:13 <KipIngram   > Looks like it only uses seven or eight machine instructions.
2023-05-28 12:19:34 <KipIngram   > So not much "assembler" to write.   But as soon as I start growing it I'll need some more.
2023-05-28 14:42:22 <KipIngram   > I think this turned out to be easier to implement in the startup assembly than in Forth because I've got all those registers to capture various bits of information in, and I can get at any of them instantly without any stack access issues.
2023-05-28 14:44:08 <KipIngram   > I was able to write one routine to do allocation and copy on all four of my primary memory regions, even though those do get different detailed treatment.  The routine runs the "offset-to-address" translation on all of those regions, but in the case of the body and header regions I set the adjustment value to zero, so it negates the effect.  There turned out to be enough registers to handle all that, so it
2023-05-28 14:44:10 <KipIngram   > came out pretty clean.
2023-05-28 14:44:58 <KipIngram   > I want to adjust every cell of the PFA table, but I want to skip over the first bit of the CFA table, so I had a register to parmeterize that as well.
2023-05-28 15:53:44 <drakonis    > unjust: i would say that its a case of being extremely insulated from the need to heavily optimize your code because your language of choice typically does all of the heavy lifting plus being so far away from the hardware that strong optimization is not really possible
2023-05-28 15:56:16 <KipIngram   > I don't think you're insulated from all of the effects.  Consider the case of multidimensional array traversal - the way you choose to do that can have drastic effects on performance by changing the effectiveness of caching.
2023-05-28 15:56:50 <KipIngram   > I think you're right for the most part, though.
2023-05-28 15:57:33 <KipIngram   > I don't think I can really appreciate that perspective very well, though, because the hardware was usually right in my face in most of the work I've done.
2023-05-28 15:57:43 <KipIngram   > I've never really experienced that "bubble."
2023-05-28 16:07:10 <unjust      > drakonis: that makes sense
2023-05-28 16:07:15 <KipIngram   > Maybe you see the same kind of thing in all sorts of areas, like the difference very well-off people vs. people that struggle attach to the value of money, etc.
2023-05-28 16:07:39 <drakonis    > the majortiy of cloud cases, yes.
2023-05-28 16:08:03 <drakonis    > oops
2023-05-28 16:09:06 <KipIngram   > I guess the higher end application that's easiest for me to think about is stuff like numerical simulations, where that array thing would really matter and be frequently encountered.  But now thinking about it imagine real cloud work would probably involve data structures that were quite a bit more "abstract."
2023-05-28 16:09:46 <KipIngram   > Working with an array there's an expectation of certain items being side-by-side, but in other data structures that are list/pointer based, not so much.
2023-05-28 16:13:50 <drakonis    > on the other hand, there are libraries for dealing with multidimensional arrays
2023-05-28 16:14:30 <drakonis    > which work for the vast majority of cases as well
2023-05-28 16:15:53 <drakonis    > blas libraries iirc
2023-05-28 16:15:59 <drakonis    > these come in many forms
2023-05-28 16:19:51 <drakonis    > but to be honest, when you're actually writing software that's expected to run fast, you'll inevitably have to write lower leve code
2023-05-28 16:19:56 <drakonis    > lower level
2023-05-28 16:20:15 <drakonis    > ie: backend software
2023-05-28 16:22:19 <drakonis    > redis is something that's used a lot in the cloud and runs extremely fast
2023-05-28 16:28:24 <drakonis    > so, the need to run extremely fast isnt always needed until they actually have to scale it
2023-05-28 16:28:32 <drakonis    > which, well...
2023-05-28 16:28:47 <KipIngram   > I would guess "extremely fast" has a "context" around it there.
2023-05-28 16:29:19 <drakonis    > basically, being able to serve a large amount of connections with low latency
2023-05-28 16:29:29 <drakonis    > context is indeed valuable
2023-05-28 16:30:48 <KipIngram   > What prompted my comments earlier about CS tendency to not really get into details was a lecture I was watching from an MIT CS course.  It was on persistent data structures, and it just felt like he glossed over more than he explained.
2023-05-28 16:31:09 <drakonis    > so, in other terms, the reason you don't see people caring about performance most of the time is due to having to ship fast
2023-05-28 16:31:15 <drakonis    > something something fake it till you make it
2023-05-28 16:31:26 <KipIngram   > Yeah, it just occurred to me that when I think "fast" it might be nanoseconds.
2023-05-28 16:31:54 <KipIngram   > But then I also work with SSDs, and a fast SSD might have tens of microseconds latency.
2023-05-28 16:33:09 <drakonis    > aye
2023-05-28 16:34:27 <KipIngram   > I watched a Veritasium video a while back on how electricity moves through circuits.  The guy hooked up a battery and a switch to a light.  They were right by each other, but it was a thought experiment, and the idea was that the wire looped out on each side like halfway to the moon.
2023-05-28 16:34:33 <KipIngram   > Obviously we're neglecting resistance here.
2023-05-28 16:34:43 <KipIngram   > The question at hand was how long does it take the light to come on.
2023-05-28 16:35:09 <KipIngram   > And in fact you get some current through the light almost immediately - you don't get a speed of light out to the end and back delay.
2023-05-28 16:35:18 <KipIngram   > Well, you do, but that's only a partial effect.
2023-05-28 16:35:32 <KipIngram   > The point being that the fields in the air around the wire carry important effects.
2023-05-28 16:36:04 <KipIngram   > Those pairs of wire running off into the distance form a transmission line, and it has parasitic capacitances shorted between them.
2023-05-28 16:36:14 <KipIngram   > Some displacement current passes across that way.
2023-05-28 16:36:51 <KipIngram   > In fact, you'd still get some current through the light even if you snipped the wire out at the far ends.
2023-05-28 16:37:14 <KipIngram   > It wouldn't persist, but for a second-ish the setup doesn't  know what the conditions out at the ends are anyway.
2023-05-28 16:38:01 <KipIngram   > Whether it's open or shorted out at the ends, though, affects the type of reflection that happens at those ends, and when that reflection gets back then of course things are totally different in those two cases.
2023-05-28 16:38:49 <KipIngram   > If the ends are shorted the "end condition" is zero voltage; if they're open, it's zero current.  The reflection that appears is whatever it takes to enforce that condition.
2023-05-28 16:40:12 <KipIngram   > Anyway, this video created quite an uproar in the "circuits" community, and provoked a whole slew of response/rebuttal videos.
2023-05-28 16:40:34 <KipIngram   > He wound up making a follow-up to clarify some things and that one included a small-scale physical demo.
2023-05-28 16:40:47 <KipIngram   > Some Caltech professors helped him with that.
2023-05-28 16:43:15 <drakonis    > sounds like an interesting watch
2023-05-28 16:47:50 <drakonis    > there's someone on youtube who's writing an physics engine and using it to simulate motor engines
2023-05-28 16:48:11 <drakonis    > https://github.com/Engine-Simulator/engine-sim-community-edition
2023-05-28 16:55:47 <drakonis    > anyhow!
2023-05-28 16:56:22 <drakonis    > the mismatch between people that have to care about the hardware when writing code and those who don't is real
2023-05-28 16:58:58 <unjust      > time & place + pros & cons for both approaches
2023-05-28 16:59:01 <drakonis    > aye
2023-05-28 16:59:13 <unjust      > it's great to prototype and experiment with new concepts in high level languages
2023-05-28 17:01:06 <drakonis    > although i've been observing that specialized hardware has been making a comeback now that you can no longer depend on cpus for consistent performance gains
2023-05-28 17:01:42 <drakonis    > as these can be lost with a single hardware vulnerability patch
2023-05-28 17:07:00 <unjust      > specialized hardware in terms of accelerators implemented with programmable logic?
2023-05-28 17:08:07 <Zarutian_iPad> 
ACTION mutters something about FPGAs, CPLDs, BitGrid, systolic arrays, and such.

2023-05-28 17:09:03 <unjust      > closedsourcebitstreamolitis
2023-05-28 17:10:20 <Zarutian_iPad> yeah, beside BitGrid and systolic arrays in general Xilinx, Altera, and co do not want to specify their bitstream formats
2023-05-28 17:11:02 <Zarutian_iPad> SymbiFlow and adjenct projects are rectifing that somewhat though
2023-05-28 17:18:11 <drakonis    > unjust: ha, yes.
2023-05-28 17:20:18 <drakonis    > ASICs, but not the cryptofuck ones
2023-05-28 17:21:39 <Zarutian_iPad> drakonis: like the sneakers?
2023-05-28 17:21:45 <drakonis    > if only
2023-05-28 17:23:42 <Zarutian_iPad> just a jokey reference, really good shoes though
2023-05-28 17:24:13 <Zarutian_iPad> but you meant Application Spefic Integrated Circuit, no?
2023-05-28 17:24:24 <drakonis    > yeah, i did.
2023-05-28 17:24:47 <drakonis    > its just that usage of the term ASIC is too closely related to cryptofuckery
2023-05-28 17:25:58 <KipIngram   > https://www.youtube.com/watch?v=bHIhgxav9LY&t=1s
2023-05-28 17:26:10 <KipIngram   > That's the original Veritasium video that started it all.
2023-05-28 17:26:34 <Zarutian_iPad> yeah, the thing is they often used the cheapest option you can get with ASIC design. Which is to use common predesigned macrocells and just design the last or last two metal layers
2023-05-28 17:26:59 <drakonis    > i can see why the video caused controversy
2023-05-28 17:27:02 <drakonis    > what a shitty title
2023-05-28 17:27:08 <KipIngram   > :-)
2023-05-28 17:27:39 <KipIngram   > You mean in the thumbnail?
2023-05-28 17:27:47 <KipIngram   > The actual title is more innocuous.
2023-05-28 17:27:54 <drakonis    > yeh.
2023-05-28 17:28:05 <KipIngram   > But what he's getting at is that the energy actual travels in the fields around the wires.
2023-05-28 17:28:11 <KipIngram   > actually
2023-05-28 17:28:43 <KipIngram   > The wires "steer" the fields.
2023-05-28 17:29:40 <drakonis    > a better title wouldnt have as many clicks, would it?
2023-05-28 17:29:48 <KipIngram   > Right.
2023-05-28 17:30:08 <KipIngram   > I've seen cases far worse, actually; some folks have no shame when it comes to click bait.
2023-05-28 17:31:14 <drakonis    > but with that said, it is nice to know
2023-05-28 17:32:47 <KipIngram   > So, in the example of a coaxial cable (just a nice easy to assess geometry), the fields are between the two conductors.  The magnetic field is circular, going around the central conductor.  The electric field is radial, going straight across between the conductors.
2023-05-28 17:33:09 <KipIngram   > So the cross product of B and E is axial, pointing down the cable.
2023-05-28 17:33:18 <KipIngram   > And that is the Poynting vector, which gives power density.
2023-05-28 17:33:55 <KipIngram   > If you integrate that across the annular ring between the conductors, that's the power flowing down the cable.
2023-05-28 17:34:12 <Zarutian_iPad> and this is why you do not use diaelectric with low magnetic flux permissivity
2023-05-28 17:34:15 <KipIngram   > And in that particular case, you can do all the math on a piece of paper and calculate that exactly.
2023-05-28 17:34:19 <KipIngram   > By hand, I mean.
2023-05-28 17:34:40 <KipIngram   > Right.  More B = more power.
2023-05-28 17:35:06 <drakonis    > i really need to brush up my physics skills
2023-05-28 17:35:11 <KipIngram   > They actually call that permeability for magnetism.
2023-05-28 17:35:11 <drakonis    > i havent seen any of this since high school
2023-05-28 17:35:16 <drakonis    > and that's been a decade ago
2023-05-28 17:35:31 <KipIngram   > It's cool that it all actually works out so  nicely.
2023-05-28 17:37:09 <KipIngram   > The electric permittivity doesn't matter as much - once you know the voltage and the geometry of the coax, E is defined.
2023-05-28 17:37:15 <KipIngram   > Doesn't change with permittivity.
2023-05-28 17:37:27 <KipIngram   > But the current gives you H, and to get to B you need that permeability.
2023-05-28 17:37:41 <thrig       > drakonis: Runge-Kutta seems ready-made for forth-order
2023-05-28 17:38:03 <KipIngram   > RK is like the most straightforward one.
2023-05-28 17:38:19 <KipIngram   > Its main downside is that it's explicit, which makes it subject to some forms of instability.
2023-05-28 17:38:33 <KipIngram   > But it sure is easy to implement.
2023-05-28 17:39:29 <KipIngram   > An "implicit" integrator effectively builds some negative feedback into the calculations, and can tame those instabilities.
2023-05-28 17:40:10 <KipIngram   > In RK the time step needs to be proportional to the smallest eigenvalue of the matrix, or it will explode on you.
2023-05-28 17:40:22 <KipIngram   > And often you don't need a time step anywhere near that small for accuracy.
2023-05-28 18:12:24 <KipIngram   > Anyway, if you take that small time step, you'll see high frequency dynamics governed by that small eigenvalue.  RK will blow up if you exceed that step (in some cases at least).   An implicit integrator will give you the lower frequency stuff with the high frequency behavior averaged over, which in a lot of cases is completely satisfactory.
2023-05-28 18:20:20 <KipIngram   > A system of equations for which the ratio of the largest eigenvalue to the smallest eigenvalue is "big" (whatever you decide qualifies) is called a "stiff" system.
2023-05-28 18:23:28 <KipIngram   > Usually the "natural" way we write the equations of a system wind up giving a set of N coupled differential equations.  But you can do a change of variables in which you replace the original variables with linear combinations of themselves.  There's an infinite number of ways to do this, and for one of them you wind up with N de-coupled single-variable equations, which you can solve and study individually.
2023-05-28 18:23:30 <KipIngram   > In that particular version, the matrix involved is diagonalized and has the eigenvalues along the main diagonal (and zero everywhere else).
2023-05-28 18:24:08 <KipIngram   > Then if you wanted to you could solve that system and go back to the original variable set, and you'd wind up with the right answer.
2023-05-28 18:26:32 <KipIngram   > You can do that in any kind of system - in stress/strain problems they call the axes that lead to that decoupled set of equations the "principle axes."
2023-05-28 18:27:55 <KipIngram   > Has to do with how energy is deployed in the system - each of those "new variables" is called a mode and anytime you excite the system you're putting a certain amount of energy in each mode, and it doesn't move around.  Stays where you put it.
2023-05-28 18:31:06 <KipIngram   > I'm sorry - no principle axes.  Principle directions.
2023-05-28 18:31:38 <KipIngram   > In those directions an applied stress will create strain that's parallel.
2023-05-28 18:32:11 <KipIngram   > And usually the stress/strain ratio is different for at least some of them.
2023-05-28 18:32:23 <KipIngram   > Has to do with the crystal structure of the material.
2023-05-28 18:32:58 <KipIngram   > In other directions an applied stress can cause a strain in a different direction.
2023-05-28 19:57:47 <thrig       > shocking reports of quartz following asteroid strike!