Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Windows Forms
  4. Hypothetical Discussion - Multi core CPU's and Software utilization

Hypothetical Discussion - Multi core CPU's and Software utilization

Scheduled Pinned Locked Moved Windows Forms
asp-netquestiondiscussioncode-review
5 Posts 2 Posters 3 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Alisaunder
    wrote on last edited by
    #1

    Just bringing this idea up to see if it might hold any merit to developers or just plain crazy. I've realized for a long time now that no matter how many CPU's you have you are still limited by the Software developers incorporating multi-threading for whatever number of cores. My Question is. What if we were to have the OS, which already knows how many Cores are present distribute the operating processes on different clock cycles to the multiple cores in a serial type effect. Everyone know data is streamed to the processor serially every clock cycle. if the OS were to know the number of CPU's and integrate a method of switching between them distributing data to each one every clock cycle, it seems to me the more cores you had the faster the information could be processed no matter whether the programs were written to optimize multi-core or not.

    L 1 Reply Last reply
    0
    • A Alisaunder

      Just bringing this idea up to see if it might hold any merit to developers or just plain crazy. I've realized for a long time now that no matter how many CPU's you have you are still limited by the Software developers incorporating multi-threading for whatever number of cores. My Question is. What if we were to have the OS, which already knows how many Cores are present distribute the operating processes on different clock cycles to the multiple cores in a serial type effect. Everyone know data is streamed to the processor serially every clock cycle. if the OS were to know the number of CPU's and integrate a method of switching between them distributing data to each one every clock cycle, it seems to me the more cores you had the faster the information could be processed no matter whether the programs were written to optimize multi-core or not.

      L Offline
      L Offline
      Luc Pattyn
      wrote on last edited by
      #2

      Alisaunder wrote:

      plain crazy

      it is. each thread executing on a core has state (in the CPU registers, in the stack, etc), instructions from one thread have to remain on the same core to work with that state; switching a thread to another core is a rather expensive kernel operation, one would typically like to avoid (that is what "thread affinity" is about). Furthermore cores have caches to vastly improve performance; and these caches most often are local to the core, so having the data in one core's cache isn't going to help the thread when executing on a different core. And finally, CPU performance isn't the only bottleneck, there are other limitations, such as memory bandwidth, and disk and network performance. Therefore, adding a few threads to an app may be good, adding a large number generally is counterproductive. In all a very bad idea.

      Luc Pattyn [My Articles] Nil Volentibus Arduum


      Fed up by FireFox memory leaks I switched to Opera and now CP doesn't perform its paste magic, so links will not be offered. Sorry.

      A 2 Replies Last reply
      0
      • L Luc Pattyn

        Alisaunder wrote:

        plain crazy

        it is. each thread executing on a core has state (in the CPU registers, in the stack, etc), instructions from one thread have to remain on the same core to work with that state; switching a thread to another core is a rather expensive kernel operation, one would typically like to avoid (that is what "thread affinity" is about). Furthermore cores have caches to vastly improve performance; and these caches most often are local to the core, so having the data in one core's cache isn't going to help the thread when executing on a different core. And finally, CPU performance isn't the only bottleneck, there are other limitations, such as memory bandwidth, and disk and network performance. Therefore, adding a few threads to an app may be good, adding a large number generally is counterproductive. In all a very bad idea.

        Luc Pattyn [My Articles] Nil Volentibus Arduum


        Fed up by FireFox memory leaks I switched to Opera and now CP doesn't perform its paste magic, so links will not be offered. Sorry.

        A Offline
        A Offline
        Alisaunder
        wrote on last edited by
        #3

        ok I'm not a CPU engineer so I just have a basic understanding of their functionality, but aren't we seeing similar functionality being used on Video cards using SLI to distribute screen information between 2,3 and 4 videocards tied together. Instead of CPU's they are GPU's which are basically the same thing.

        1 Reply Last reply
        0
        • L Luc Pattyn

          Alisaunder wrote:

          plain crazy

          it is. each thread executing on a core has state (in the CPU registers, in the stack, etc), instructions from one thread have to remain on the same core to work with that state; switching a thread to another core is a rather expensive kernel operation, one would typically like to avoid (that is what "thread affinity" is about). Furthermore cores have caches to vastly improve performance; and these caches most often are local to the core, so having the data in one core's cache isn't going to help the thread when executing on a different core. And finally, CPU performance isn't the only bottleneck, there are other limitations, such as memory bandwidth, and disk and network performance. Therefore, adding a few threads to an app may be good, adding a large number generally is counterproductive. In all a very bad idea.

          Luc Pattyn [My Articles] Nil Volentibus Arduum


          Fed up by FireFox memory leaks I switched to Opera and now CP doesn't perform its paste magic, so links will not be offered. Sorry.

          A Offline
          A Offline
          Alisaunder
          wrote on last edited by
          #4

          By the way this is a hypothetical discussion I wasn't referring to current threading technology I was referring to a new way of trying to implement and utilize the extra cores inside a processor using the OS sort of like SLI does with a device driver and GPU's.

          L 1 Reply Last reply
          0
          • A Alisaunder

            By the way this is a hypothetical discussion I wasn't referring to current threading technology I was referring to a new way of trying to implement and utilize the extra cores inside a processor using the OS sort of like SLI does with a device driver and GPU's.

            L Offline
            L Offline
            Luc Pattyn
            wrote on last edited by
            #5

            in a GPU things are quite different: it is dealing with streaming data, performing "simple" operations on a sequence of pixels, without much state involved, with tailored memory ports, and highly predictable. More cores means a smaller screen area per core, hence faster. Video processing is inherently a candidate for parallel processing; your average web browser, spreadsheet, whatever, isn't. :)

            Luc Pattyn [My Articles] Nil Volentibus Arduum


            Fed up by FireFox memory leaks I switched to Opera and now CP doesn't perform its paste magic, so links will not be offered. Sorry.

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups