4 ms·

Yes, I made my own open-source event driven platform: http://github.com/tinspin http://github.com/tinspin (rupy is the foundation and fuse is an example impleme

by bullen 5y ago

Yes, I made my own open-source event driven platform: http://github.com/tinspin http://github.com/tinspin (rupy is the foundation and fuse is an example implementation tested with 350.000 users and 5 years uptime) The learnings where 2-fold: 1) You need async-to-async capable db clients so that you use 4 threads (potentially on separate cores) for each browser <-> server <-> database roundtrip. Since most databases don't have async capable clients I wrote my own database too: http://root.rupy.se http://root.rupy.se 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory). This part is very hard to prove in theory, but in practice I'm baffled by how well Java performs, you can find three quotes that I managed find here: https://github.com/tinspin/rupy/wiki https://github.com/tinspin/rupy/wiki Finally getting threads to cooporate on things is hard and you cannot debug it with any tools, instead you have to use "trial and error" until is sort of works all the time.

CyberDildonics 5y ago
> 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory). Where did you get the idea that you need a VM and GC to do this? You literally only need a pointer to memory. These boil down almost directly to instructions on a CPU. You literally just atomically load and store to a pointer. https://en.cppreference.com/w/cpp/atomic/atomic https://en.cppreference.com/w/cpp/atomic/atomic Java isn't fast, your CPU is fast and the best thing any VM or GC can do is get out of the way.
- bullen 5y ago
  I would have written rupy in C with atomic pointers and .so/.dll hot-deploy if I had done it now, but: All concurrent complex datatypes leak memory with C/C++, I don't know why; but if you read the quotes you'll see others try to explain it: https://github.com/tinspin/rupy/wiki https://github.com/tinspin/rupy/wiki The VM is good for more things than concurrency, like no seg. fault crashes, which is very good to have on a server. Have you built anything like a 5 year uptime 1000+ concurrent users server with hot-patching every day? Have you even tried Java?
  - CyberDildonics 5y ago
    None of this reply even has anything to do with what I asked, which was why you think you need a VM and garbage collection to run specific CPU instructions. > All concurrent complex datatypes leak memory with C/C++ That's completely ridiculous and shows that you have a very fundamental misunderstanding of how these things work. They are wrappers around functions that do the atomic operations. https://en.cppreference.com/w/cpp/atomic/atomic_store https://en.cppreference.com/w/cpp/atomic/atomic_store Feel free to show me the memory leak you were talking about. https://godbolt.org/ https://godbolt.org/
    - bullen 5y ago
      All concurrent maps f.ex. It's like you're argumenting in a void, have you ever made anything? Please show some code you have written or stop replying to my comments.
      - CyberDildonics 5y ago
        That makes absolutely no sense in any way. You were implying that atomic operations, which don't allocate any memory and are just a pass through to CPU instructions operating on a pointer, somehow leak memory. Now you are saying "all concurrent maps" in C++ leak memory which not only has nothing to with what you said earlier, but it an insane claim to make without linking to specific maps you are talking about, not to mention that there aren't any in the C++ standard library. > Please show some code you have written or stop replying to my comments. What would make you realize that saying operations fundamental to a CPU "leak memory" is like saying 'loops make programs crash'. It is only something someone would say if they not only don't understand the fundamentals of what they are talking about, but don't even realize they don't understand it and in fact are absolutely sure that they do.

by bullen 5y ago

CyberDildonics 5y ago

> 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory). Where did you get the idea that you need a VM and GC to do this? You literally only need a pointer to memory. These boil down almost directly to instructions on a CPU. You literally just atomically load and store to a pointer. https://en.cppreference.com/w/cpp/atomic/atomic https://en.cppreference.com/w/cpp/atomic/atomic Java isn't fast, your CPU is fast and the best thing any VM or GC can do is get out of the way.

bullen 5y ago
I would have written rupy in C with atomic pointers and .so/.dll hot-deploy if I had done it now, but: All concurrent complex datatypes leak memory with C/C++, I don't know why; but if you read the quotes you'll see others try to explain it: https://github.com/tinspin/rupy/wiki https://github.com/tinspin/rupy/wiki The VM is good for more things than concurrency, like no seg. fault crashes, which is very good to have on a server. Have you built anything like a 5 year uptime 1000+ concurrent users server with hot-patching every day? Have you even tried Java?
- CyberDildonics 5y ago
  None of this reply even has anything to do with what I asked, which was why you think you need a VM and garbage collection to run specific CPU instructions. > All concurrent complex datatypes leak memory with C/C++ That's completely ridiculous and shows that you have a very fundamental misunderstanding of how these things work. They are wrappers around functions that do the atomic operations. https://en.cppreference.com/w/cpp/atomic/atomic_store https://en.cppreference.com/w/cpp/atomic/atomic_store Feel free to show me the memory leak you were talking about. https://godbolt.org/ https://godbolt.org/
  - bullen 5y ago
    All concurrent maps f.ex. It's like you're argumenting in a void, have you ever made anything? Please show some code you have written or stop replying to my comments.
    - CyberDildonics 5y ago
      That makes absolutely no sense in any way. You were implying that atomic operations, which don't allocate any memory and are just a pass through to CPU instructions operating on a pointer, somehow leak memory. Now you are saying "all concurrent maps" in C++ leak memory which not only has nothing to with what you said earlier, but it an insane claim to make without linking to specific maps you are talking about, not to mention that there aren't any in the C++ standard library. > Please show some code you have written or stop replying to my comments. What would make you realize that saying operations fundamental to a CPU "leak memory" is like saying 'loops make programs crash'. It is only something someone would say if they not only don't understand the fundamentals of what they are talking about, but don't even realize they don't understand it and in fact are absolutely sure that they do.