4 ms·

I minted Joint Parallel and gave the definition! This code runs: http://move.rupy.se/file/atomic.txt http://move.rupy.se/file/atomic.txt And that's all you ne

by bullen 6y ago

I minted Joint Parallel and gave the definition! This code runs: http://move.rupy.se/file/atomic.txt http://move.rupy.se/file/atomic.txt And that's all you need to know really. As for experience, I wrote my own app server with distributed database and multiplayer protocol from scratch by myself and proved it with a MMO that has 300.000 customers: https://store.steampowered.com/app/486310/Meadow/ https://store.steampowered.com/app/486310/Meadow/ https://github.com/tinspin https://github.com/tinspin

CyberDildonics 6y ago
The things you said in your comment above are untrue for very fundamental reasons. This isn't a judgement call of the best techniques based github histories. > I minted Joint Parallel and gave the definition! That means it's nonsense. It is an oxymoron, it contradicts itself. Parallelism by definition is about separation of dependencies and synchronization. Join implies the exact opposite. That's like saying Bright Black while telling people you invented a new color space. It is a hiccup to being taken seriously (to put it mildly). You have said stuff like 'java doesn't crash (usually)' and that multi-threading rendering adds at least 10 frames of latency to a game. Statements like these are not just incorrect, they indicated a lack of understanding by thinking mostly orthogonal concepts are somehow at the mercy of each other. I looked at your link. The first file I opened says "non-blocking and asynchronous" in the first line of the comment. https://github.com/tinspin/rupy/blob/master/src/se/rupy/http/Reply.java https://github.com/tinspin/rupy/blob/master/src/se/rupy/http... Your methods that are supposedly doing this use the synchronize keyword whose purpose is to "block (suspend execution)" of other threads that call the same method until the first thread is done. https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
- bullen 6y ago
  Joint because Parallel by itself means nothing, if I setup two separate computers with a load balancer they are parallel. Joint as I said; and it's not rocket science so I'm getting a little annoyed; is when two separate cores work on the same real-time task that shares memory, most software 1) does not do this yet because it's hard 2) most programmers don't learn this because 1). For example Erlang, Rust and Go are terrible at sharing memory because they have simple memory models, they solve parallelism by synchronizing hard and slow with copying and locks. And yes games today have 10 frames of motion-to-photon latency, I measured it myself. Non-blocking there is referring to the IO, synchronized only blocks if there is contention, you have to compare this to the synchronous HTTP APIs to understand why I guess? wakeup() (and other methods) are synchronized because you don't want two threads to contest the hand-over point (in this case wakeup a HTTP response); all shared memory is done over java.util.concurrent data, which in most cases is atomic. You have to look at the fuse project to see most joint parallel code, not saying it's pretty; but it works at, just as these quotes imply, around 10x perf: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html "Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html https://travisdowns.github.io/blog/2020/07/06/concurrency-co... Until you show me something joint parallel you have done and preferably proven (with say 450 concurrent real-time action users on one machine); I'm calling this settled, your arguments are thin! (also why am I arguing with a user called dildo?!)
  - CyberDildonics 6y ago
    You completely missed the point, which is that you fundamentally don't understand how these things work. > Joint as I said; and it's not rocket science so I'm getting a little annoyed; is when two separate cores work on the same real-time task that shares memory, most software 1) does not do this yet because it's hard 2) most programmers don't learn this because 1). That's just parallelism. What do you think openMP does? It is a fork-join model and is the easiest method of parallel programming because reading data that isn't being written to is trivial. > For example Erlang, Rust and Go are terrible at sharing memory because they have simple memory models, they solve parallelism by synchronizing hard and slow with copying and locks. This is not true. Again you are not understanding the fundamentals of what a system language like rust does. https://doc.rust-lang.org/std/sync/atomic/ https://doc.rust-lang.org/std/sync/atomic/ > And yes games today have 10 frames of motion-to-photon latency, I measured it myself. I measured it and it was 1 frame > Until you show me something joint parallel you have done and preferably proven (with say 450 concurrent real-time action users on one machine); I'm calling this settled, your arguments are thin! (also why am I arguing with a user called dildo?!) None of this has to do with validating the things you have said. If you can use the concurrent data structures then that's good, that's what they are there for. I think you have a very warped idea of what you actually understand. Cars get people where they want to go but getting your driver's license doesn't mean you can design an engine.

