On a sunny day (Fri, 01 Oct 2021 14:44:17 +0200) it happened Jeroen Belleman <jeroen@nospam.please> wrote in <sj6vr2$10lp$1@gioia.aioe.org>:>On 2021-10-01 12:56, Don Y wrote: >> On 10/1/2021 3:04 AM, Jeroen Belleman wrote: >>> There's also Wirth's observation: "Software gets slower faster >>> than hardware gets faster." >> >> You've got to have a bit of sympathy for folks who write desktop >> applications; they have virtually no control over the environment >> in which their code executes. >> >[Snip!] > >Just last week, I rebooted a Linux machine that I set up >20 years ago, and which had been sleeping in the attic. >It's actually much snappier than my newest machine. > >Software *is* getting more and more bloated, and I don't >really have the impression that the functionality is >there to justify it. Mostly we are irritated by the addition >of pointless animations and snazzy effects. There is >something rotten in the state of modern software. > >Jeroen BellemanI have a modern PC with all sorts of cards in it, One day I tested my new 2kW water cooker, the PC crashed due to the mains dip it caused, and messed up the harddisk. put some new Debian OS on it but somehow it sucked, So it is off now and have not yet missed it. Now I use a 15 years old top of the line PC running 'grml' (a special Linux version for sysadm) for PIC programming, sat TV, all sorts of programs I wrote and everything works. But for normal web stuff and reading Usenet I use my Samsung laptop with ~ # uname -a Linux panteltje20 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 Intel(R) Core(TM) i5 So Slackware Linux installed in 2011. But the old Seamonkey browser has more and more problems with some sites,,, So next to it I have 4 Raspberry Pis, 2 are version 4, one has 4GB and one 8GB RAM. takes a fraction of the power of a big PC, has several rtl_sdr USB sticks for for example spectrum analyzer, AIS reception, planes, weather sensor, radio, etc and uses Chrome browser and is lightning fast, A second raspi 4 is almost 100% backup. One raspi works as gateway, has a 4G USB stick in it. The Pi4s each have a 3.5 TB USB harddisks connected to it. All on a UPS, works several minutes when power fails. Maybe the time for the big PCs is over... Not even a fan in the 8GB Pi4, have one in the 4GB version. HDMI switch with remote to switch the monitor between the PIs and other stuff here... Or simply access the Pis via ssh from the laptop via the wired LAN. Quite a bit of computer power And all the PIC stuff I wrote is also connected, you can acces anything from anywhere radiation counter .. room lights, room music (even via IR remote), security cams etc etc.
new spice
Started by ●September 28, 2021
Reply by ●October 1, 20212021-10-01
Reply by ●October 1, 20212021-10-01
On a sunny day (Fri, 1 Oct 2021 09:05:31 -0400) it happened Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in <95332466-d835-f22c-a8f3-dfc5cd15d1a7@electrooptical.net>:>Jeroen Belleman wrote: >> On 2021-10-01 14:11, Gerhard Hoffmann wrote: >>> Am 01.10.21 um 12:04 schrieb Jeroen Belleman: >>> >>> >>>> There's also Wirth's observation: "Software gets slower faster >>>> than hardware gets faster." >>> >>> When asked how his name should be pronounced he said: >>> >>> "You can call me by name: that's Wirth >>> or you can call me by value: that's worth" >>> >>> >>> >> Cheers, Gerhard >> >> I still don't get why C++ had to add call by reference. Big >> mistake, in my view. >> >> Jeroen Belleman > >Why? Smart pointers didn't exist in 1998 iirc, and reducing the number >of bare pointers getting passed around has to be a good thing, surely?C++ is a crime against humanity. New languages are created almost daily because people are not willing to learn about the hardware and what really happens. Snake language (phyton) is just an other example. Pointers is easy in C. Yes, mistakes are possible but use brain!. Takes less time to learn to code in ASM or C than learning the latest crap language and being forced to use its either missing or crap libraries. Bloat sells it seems, and bloat writers sell themselves. 'Learn to be a web developer in 14 days' I have seen advertised. The essence is that if you do not know how to solve a problem, then no matter how much bloat you throw at it the problem will not go away. <although with AI and neural nets it will do the guessing for you ;-)>
Reply by ●October 1, 20212021-10-01
On Fri, 1 Oct 2021 08:55:01 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>Gerhard Hoffmann wrote: >> Am 30.09.21 um 21:24 schrieb John Larkin: >>> On Thu, 30 Sep 2021 19:58:50 +0100, "Kevin Aylward" >>> <kevinRemoveandReplaceATkevinaylward.co.uk> wrote: >>> >>>>> "John Larkin"� wrote in message >>>>> news:bdc7lgdap8o66j8m92ullph1nojbg9c5ni@4ax.com... >>>> >>>>> https://www.linkedin.com/in/mike-engelhardt-a788a822 >>>> >>>> ...but why ......? >>>> >>> >>> Maybe he enjoys it. I'm sure he's enormously wealthy and could do >>> anything he wahts. >>> >>> I want a Spice that uses an nvidia board to speed it up 1000:1. >>> >> >> Hopeless. That has already been tried in IBM AT times with these >> Weitek coprocessors and NS 32032 processor boards; it never lived >> up to the expectations. > >Parallellizing sparse matrix computation is an area of active research. >The best approach ATM seems to be runtime profiling that generates a >JIT-compiled FPGA image for the actual crunching, sort of like the way >FFTW generates optimum FFT routines. > >> >> That's no wonder. When in time domain integration the next result >> depends on the current value and maybe a few in the past, you cannot >> compute more future timesteps in parallel. Maybe some speculative >> versions in parallel and then selecting the best. But that is no >> work for 1000 processors. > >SPICE isn't a bad application for parallellism, if you can figure out >how to do it--you wouldn't bother for trivial things, where the run >times are less than 30s or so, but for longer calculations the profiling >would be a small part of the work. The inner loop is time-stepping the >same matrix topology all the time (though the coefficients change with >the time step). > >Since all that horsepower would be spending most of its time waiting for >us to dork the circuit and dink the fonts, it could be running the >profiling in the background during editing. You might get 100x speedup >that way, ISTM. > >> >> The inversion of the nodal matrix might use some improvement since >> it is NP complete, like almost everything that is interesting. > >Matrix inversion is NP-complete? Since when? It's actually not even >cubic, asymptotically--the lowest-known complexity bound is less than >O(N**2.4). > >> Its size grows with the number of nodes and the matrix is sparse since >> most nodes have no interaction. Dividing the circuit into subcircuits, >> solving these separately and combining the results could provide >> a speedup, for problems with many nodes. That would be a MAJOR change. >> >> Spice has not made much progress since Berkeley is no longer involved. >> Some people make some local improvements and when they lose interest >> after 15 years their improvements die. There is no one to integrate >> that stuff in one open official version. Maybe NGspice comes closest. >> >> Keysight ADS has on option to run it on a bunch of workstations but >> that helps probably most for electromagnetics which has not much >> in common with spice. >> > >It has more than you might think. EM simulators basically have to loop >over all of main memory twice per time step, and all the computational >boundaries have to be kept time-coherent. With low-latency >interconnects and an OS with a thread scheduler that isn't completely >brain-dead (i.e. anything except Linux AFAICT), my EM code scales within >20% or so of linearly up to 15 compute nodes, which is as far as I've >tried. > >So I'm more optimistic than you, if still rather less than JL. ;) > >Cheers > >Phil HobbsSince a schematic has a finite number of nodes, why not have one CPU per node? The sim would run as slow as the slowest node, but that could be fudged some too. -- Father Brown's figure remained quite dark and still; but in that instant he had lost his head. His head was always most valuable when he had lost it.
Reply by ●October 1, 20212021-10-01
Tom Gardner wrote:> On 01/10/21 14:05, Phil Hobbs wrote: >> Jeroen Belleman wrote: >>> On 2021-10-01 14:11, Gerhard Hoffmann wrote: >>>> Am 01.10.21 um 12:04 schrieb Jeroen Belleman: >>>> >>>> >>>>> There's also Wirth's observation: "Software gets slower >>>>> faster than hardware gets faster." >>>> >>>> When asked how his name should be pronounced he said: >>>> >>>> "You can call me by name: that's Wirth or you can call me by >>>> value: that's worth" >>>> >>>> >>>>>> Cheers, Gerhard >>> >>> I still don't get why C++ had to add call by reference. Big >>> mistake, in my view. >>> >>> Jeroen Belleman >> >> Why? Smart pointers didn't exist in 1998 iirc, and reducing the >> number of bare pointers getting passed around has to be a good >> thing, surely? > > "Smart pointer" is a much older concept given a new name.Hmm, interesting. Got a link? You sort of need destructors to make smart pointers work properly.> Why? Either because newbies triumphantly (but unwittingly) reinvented > the wheel, or because a marketeer wanted to make their product sound > new/shiny.Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●October 1, 20212021-10-01
jlarkin@highlandsniptechnology.com wrote:> On Fri, 1 Oct 2021 08:55:01 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> Gerhard Hoffmann wrote: >>> Am 30.09.21 um 21:24 schrieb John Larkin: >>>> On Thu, 30 Sep 2021 19:58:50 +0100, "Kevin Aylward" >>>> <kevinRemoveandReplaceATkevinaylward.co.uk> wrote: >>>> >>>>>> "John Larkin" wrote in message >>>>>> news:bdc7lgdap8o66j8m92ullph1nojbg9c5ni@4ax.com... >>>>> >>>>>> https://www.linkedin.com/in/mike-engelhardt-a788a822 >>>>> >>>>> ...but why ......? >>>>> >>>> >>>> Maybe he enjoys it. I'm sure he's enormously wealthy and could do >>>> anything he wahts. >>>> >>>> I want a Spice that uses an nvidia board to speed it up 1000:1. >>>> >>> >>> Hopeless. That has already been tried in IBM AT times with these >>> Weitek coprocessors and NS 32032 processor boards; it never lived >>> up to the expectations. >> >> Parallellizing sparse matrix computation is an area of active research. >> The best approach ATM seems to be runtime profiling that generates a >> JIT-compiled FPGA image for the actual crunching, sort of like the way >> FFTW generates optimum FFT routines. >> >>> >>> That's no wonder. When in time domain integration the next result >>> depends on the current value and maybe a few in the past, you cannot >>> compute more future timesteps in parallel. Maybe some speculative >>> versions in parallel and then selecting the best. But that is no >>> work for 1000 processors. >> >> SPICE isn't a bad application for parallellism, if you can figure out >> how to do it--you wouldn't bother for trivial things, where the run >> times are less than 30s or so, but for longer calculations the profiling >> would be a small part of the work. The inner loop is time-stepping the >> same matrix topology all the time (though the coefficients change with >> the time step). >> >> Since all that horsepower would be spending most of its time waiting for >> us to dork the circuit and dink the fonts, it could be running the >> profiling in the background during editing. You might get 100x speedup >> that way, ISTM. >> >>> >>> The inversion of the nodal matrix might use some improvement since >>> it is NP complete, like almost everything that is interesting. >> >> Matrix inversion is NP-complete? Since when? It's actually not even >> cubic, asymptotically--the lowest-known complexity bound is less than >> O(N**2.4). >> >>> Its size grows with the number of nodes and the matrix is sparse since >>> most nodes have no interaction. Dividing the circuit into subcircuits, >>> solving these separately and combining the results could provide >>> a speedup, for problems with many nodes. That would be a MAJOR change. >>> >>> Spice has not made much progress since Berkeley is no longer involved. >>> Some people make some local improvements and when they lose interest >>> after 15 years their improvements die. There is no one to integrate >>> that stuff in one open official version. Maybe NGspice comes closest. >>> >>> Keysight ADS has on option to run it on a bunch of workstations but >>> that helps probably most for electromagnetics which has not much >>> in common with spice. >>> >> >> It has more than you might think. EM simulators basically have to loop >> over all of main memory twice per time step, and all the computational >> boundaries have to be kept time-coherent. With low-latency >> interconnects and an OS with a thread scheduler that isn't completely >> brain-dead (i.e. anything except Linux AFAICT), my EM code scales within >> 20% or so of linearly up to 15 compute nodes, which is as far as I've >> tried. >> >> So I'm more optimistic than you, if still rather less than JL. ;) >> >> Cheers >> >> Phil Hobbs > > Since a schematic has a finite number of nodes, why not have one CPU > per node?Doing what, exactly? Given that the circuit topology forms an irregular sparse matrix, there would be a gigantic communication bottleneck in general. Somebody has to decide on the size of the next time step, for instance, which is a global property that has to be properly disseminated after computation. I can't see a good way to do those things other than SMP, which has well-known scaling issues due to cache coherence traffic going as some highish power of the number of cores. The JIT-compiled FPGA approach handles that pretty well AFAICT, as long as there aren't some limited communications resources that get used up too fast. (I don't know very much about the guts of high-end FPGAs.)> > The sim would run as slow as the slowest node, but that could be > fudged some too.Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●October 1, 20212021-10-01
On 01/10/21 15:46, Phil Hobbs wrote:> Tom Gardner wrote: >> On 01/10/21 14:05, Phil Hobbs wrote: >>> Jeroen Belleman wrote: >>>> On 2021-10-01 14:11, Gerhard Hoffmann wrote: >>>>> Am 01.10.21 um 12:04 schrieb Jeroen Belleman: >>>>> >>>>> >>>>>> There's also Wirth's observation: "Software gets slower >>>>>> faster than hardware gets faster." >>>>> >>>>> When asked how his name should be pronounced he said: >>>>> >>>>> "You can call me by name: that's Wirth or you can call me by >>>>> value: that's worth" >>>>> >>>>> >>>>>>> Cheers, Gerhard >>>> >>>> I still don't get why C++ had to add call by reference. Big mistake, in my >>>> view. >>>> >>>> Jeroen Belleman >>> >>> Why? Smart pointers didn't exist in 1998 iirc, and reducing the number of >>> bare pointers getting passed around has to be a good >>> thing, surely? >> >> "Smart pointer" is a much older concept given a new name. > > Hmm, interesting. Got a link? You sort of need destructors to make > smart pointers work properly.No, I don't have a specific link. I'm not thinking of anything that had specific built-in compiler support, but which was implemented by library or environment support. That implied it was application specific based on a programming convention. In a similar vein, I found I had triumphantly invented a primitive form of OOP for a realtime project. When I later used OOP terminology to explain the concepts, people readily understood it (and its limitations). I'll add a standard dig, which is overstated but contains more than a little validity.... If you look at academic papers on C++ (and to a lesser extent C), they refer to other C++/C papers. If you look at academic papers on other languages, they refer to many different languages. In other words, the C/C++ academic community has less awareness of other communities and their progress. If being really snarky I'd attribute that to the C/C++ community having to allocate their brainpower to problems that are a consequence of their tools' characteristics and historic choices.>> Why? Either because newbies triumphantly (but unwittingly) reinvented >> the wheel, or because a marketeer wanted to make their product sound >> new/shiny.
Reply by ●October 1, 20212021-10-01
Tom Gardner wrote:> On 01/10/21 15:46, Phil Hobbs wrote: >> Tom Gardner wrote: >>> On 01/10/21 14:05, Phil Hobbs wrote: >>>> Jeroen Belleman wrote: >>>>> On 2021-10-01 14:11, Gerhard Hoffmann wrote: >>>>>> Am 01.10.21 um 12:04 schrieb Jeroen Belleman: >>>>>> >>>>>> >>>>>>> There's also Wirth's observation: "Software gets slower >>>>>>> faster than hardware gets faster." >>>>>> >>>>>> When asked how his name should be pronounced he said: >>>>>> >>>>>> "You can call me by name: that's Wirth or you can call me by >>>>>> value: that's worth" >>>>>> >>>>>> >>>>>>>> Cheers, Gerhard >>>>> >>>>> I still don't get why C++ had to add call by reference. Big >>>>> mistake, in my view. >>>>> >>>>> Jeroen Belleman >>>> >>>> Why? Smart pointers didn't exist in 1998 iirc, and reducing the >>>> number of bare pointers getting passed around has to be a good >>>> thing, surely? >>> >>> "Smart pointer" is a much older concept given a new name. >> >> Hmm, interesting. Got a link? You sort of need destructors to make >> smart pointers work properly. > > No, I don't have a specific link. > > I'm not thinking of anything that had specific built-in > compiler support, but which was implemented by library > or environment support. That implied it was application > specific based on a programming convention.Okay, it _could_ have been implemented way back, sure. Cfront had destructors--it's all a matter of bookkeeping, and could have been done in Algol, I expect. I'm not aware of anybody having actually done it, and apparently you aren't either.> > In a similar vein, I found I had triumphantly invented > a primitive form of OOP for a realtime project. When I > later used OOP terminology to explain the concepts, people > readily understood it (and its limitations).Sure, OOP is a tool, like a Crescent wrench (adjustable spanner OYSOTP). It's a particularly well suited tool for most of the programming I do--simulators, embedded stuff, and instrument control--so I like it a lot. (Other stuff is mostly scripts, for which I generally use Rexx. Rexx isn't fussy about tabs v. spaces and doesn't change the meaning of a program when it's reformatted. Could use more library support, though.)> I'll add a standard dig, which is overstated but contains > more than a little validity.... > > If you look at academic papers on C++ (and to a lesser > extent C), they refer to other C++/C papers. If you look > at academic papers on other languages, they refer to many > different languages. In other words, the C/C++ academic > community has less awareness of other communities and their > progress. > > If being really snarky I'd attribute that to the C/C++ > community having to allocate their brainpower to problems > that are a consequence of their tools' characteristics and > historic choices.But you wouldn't do such a thing, of course. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●October 1, 20212021-10-01
Jan Panteltje wrote:> On a sunny day (Fri, 1 Oct 2021 09:05:31 -0400) it happened Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote in > <95332466-d835-f22c-a8f3-dfc5cd15d1a7@electrooptical.net>: > >> Jeroen Belleman wrote: >>> On 2021-10-01 14:11, Gerhard Hoffmann wrote: >>>> Am 01.10.21 um 12:04 schrieb Jeroen Belleman: >>>> >>>> >>>>> There's also Wirth's observation: "Software gets slower faster >>>>> than hardware gets faster." >>>> >>>> When asked how his name should be pronounced he said: >>>> >>>> "You can call me by name: that's Wirth >>>> or you can call me by value: that's worth" >>>> >>>> >>>> >> Cheers, Gerhard >>> >>> I still don't get why C++ had to add call by reference. Big >>> mistake, in my view. >>> >>> Jeroen Belleman >> >> Why? Smart pointers didn't exist in 1998 iirc, and reducing the number >> of bare pointers getting passed around has to be a good thing, surely? > > C++ is a crime against humanity. > > New languages are created almost daily because people are not willing to learn about the hardware > and what really happens.I sort of doubt that you or anyone on this group actually knows "what really happens" when a 2021-vintage compiler maps your source code onto 2010s or 2020s-vintage hardware. See Chisnall's classic 2018 paper, "C is not a low-level language. Your computer is not a fast PDP-11." <https://dl.acm.org/doi/abs/10.1145/3212477.3212479> It's far from a straightforward process.> Snake language (phyton) is just an other example. > > Pointers is easy in C. > Yes, mistakes are possible but use brain!. > Takes less time to learn to code in ASM or C than learning the latest crap language > and being forced to use its either missing or crap libraries. > Bloat sells it seems, and bloat writers sell themselves. > 'Learn to be a web developer in 14 days' I have seen advertised. > > The essence is that if you do not know how to solve a problem, > then no matter how much bloat you throw at it the problem will not go away.Whoa, there, Jan. I know you've been trying to round the Cape of Good Hope for a good couple hundred years now, which must be very distracting, but what we were talking about was references vs. pointers. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●October 1, 20212021-10-01
On Fri, 1 Oct 2021 11:07:48 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>jlarkin@highlandsniptechnology.com wrote: >> On Fri, 1 Oct 2021 08:55:01 -0400, Phil Hobbs >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>> Gerhard Hoffmann wrote: >>>> Am 30.09.21 um 21:24 schrieb John Larkin: >>>>> On Thu, 30 Sep 2021 19:58:50 +0100, "Kevin Aylward" >>>>> <kevinRemoveandReplaceATkevinaylward.co.uk> wrote: >>>>> >>>>>>> "John Larkin"� wrote in message >>>>>>> news:bdc7lgdap8o66j8m92ullph1nojbg9c5ni@4ax.com... >>>>>> >>>>>>> https://www.linkedin.com/in/mike-engelhardt-a788a822 >>>>>> >>>>>> ...but why ......? >>>>>> >>>>> >>>>> Maybe he enjoys it. I'm sure he's enormously wealthy and could do >>>>> anything he wahts. >>>>> >>>>> I want a Spice that uses an nvidia board to speed it up 1000:1. >>>>> >>>> >>>> Hopeless. That has already been tried in IBM AT times with these >>>> Weitek coprocessors and NS 32032 processor boards; it never lived >>>> up to the expectations. >>> >>> Parallellizing sparse matrix computation is an area of active research. >>> The best approach ATM seems to be runtime profiling that generates a >>> JIT-compiled FPGA image for the actual crunching, sort of like the way >>> FFTW generates optimum FFT routines. >>> >>>> >>>> That's no wonder. When in time domain integration the next result >>>> depends on the current value and maybe a few in the past, you cannot >>>> compute more future timesteps in parallel. Maybe some speculative >>>> versions in parallel and then selecting the best. But that is no >>>> work for 1000 processors. >>> >>> SPICE isn't a bad application for parallellism, if you can figure out >>> how to do it--you wouldn't bother for trivial things, where the run >>> times are less than 30s or so, but for longer calculations the profiling >>> would be a small part of the work. The inner loop is time-stepping the >>> same matrix topology all the time (though the coefficients change with >>> the time step). >>> >>> Since all that horsepower would be spending most of its time waiting for >>> us to dork the circuit and dink the fonts, it could be running the >>> profiling in the background during editing. You might get 100x speedup >>> that way, ISTM. >>> >>>> >>>> The inversion of the nodal matrix might use some improvement since >>>> it is NP complete, like almost everything that is interesting. >>> >>> Matrix inversion is NP-complete? Since when? It's actually not even >>> cubic, asymptotically--the lowest-known complexity bound is less than >>> O(N**2.4). >>> >>>> Its size grows with the number of nodes and the matrix is sparse since >>>> most nodes have no interaction. Dividing the circuit into subcircuits, >>>> solving these separately and combining the results could provide >>>> a speedup, for problems with many nodes. That would be a MAJOR change. >>>> >>>> Spice has not made much progress since Berkeley is no longer involved. >>>> Some people make some local improvements and when they lose interest >>>> after 15 years their improvements die. There is no one to integrate >>>> that stuff in one open official version. Maybe NGspice comes closest. >>>> >>>> Keysight ADS has on option to run it on a bunch of workstations but >>>> that helps probably most for electromagnetics which has not much >>>> in common with spice. >>>> >>> >>> It has more than you might think. EM simulators basically have to loop >>> over all of main memory twice per time step, and all the computational >>> boundaries have to be kept time-coherent. With low-latency >>> interconnects and an OS with a thread scheduler that isn't completely >>> brain-dead (i.e. anything except Linux AFAICT), my EM code scales within >>> 20% or so of linearly up to 15 compute nodes, which is as far as I've >>> tried. >>> >>> So I'm more optimistic than you, if still rather less than JL. ;) >>> >>> Cheers >>> >>> Phil Hobbs >> >> Since a schematic has a finite number of nodes, why not have one CPU >> per node? > >Doing what, exactly?Computing the node voltage for the next time step.>Given that the circuit topology forms an irregular >sparse matrix, there would be a gigantic communication bottleneck in >general.Shared ram. Most nodes only need to see a few neighbors, plainly visible on the schematic. The ram memory map could be clever that way.>Somebody has to decide on the size of the next time step, for >instance, which is a global property that has to be properly >disseminated after computation.Step when the slowest CPU is done processing its node. -- Father Brown's figure remained quite dark and still; but in that instant he had lost his head. His head was always most valuable when he had lost it.
Reply by ●October 1, 20212021-10-01
jlarkin@highlandsniptechnology.com wrote:> On Fri, 1 Oct 2021 11:07:48 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> jlarkin@highlandsniptechnology.com wrote: >>> On Fri, 1 Oct 2021 08:55:01 -0400, Phil Hobbs >>> <pcdhSpamMeSenseless@electrooptical.net> wrote: >>> >>>> Gerhard Hoffmann wrote: >>>>> Am 30.09.21 um 21:24 schrieb John Larkin: >>>>>> On Thu, 30 Sep 2021 19:58:50 +0100, "Kevin Aylward" >>>>>> <kevinRemoveandReplaceATkevinaylward.co.uk> wrote: >>>>>> >>>>>>>> "John Larkin" wrote in message >>>>>>>> news:bdc7lgdap8o66j8m92ullph1nojbg9c5ni@4ax.com... >>>>>>> >>>>>>>> https://www.linkedin.com/in/mike-engelhardt-a788a822 >>>>>>> >>>>>>> ...but why ......? >>>>>>> >>>>>> >>>>>> Maybe he enjoys it. I'm sure he's enormously wealthy and could do >>>>>> anything he wahts. >>>>>> >>>>>> I want a Spice that uses an nvidia board to speed it up 1000:1. >>>>>> >>>>> >>>>> Hopeless. That has already been tried in IBM AT times with these >>>>> Weitek coprocessors and NS 32032 processor boards; it never lived >>>>> up to the expectations. >>>> >>>> Parallellizing sparse matrix computation is an area of active research. >>>> The best approach ATM seems to be runtime profiling that generates a >>>> JIT-compiled FPGA image for the actual crunching, sort of like the way >>>> FFTW generates optimum FFT routines. >>>> >>>>> >>>>> That's no wonder. When in time domain integration the next result >>>>> depends on the current value and maybe a few in the past, you cannot >>>>> compute more future timesteps in parallel. Maybe some speculative >>>>> versions in parallel and then selecting the best. But that is no >>>>> work for 1000 processors. >>>> >>>> SPICE isn't a bad application for parallellism, if you can figure out >>>> how to do it--you wouldn't bother for trivial things, where the run >>>> times are less than 30s or so, but for longer calculations the profiling >>>> would be a small part of the work. The inner loop is time-stepping the >>>> same matrix topology all the time (though the coefficients change with >>>> the time step). >>>> >>>> Since all that horsepower would be spending most of its time waiting for >>>> us to dork the circuit and dink the fonts, it could be running the >>>> profiling in the background during editing. You might get 100x speedup >>>> that way, ISTM. >>>> >>>>> >>>>> The inversion of the nodal matrix might use some improvement since >>>>> it is NP complete, like almost everything that is interesting. >>>> >>>> Matrix inversion is NP-complete? Since when? It's actually not even >>>> cubic, asymptotically--the lowest-known complexity bound is less than >>>> O(N**2.4). >>>> >>>>> Its size grows with the number of nodes and the matrix is sparse since >>>>> most nodes have no interaction. Dividing the circuit into subcircuits, >>>>> solving these separately and combining the results could provide >>>>> a speedup, for problems with many nodes. That would be a MAJOR change. >>>>> >>>>> Spice has not made much progress since Berkeley is no longer involved. >>>>> Some people make some local improvements and when they lose interest >>>>> after 15 years their improvements die. There is no one to integrate >>>>> that stuff in one open official version. Maybe NGspice comes closest. >>>>> >>>>> Keysight ADS has on option to run it on a bunch of workstations but >>>>> that helps probably most for electromagnetics which has not much >>>>> in common with spice. >>>>> >>>> >>>> It has more than you might think. EM simulators basically have to loop >>>> over all of main memory twice per time step, and all the computational >>>> boundaries have to be kept time-coherent. With low-latency >>>> interconnects and an OS with a thread scheduler that isn't completely >>>> brain-dead (i.e. anything except Linux AFAICT), my EM code scales within >>>> 20% or so of linearly up to 15 compute nodes, which is as far as I've >>>> tried. >>>> >>>> So I'm more optimistic than you, if still rather less than JL. ;) >>>> >>>> Cheers >>>> >>>> Phil Hobbs >>> >>> Since a schematic has a finite number of nodes, why not have one CPU >>> per node? >> >> Doing what, exactly? > > Computing the node voltage for the next time step.Right, but exactly how?> >> Given that the circuit topology forms an irregular >> sparse matrix, there would be a gigantic communication bottleneck in >> general. > > Shared ram. Most nodes only need to see a few neighbors, plainly > visible on the schematic."Shared ram" is all virtual, though--you don't have N-port memory really. It has to be connected somehow, and all the caches kept coherent. That causes communications traffic that grows very rapidly with the number of cores--about N**4 if it's done in symmetrical (SMP) fashion.> The ram memory map could be clever that way.Sure, that's what the JIT FPGA approach does, but the memory layout doesn't solve the communications bottleneck with a normal CPU or GPU.>> Somebody has to decide on the size of the next time step, for >> instance, which is a global property that has to be properly >> disseminated after computation. > > Step when the slowest CPU is done processing its node.But then it has to decide what to do next. The coefficients of the next iteration depend on the global time step, so there's no purely node-local method for doing adaptive step size. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
