• mushroommunk@lemmy.today
    link
    fedilink
    arrow-up
    40
    ·
    2 days ago

    Depends on the available memory and size of the tables. I’ve worked on cases where time to compute didn’t matter as much as shaving off three more bytes did. Large lookup tables would have absolutely killed us compared to running some math.

    • baines@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      1
      ·
      17 hours ago

      not doubting you because the customer can be funny but wha?

      if time to compute doesnt matter there are likely more minimal hardware options to optimize for look up tables and memory cost/space

      • mushroommunk@lemmy.today
        link
        fedilink
        arrow-up
        1
        ·
        16 hours ago

        There are so many situations where you can’t just swap hardware. Robots on an assembly line? Yeah you’ve gotta use hardware that’s gone through safety testing. They’re not going to just swap hardware to make things easier. You want to ship an update, you do it in software and under strict testing regiment. Some of that hardware is 20 or 30 years old. Medical. Aeronautics. Aerospace. All of them and more are using older hardware that’s often memory limited but can often just sit and process their next step, and they often don’t have built in complex hardware features because those add potential failure points.

        • baines@lemmy.cafe
          link
          fedilink
          English
          arrow-up
          1
          ·
          16 hours ago

          the hang up for me is more the not caring about time to compute

          aeroish is my experience, and for me those have all cared about time to compute

          generally that’s one of the biggest constraints to the point of being super strict

          like major money being spent on modeled approximations and processing speed costs eclipsing pretty much everything on the design side

          tables for weather, angles, altitude, position this would be tiny compared to some we’re using

          30 year old equipment is even more taxed given the likely feature creep in my experience

          • mushroommunk@lemmy.today
            link
            fedilink
            arrow-up
            2
            ·
            16 hours ago

            I’m guessing you were doing in flight aero stuff? I’ve been more in the medical and manufacturing space but the aero I did we were doing post-flight processing for reports. We had almost no memory to operate on, probably because of all the tables you’re referencing that others were using.

    • henfredemars@infosec.pub
      link
      fedilink
      English
      arrow-up
      15
      ·
      2 days ago

      Good point! Good point.

      I’ve seen bubble sort implemented because we had data that said it was faster and was slightly smaller for the exact type data we were sorting and its expected distribution.

      • disorderly@lemmy.world
        link
        fedilink
        arrow-up
        22
        ·
        2 days ago

        I fondly remember the time I hired a QT expert onto an embedded app team and on his first project he imported a sort algorithm from std. He found the system got weird and glitchy, and often crashed.

        Yeahhh turns out the algorithm he chose needed to make a copy in memory and the thread he was working in only had 2048 bytes of stack, so larger inputs would corrupt the stack allocated to the next thread. I had to explain to him that we had a full second to complete the math before we had to give back our semaphore, so saving a couple milliseconds on the sort was not a priority. Fun times.