by bullen 6y ago

CyberDildonics 6y ago

The things you said in your comment above are untrue for very fundamental reasons. This isn't a judgement call of the best techniques based github histories. > I minted Joint Parallel and gave the definition! That means it's nonsense. It is an oxymoron, it contradicts itself. Parallelism by definition is about separation of dependencies and synchronization. Join implies the exact opposite. That's like saying Bright Black while telling people you invented a new color space. It is a hiccup to being taken seriously (to put it mildly). You have said stuff like 'java doesn't crash (usually)' and that multi-threading rendering adds at least 10 frames of latency to a game. Statements like these are not just incorrect, they indicated a lack of understanding by thinking mostly orthogonal concepts are somehow at the mercy of each other. I looked at your link. The first file I opened says "non-blocking and asynchronous" in the first line of the comment. https://github.com/tinspin/rupy/blob/master/src/se/rupy/http/Reply.java https://github.com/tinspin/rupy/blob/master/src/se/rupy/http... Your methods that are supposedly doing this use the synchronize keyword whose purpose is to "block (suspend execution)" of other threads that call the same method until the first thread is done. https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...

bullen 6y ago
Joint because Parallel by itself means nothing, if I setup two separate computers with a load balancer they are parallel. Joint as I said; and it's not rocket science so I'm getting a little annoyed; is when two separate cores work on the same real-time task that shares memory, most software 1) does not do this yet because it's hard 2) most programmers don't learn this because 1). For example Erlang, Rust and Go are terrible at sharing memory because they have simple memory models, they solve parallelism by synchronizing hard and slow with copying and locks. And yes games today have 10 frames of motion-to-photon latency, I measured it myself. Non-blocking there is referring to the IO, synchronized only blocks if there is contention, you have to compare this to the synchronous HTTP APIs to understand why I guess? wakeup() (and other methods) are synchronized because you don't want two threads to contest the hand-over point (in this case wakeup a HTTP response); all shared memory is done over java.util.concurrent data, which in most cases is atomic. You have to look at the fuse project to see most joint parallel code, not saying it's pretty; but it works at, just as these quotes imply, around 10x perf: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html "Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html https://travisdowns.github.io/blog/2020/07/06/concurrency-co... Until you show me something joint parallel you have done and preferably proven (with say 450 concurrent real-time action users on one machine); I'm calling this settled, your arguments are thin! (also why am I arguing with a user called dildo?!)
- CyberDildonics 6y ago
  You completely missed the point, which is that you fundamentally don't understand how these things work. > Joint as I said; and it's not rocket science so I'm getting a little annoyed; is when two separate cores work on the same real-time task that shares memory, most software 1) does not do this yet because it's hard 2) most programmers don't learn this because 1). That's just parallelism. What do you think openMP does? It is a fork-join model and is the easiest method of parallel programming because reading data that isn't being written to is trivial. > For example Erlang, Rust and Go are terrible at sharing memory because they have simple memory models, they solve parallelism by synchronizing hard and slow with copying and locks. This is not true. Again you are not understanding the fundamentals of what a system language like rust does. https://doc.rust-lang.org/std/sync/atomic/ https://doc.rust-lang.org/std/sync/atomic/ > And yes games today have 10 frames of motion-to-photon latency, I measured it myself. I measured it and it was 1 frame > Until you show me something joint parallel you have done and preferably proven (with say 450 concurrent real-time action users on one machine); I'm calling this settled, your arguments are thin! (also why am I arguing with a user called dildo?!) None of this has to do with validating the things you have said. If you can use the concurrent data structures then that's good, that's what they are there for. I think you have a very warped idea of what you actually understand. Cars get people where they want to go but getting your driver's license doesn't mean you can design an engine.