Announcement

Collapse
No announcement yet.

Glibc 2.29 Released With getcpu() On Linux, New Optimizations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by lkundrak View Post

    Sorry to say so, but you managed to embarrass yourself by forgetting to attach a patch to your strong words.
    If you knew how many times people have tried posting/discussing different optimizations you wouldn't have opened the obviously overfed pie hole, mr. meat sack.
    I made the comment for bloody obvious reasons.
    We can have the discussion about the PPC typical mem backend and how glibc under-uses it. Or you can just google?
    I had to dump glibc memcpy/memmove several times on PPC for performance sensitive apps to run replacement asm functions.

    Comment


    • #12
      Originally posted by arjan_intel View Post
      it's statistically not horrible, meaning if you want to use it as an index into, say, an array of "mostly per cpu" structures, you'll get 95% or even 99% or more the "right" answer, and if the cost of being wrong is just a few cache misses/etc (e.g. performance) then that can be a very valid use of this
      few cache misses seem less expensive than syscall

      Comment


      • #13
        Originally posted by pal666 View Post
        few cache misses seem less expensive than syscall
        it'll be a vsyscall on many systems... and a syscall is maybe 100 to 200 cycles (depends on cpu); cache miss can be more

        Comment


        • #14
          Originally posted by cybertraveler View Post
          The mention of the C-SKY 32 bit CPU got me wondering: why aren't more low-power CPUs intended for use in embedded systems, portable systems or SBCs (like the Raspberry Pi), 32 bit only?[/LIST]There's some interesting words about how the Nintendo 64, 64 bit CPU was used here:

          https://en.wikipedia.org/wiki/Ninten...rocessing_unit

          The claim is, it was mostly used in 32 bit mode for the very reasons I would expect.
          Nintendo 64 from 1996, 23 years ago.. what was true of hardware in 1996 is not true now. Compare average ram capacity for example.

          I have a real world example comparing 64bit operations to 32bit operations running MyCroft voice assistant.

          <pre>
          ***** 64bit pi 3b 1.2GHz
          ~16% cpu usage waiting for command
          344M used
          5 min load 0.60
          ***** 32bit pi 3b 1.2GHz
          ~23% cpu usage waiting for command
          267M used
          5 min load 0.82
          So yes, 64bit does have a performance advantage…and the memory footprint is within the capabilities of the Pi 3A+.
          </pre>

          Comment


          • #15
            Originally posted by cbxbiker61 View Post
            So yes, 64bit does have a performance advantage…and the memory footprint is within the capabilities of the Pi 3A+.
            Firstly: you should say 64 bit "can have" not "does have". One test of one app..

            Secondly: the memory footprint will vary depending on the app(s) you are running, so again; the general statement you made doesn't make sense.

            Thirdly and most importantly: I think you missed my point. Perhaps I didn't explain myself well enough. I will clarify:

            Yes... there may be 64 bit hardware that runs 64 bit apps quicker and there may be apps that benefit from the increased size of types. However, if an app doesn't need or benefit from bigger types (IE doing arithmatic with bigger numbers) and it doesn't need to address more than 4 GB of memory, then a 32 bit CPU will always (as far as I know) be superior to a 64 bit CPU (if all other things equal; e.g. equivalent instruction sets), as you will need less CPU cache and less memory to do the same job.

            I expect that the vast majority of embedded systems and very low power devices would be more efficient if they used a 32 bit CPU architecture. However, I did previous note reasons why embedded device manufacturers aren't doing this.

            Comment


            • #16
              Originally posted by cybertraveler View Post

              I expect that the vast majority of embedded systems and very low power devices would be more efficient if they used a 32 bit CPU architecture. However, I did previous note reasons why embedded device manufacturers aren't doing this.
              The vast majority of embedded (micro-controllers) are using 32bit. The vast majority of computers running a full OS are using 64bit.

              I don't imagine that the Cortex A7 will disappear anytime soon. So there certainly are 32bit micro options available.
              Last edited by cbxbiker61; 01 February 2019, 05:49 PM.

              Comment


              • #17
                Originally posted by cybertraveler View Post

                Firstly: you should say 64 bit "can have" not "does have". One test of one app..

                Secondly: the memory footprint will vary depending on the app(s) you are running, so again; the general statement you made doesn't make sense.

                Thirdly and most importantly: I think you missed my point. Perhaps I didn't explain myself well enough. I will clarify:

                Yes... there may be 64 bit hardware that runs 64 bit apps quicker and there may be apps that benefit from the increased size of types. However, if an app doesn't need or benefit from bigger types (IE doing arithmatic with bigger numbers) and it doesn't need to address more than 4 GB of memory, then a 32 bit CPU will always (as far as I know) be superior to a 64 bit CPU (if all other things equal; e.g. equivalent instruction sets), as you will need less CPU cache and less memory to do the same job.

                I expect that the vast majority of embedded systems and very low power devices would be more efficient if they used a 32 bit CPU architecture. However, I did previous note reasons why embedded device manufacturers aren't doing this.
                Well a wider data bus will allow for faster loads and stores to cache/memory for applications that shuffle lots of memory around.

                Comment


                • #18
                  Originally posted by F.Ultra View Post

                  Well a wider data bus will allow for faster loads and stores to cache/memory for applications that shuffle lots of memory around.
                  True, but that's somewhat arbitrary because the bus size can be wider or thinner than the processor architecture. You could have a 32 bit CPU with a 128 bit bus. That Nintendo page I linked above also stated that the 64 bit CPU was connected to another chip via a 32 bit bus.

                  Also, the bus frequency affects the speed too.

                  Comment


                  • #19
                    Originally posted by cybertraveler View Post

                    True, but that's somewhat arbitrary because the bus size can be wider or thinner than the processor architecture. You could have a 32 bit CPU with a 128 bit bus. That Nintendo page I linked above also stated that the 64 bit CPU was connected to another chip via a 32 bit bus.

                    Also, the bus frequency affects the speed too.
                    Interesting that you keep using examples from 23 years ago as if they are relevant today.

                    His point is not arbitrary...I challenge you to find one current 64bit chip that is using memory that is less than 64bits wide. My Mycroft example is a current real-world scenario where 64bit memory access improves performance, therefore the chip idles more and uses less power.

                    Sure, there can be scenarios where 32bit might be an advantage over 64bit. But your statement "I expect that the vast majority of embedded systems and very low power devices would be more efficient if they used a 32 bit CPU architecture." is misguided. I'm assuming that you mean machines running a full OS, as I already pointed out that current micro-controllers are 32bits.

                    In any case, any engineer putting together a real solution will have the savvy to weigh the pros and cons and make an informed decision. I doubt they'll be weighing data from 23 year old designs very heavily.

                    Comment


                    • #20
                      cbxbiker61 - you failed to acknowledge my previous comments pointing out the glaring issues with your prior post. I'm not spending further time discussing this with you.

                      Comment

                      Working...
                      X