Intel CEO Pat Gelsinger Retires

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • DumbFsck
    Senior Member
    • Dec 2023
    • 332

    I don't understand how you managed to have a long career being so thick.

    Originally posted by mSparks View Post
    detectCores is nowhere near the problem, that correctly returns how many cores the system silicon has.
    The problem is, if you try and run stuff through the windows kernel on more than one core the whole operating system explodes - because the windows kernel is not thread safe.
    The NT kernel is thread-safe. I take you have the same definition of "thread safety" as I do (and honestly, basically the whole industry has), as in, a piece of code or a system being used at the same time by multiple threads without causing errors, unexpected behaviour, or data corruption.

    Windows offers, in its kernel:
    Spinlocks, mutexes, semaphores, rwlocks, atomic increment/decrement/exchange etc, IRQL, supports kernel preemption, supports reference counting for kernel objects to manage object lifetimes, DPCs, SEH, has their own scheduler...

    All of this means that it IS thread safe, those are a lot of tools to guarantee it, and most of those are very similar to what Linux offers in terms of safety. Of course without being able to see how it is implemented under the hood, but regardless, they work.

    Not to mention, IIRC fork() is NOT thread-safe, you have to synchronize your shit yourself when using it...

    Originally posted by mSparks View Post
    fork() is the POSIX OS call to get a thread safe pointer to the kernel, without it you cannot run multithreaded applications that call the OS Kernel. windows has no equivalent function to fork because it is mostly single threaded/doesn't support multithreading.
    What do you even mean with "a thread safe pointer to the kernel"? I've never heard of anything like it...

    Maybe you mean something with shared memory? in which case I think you'd be more interested in pthreads rather than fork(), or even clone() if you want to go lower - NOT fork().

    Originally posted by mSparks View Post
    So on Windows, R just uses a dummy function that runs the users function on 1 core
    I already told you once and will tell you again: R's IMPLEMENTATION IS R's PROBLEM, NOT WINDOWS'

    Personally I don't even believe you read or tried using future:: parallelly for that video you showed. That could be anything.

    But then again, since many other languages and millions of other programs offer multi-threading on windows without issues, even if parallelly is not a solution - R's implementation and Parallelly's implementation are NOT sufficient to say that windows itself isn't multithreaded...



    Originally posted by mSparks View Post
    because windows doesn't support multithreading - let alone all the hardware accelerated multithreading on all modern non X86 silicon.
    [...]​

    Not when your OS supports multithreading it is't. You just give it a pointer to a memory space, a pointer to your function/function calls you want to run over that memory space, and the number of threads you want to split the job over, and the OS takes care of the rest, making use of any silicon and hardware acceleration it has available. No fucking about with mutexes, no worrying about what is or isn't thread safe, "just works".


    Windows cannot do this
    it can... with windows.h you just call CreateThread and pass whatever you want, windows will do the rest and take care of you (you can HANDLE whatever you like as well, there are what, hundreds of functions you can just call from kernel32.dll and get windows to do whatever you want with it? don't take it from me, just click on the left column titled "synchronization reference" and then "synchronization functions" in this page)

    This link should make you better informed...

    Comment

    • mSparks
      Senior Member
      • Oct 2007
      • 2077

      Originally posted by DumbFsck View Post
      I don't understand how you managed to have a long career being so thick.

      The NT kernel is thread-safe. I take you have the same definition of "thread safety" as I do (and honestly, basically the whole industry has), as in, a piece of code or a system being used at the same time by multiple threads without causing errors, unexpected behaviour, or data corruption.
      Then how do you explain


      Originally posted by DumbFsck View Post
      R's IMPLEMENTATION IS R's PROBLEM, NOT WINDOWS'
      R's linux and macos implimentation is like 3 lines of C code, if what you say is true, why has no one written the equivalent lines of R code

      Code:
      f <- mcfork(detached)
      env <- parent.frame()​​
      mc.advance.stream()
      sendMaster(try(eval(expr, env), silent = TRUE))
      mcexit(0L)​
      for windows?

      Originally posted by DumbFsck View Post
      just call CreateThread and pass whatever you want
      What you want to pass is an entire copy of the program calling it without using any more ram than absolutely necessary (the bits of ram owned by the program calling CreateThread changed by each thread), with the OS handling all the resources needed to multithread it. whats the windows call to do that?

      Answer btw is there isnt one, because windows doesnt support multithreading, you would have to implement it all yourself, and everyone who has tried has failed - including microsoft, who gave up and did it (badly) with WSL then slightly less badly with WSL2.
      Last edited by mSparks; 22 December 2024, 03:52 PM.

      Comment

      Working...
      X