Announcement

Collapse
No announcement yet.

Intel Launches The Xeon D 2100, Up To 18 Core SoCs

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

  • #41
    Originally posted by Yndoendo View Post
    Will not touch Intel until at least Meltdown is fixed on silicon. AMD is currently your safer bet.
    Of course then you're essentially limited to 8 Cores per NUMA node, not ideal for Software Defined {Storage,Network}.

    Comment


    • #42
      Originally posted by nils_ View Post

      I 'member the old days when the first multi CPU x86 systems sprung up. Linux was still pretty terrible at handling multiple CPUs ('member the BKL/big kernel lock?), and it took a few years for the BSDs to catch up.
      Yeah, I remember that vaguely. But it was still better than NT4/2K though. Limited to just 2 processors unless you wanted to pay hundreds more for the server variant of the OS. I remember specifically it was one of the first reasons I had to give Linux a serious chance.

      Comment


      • #43
        Originally posted by ptrwis View Post

        I hope to see such solution from Intel in next 2 years.
        I suspect AMD has the lead here. I'm very much impressed with my recent RYZEN Mobile purchase, but unfortunately have to wait for Linux support. It is nice to see AMD back in the game.

        In any event the nice thing about this high integration is that it makes for very small motherboards leaving room for large batteries and expansion. On the desktop we can have very small but perfomant machines that can go anywhere.

        Comment


        • #44
          Originally posted by nils_ View Post

          I 'member the old days when the first multi CPU x86 systems sprung up. Linux was still pretty terrible at handling multiple CPUs ('member the BKL/big kernel lock?), and it took a few years for the BSDs to catch up.
          It certainly took awhile for OS's to leverage multi cpus and then multi core chips but i dont know of anybody that would want to go back to a single processor, single core systems like we had a couple of decades ago. It really didnt matter whos OS you where running support for many core systems took awhile to firm up.

          In any event the point i was trying to get across and which other members couldnt understand is that the OS and the multi core are critical to delivering the performance most users expect these days. Somehow that was turned into an arguement against single core performance which it wasnt. What is obvious is that the majority of users are better off with multi core machines when combined with modern OS's and apps.

          Comment


          • #45
            Originally posted by starshipeleven View Post
            I'm just pointing out that currently the issue is in the applications not multithreading themselves anywhere near enough. The OS and hardware was ready since last decade, it's so widespread that it's practically irrelevant.
            And im pointing out that that is largely baloney! More importantly you seem to believe that most user only run one app at a time. Nor do you believe that the OS has its own house keeping to do.
            Huh? For any high-performance application you very much care. The OS does have all the thread-management infrastructure, and schedulers for CPU time, I/O and so on. If you are on a multicore system you need some kind of OS to do this job for you, or you must do so on your own, and that's not a piece of cake.
            Thanks for invalidating your previous coments.
            *That runs like shit even on octacores.
            Actually the latest releases on modern hardware arent that bad.
            And no, I don't see why an IDE should need any significant amount of processing power. It's a glorified text editor with auxiliary package manager or XML/similar parser functionality.
            It is a tool for skilled developers and just like XCode, Visual Studio and others it requires a modern OS and hardware.
            *Java duplicates a bunch of OS functions for the sake of making a cross-OS application, but by itself does not multi-thread your program.

            It may do something very rudimentary, yes, if you use pre-made libs/frameworks that are multi-threaded, but you can use libraries/frameworks on any language.

            Multi-threading happens when the programmer lays out a project where his program splits up itself in multiple threads where each does stuff on its own. This division must happen at the logic level, on the drawing board, you can't just take a blob and split it brutally.
            In most cases yes but the point is you still need a modern OS and mukti core hardware to really leverage the technology.
            Multi-threading requires man-hours and skill. It is not granted by a framework unless you are doing something with 0 innovation in it (the nth "great webapplication for company accounting" for example) where you can just take a framework that is multi-threaded already and assemble the programming equivalent of Lego blocks to create your program.
            Isnt it pretty stupid not to use framework supplied features? Beyond that there are plenty of examples of very simple mukti threading implementations in apps with big pay offs.


            The OS is just exposing the capability and providing the infrastructure to deal with many threads running independently.
            So the OS actually is important.
            If the applications don't multi-thread themselves, there is little the OS can do. Which is my point.
            My point is who cares? Very few these days are hung up on the performance of a single non threaded app.
            That's not what multi-threading is about. That's multitasking. Even a single-core system can run multiple different programs at the same time, since pretty much any OS worthy of the name is multitasking.
            You still arent grasping what is being discussed here.
            DOS is not multi-threading either, it would not allow to use more than a single core effectively.
            Exactly. If you are so hung up on the performance of a single app that isn't threaded, you might as well go back to using DOS. Im not sure what your problem is here, very few care anymore about such apps. We live in a world of processes and threads now.
            The only reason they started making multi-core CPUs is because they could not make faster single-core ones. So no, using only a single core would severely limit the processing power the game has access to.
            Yet you keep saying all these mystery apps exist that are onlysingle threaded.
            Multithreading is NOT the same thing as multitasking. Multitasking is easy, as it is dealt with by the OS. Multithreading is hard, as it requires the program itself to split itself up in many smaller "programlets" that are dealt with as they were separate programs in a multitasking OS.
            Multi threading is no harder than multitasking. The concept is actually simple. It is the project at hand that is either simple or hard.
            "highly threaded" yeah right. Even browsers "highly thread" by just using a thread per web-page rendered, or splitting the media rendering on its own thread or similar. That's kindergarden-grade multithreading.

            Ask yourself why the Apple phones/tablets have the CPUs with best IPC (instructions per clock, it's a measure of how powerful is the processor in executing single-thread programs), or why Intel is still doing their damn best to provide consumer hardware that has the best IPC possible.
            Those chips also come with additional core. You cant beat parallel processing by throwing high IPC counts at the problem. Apples achievement is striking the right balance between single core performance and the number of cores supplied.

            Comment

            Working...
            X