Intel CEO Pat Gelsinger Retires

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

  • mSparks
    replied
    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.

    Leave a comment:


  • DumbFsck
    replied
    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...

    Leave a comment:


  • mSparks
    replied
    Originally posted by duby229 View Post

    I pointed out the detectCores() function to you a while ago. .
    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.
    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.

    So on Windows, R just uses a dummy function that runs the users function on 1 core

    throwing
    'mc.cores' > 1 is not supported on Windows

    if you set numCores to anything other than 1
    because windows doesn't support multithreading - let alone all the hardware accelerated multithreading on all modern non X86 silicon.

    Originally posted by duby229 View Post

    but acheiving parallelism is really hard.


    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, because it requires a thread safe pointer to the kernel (fork() on POSIX), which is what I mean by "windows does not support multithreading".
    Linux and MacOS make extensive use of it, which is why they outperform windows in every high core count setting.
    Last edited by mSparks; 17 December 2024, 02:06 AM.

    Leave a comment:


  • duby229
    replied
    Originally posted by mSparks View Post

    so its true because everyone told you it is true.

    Not because you actually got it working...

    Gotcha.

    Unfortunately ad populum arguments won't actualy get it working or save windows and X86 from the explosion in the number of cores on peoples devices that actually need it working for windows/X86 to be competitive going forward.
    I pointed out the detectCores() function to you a while ago. And here he just recently pointed out that function is known to not work. And then he linked you to a known working solution.

    So yes, yes he did! It's up to you to figure out what he means. If everyone is telling you the same thing, then maybe you should consider what they are saying.... Just saying...

    Leave a comment:


  • duby229
    replied
    Originally posted by smitty3268 View Post

    I'm sorry, but the idea that forking is the only way to possibly get multi-threading is such a wackjob idea I don't even know how to respond.

    It's like the computer-science equivalent of a guy claiming the earth is flat.

    I don't think there's much to discuss when you obviously reject any common basic understanding of how computers work.
    I tried already. It is possible to achieve concurrency in some situations, but acheiving parallelism is really hard. Nobody is using fork to multithread.

    Leave a comment:


  • mSparks
    replied
    Originally posted by smitty3268 View Post

    I'm sorry, but the idea that forking is the only way to possibly get multi-threading is such a wackjob idea I don't even know how to respond.

    It's like the computer-science equivalent of a guy claiming the earth is flat.

    I don't think there's much to discuss when you obviously reject any common basic understanding of how computers work.
    so its true because everyone told you it is true.

    Not because you actually got it working...

    Gotcha.

    Unfortunately ad populum arguments won't actualy get it working or save windows and X86 from the explosion in the number of cores on peoples devices that actually need it working for windows/X86 to be competitive going forward.
    Last edited by mSparks; 16 December 2024, 06:25 PM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by mSparks View Post
    15 years of the worlds best comp sci analysts, SaaS and software developers trying to get multithreading working on windows and failing.

    Plus multiple windows devices from windows phone to windows surface failing because they lack the power/perf characteristics of multithreaded applications.

    Where did you get the idea you can?
    I'm sorry, but the idea that forking is the only way to possibly get multi-threading is such a wackjob idea I don't even know how to respond.

    It's like the computer-science equivalent of a guy claiming the earth is flat.

    I don't think there's much to discuss when you obviously reject any common basic understanding of how computers work.

    Leave a comment:


  • samuellnom
    replied
    Wow, that's surprising! Intel has been facing challenges, and Gelsinger's retirement adds another twist. It'll be interesting to see how the company moves forward from here.

    Leave a comment:


  • mSparks
    replied
    Originally posted by smitty3268 View Post

    lol. Where in the world did you get that idea?
    15 years of the worlds best comp sci analysts, SaaS and software developers trying to get multithreading working on windows and failing.

    Plus multiple windows devices from windows phone to windows surface failing because they lack the power/perf characteristics of multithreaded applications.

    Where did you get the idea you can?
    Last edited by mSparks; 14 December 2024, 09:23 PM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by mSparks View Post
    because without fork you can't multithread
    lol. Where in the world did you get that idea?

    Leave a comment:

Working...
X