Announcement

Collapse
No announcement yet.

Raspberry Pi Zero 2 W Launches As Newer, Faster $10 Single Board Computer

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

  • #31
    Is the availability of these going to be better than the other Zero boards? I never ended up getting either of those as sellers limit purchases to 1 per order and charge crazy shipping. Must be nice to live near a Microcenter.
    Adafruit has the older one in stock now. https://www.adafruit.com/product/3708 . 1 per customer.

    Shipping cost is 'crazy'.... What I do is wait until I have $100+ of stuff I want (not necessarily need ) and tack on a Zero, or lately a Pico or two. Have a few extra boards now in my parts box when I need them....

    Comment


    • #32
      Interesting. Not what I was looking for, but cool.

      Comment


      • #33
        Does RPi devices have RTC clock trimmed to 32.768kHz( Hw clock )?
        I have rpi v1.1 and I think it doesn't..

        Comment


        • #34
          Originally posted by tuxd3v View Post
          Does RPi devices have RTC clock trimmed to 32.768kHz( Hw clock )?
          I have rpi v1.1 and I think it doesn't..
          None of the Pi boards have a RTC. You can add one with a HAT or incorporate one on a carrier board for the compute unit versions, or you can use ntpd or equivalent on the OS you're using.

          Comment


          • #35
            Originally posted by sinepgib View Post

            Yes, but there are things like not using the extra registers (I'm talking about x86_64 here, I have no idea about ARM), specially for argument passing, assuming some extensions are missing, etc. There are some concrete advantages you get by being aware the processor is the 64 bits variant.
            Aarch64 performance advantage over armhf is quite limited with most workloads; just some specific workloads gain great benefit in term of performance. amd64 gains over x86 instead are quite consistent in most workloads.

            ps: usually increased register width and address space result in a performance drop by itself, amd64 gains a lot because lot of legacy things were removed and there are many more general purpose registers.

            Comment


            • #36
              Originally posted by blackshard View Post
              ps: usually increased register width and address space result in a performance drop by itself, amd64 gains a lot because lot of legacy things were removed and there are many more general purpose registers.
              I didn't know about that, but if it also implies (again, I have no idea about aarch64) more registers, surely that offsets most of the drop cause by the extra width? Operating on registers is generally much faster than memory access, even taking caching into account. Plus, ARM being RISC always operates on registers, right?

              Comment


              • #37
                Originally posted by kaidenshi View Post
                None of the Pi boards have a RTC. You can add one with a HAT or incorporate one on a carrier board for the compute unit versions, or you can use ntpd or equivalent on the OS you're using.
                The Idea is exactly to have a ntp server but using the RTC clock, to provide more fidelity of time to the system...I know that from time to time it will query the outside ntp servers, but in the meantime I want the time correctly moving, so that I can provide more accurate time to the internal network..

                I didn't thought about a Hat, probably there are hats for that, thanks!

                Comment


                • #38
                  Originally posted by blackshard View Post
                  ps: usually increased register width and address space result in a performance drop by itself, amd64 gains a lot because lot of legacy things were removed and there are many more general purpose registers.
                  At least in some metrics, one very common is exactly for the context switch times, they will increase with the amount of registers for sure..
                  In the end the ABI will have a lot to say, but there are always some points that you can know in advance if they are an improvement or not to certain things..

                  Comment


                  • #39
                    Originally posted by sinepgib View Post
                    Operating on registers is generally much faster than memory access, even taking caching into account. Plus, ARM being RISC always operates on registers, right?
                    What do you mean by operate on Registers?
                    Every arch operate on Registers, probably you are referring to System V ABI calling convention, more specific when you pass values to functions?
                    • X86( at least i386 ) pass on the stack by reverse order,
                    • amd64, pass in registers rdi, rsi, rdx, rcx, r8, r9, and the rest on the stack by reverse order( like in x86 ).
                    This do increase performance..

                    yes ARM also pass parameters in the registers( like amd64 ), but ARM pass less parameters in the registers r0, r1, r2, r3(4, while amd64 pass 6.. ), and the rest in the stack..
                    It could be that a lot changed from armv7 to arm64, I don't know about that..

                    By other words, if you have functions that pass a lot of parameters, then amd64 is faster calling functions..
                    In Context switches the arch that has more registers will suffer a lot more, since will have a lot of time only saving and restoring that great amount of registers between context switch's..this will be of a greater problem if you intend to have a real time OS..

                    Its not easy to say in a simpler way, what is best,depends..
                    Because it all depends on the situation,the ABI is also the big Elephant in the room.
                    Its very important that you design a good processor but its also very important that you design a good ABI,( if not you could end with poor performance, and/or incoherences ).

                    Also its very difficult to say, because the bottle of( very good wine.. )wine that I just finished...is starting to make a great effect on me..
                    regards,
                    Last edited by tuxd3v; 29 October 2021, 09:00 PM. Reason: complement

                    Comment


                    • #40
                      Originally posted by tuxd3v View Post
                      What do you mean by operate on Registers?
                      RISC architectures (typically) lack the rich variety of input/output combinations for operating on data that CISC ones tend to have. You tend to just have loads from and stores to memory, and every other instruction works with either literals or registers only.
                      By "operating on registers" I mean having more registers available you can avoid memory accesses, be it because you do register-memory operations or loads and stores. You can keep more data, including intermediary one, on registers, rather than going to memory.

                      Originally posted by tuxd3v View Post
                      Every arch operate on Registers, probably you are referring to System V ABI calling convention, more specific when you pass values to functions?
                      • X86( at least i386 ) pass on the stack by reverse order,
                      • amd64, pass in registers rdi, rsi, rdx, rcx, r8, r9, and the rest on the stack by reverse order( like in x86 ).
                      This do increase performance..
                      That is one thing I referred to, but not just that, the code inside functions can benefit from seeing the extra registers. If you build C code assuming it will run on an x86_64 processor you can compile it to use registers r8-r15, which x86 can't use.
                      Just a nit, but not all ISAs use registers AFAIR, some fringe and ancient stuff is stack only, right?

                      Originally posted by tuxd3v View Post
                      yes ARM also pass parameters in the registers( like amd64 ), but ARM pass less parameters in the registers r0, r1, r2, r3(4, while amd64 pass 6.. ), and the rest in the stack..
                      It could be that a lot changed from armv7 to arm64, I don't know about that..

                      By other words, if you have functions that pass a lot of parameters, then amd64 is faster calling functions..
                      In Context switches the arch that has more registers will suffer a lot more, since will have a lot of time only saving and restoring that great amount of registers between context switch's..this will be of a greater problem if you intend to have a real time OS..
                      Context switches are something you'd want to avoid anyway tho, you should make them a negligible fraction of your computations if you can manage. Regarding real time, yeah, you pick the stuff you need for your use case. Real time is not my case, just to clarify. I didn't think of context switches before tho, so it's nice you bring it up.

                      Originally posted by tuxd3v View Post
                      Its not easy to say in a simpler way, what is best,depends..
                      Because it all depends on the situation,the ABI is also the big Elephant in the room.
                      Its very important that you design a good processor but its also very important that you design a good ABI,( if not you could end with poor performance, and/or incoherences ).
                      I agree. Which makes extra sad that ABIs are extra conservative (with good reasons tho, most people don't want their binaries to just break).

                      Originally posted by tuxd3v View Post
                      Also its very difficult to say, because the bottle of( very good wine.. )wine that I just finished...is starting to make a great effect on me..
                      regards,
                      I envy you.
                      Last edited by sinepgib; 30 October 2021, 12:05 AM. Reason: I didn't really addressed the quoted part :facepalm:

                      Comment

                      Working...
                      X