I want to download vs on my pterodactyl server but when i install it the world crashes is there a way to minimize the treads that are create to like 200 ?
#Pterodactyl
onyx wren
onyx wren
maybe will be added in the future but it would also ruin the physics performance
can you make maybe a pyterodactyl version that doesnt get updated that often?
final hawk
can you make maybe a pyterodactyl version that doesnt get updated that often?
wdym updated?
like released or physics tick updates
onyx wren
like released or physics tick updates
a version for pterodactyl that gets an update like every 2 months
onyx wren
we would just add a config to restrict the threads
ohh thats rly good ig if its possible
final hawk
ohh thats rly good ig if its possible
Ok so it turns out this is already a thing
And no one frickin noticed 😭
In the vs core server config you can set a thread limit
As of 2.4 or something
But it also should maybe default to the limit pterodactyl enforces? Not sure
proud oak
maybe will be added in the future but it would also ruin the physics performance
how does that work anyway a cpu doesent have 200 threads
final hawk
how does that work anyway a cpu doesent have 200 threads
The JVM can do more threads than that
Idk how
Probably by switching between them periodically?
Idk triode would know more
proud oak
The JVM can do more threads than that
huh alr
proud oak
It’s C++ iirc
System manages time and slices them
final hawk
So it can also do more than the CPUs threads? Handy
proud oak
So it can also do more than the CPUs threads? Handy
Huh
proud oak
So it can also do more than the CPUs threads? Handy
Here let me explain with my amazing degree
17
In C++, you can create more software threads than physically available hardware threads (CPU cores/logical processors) because the operating system manages and time-slices them. The C++ standard does not impose a limit on the number of threads you can create, leaving it up to the operating system and available memory.
How it Works
When a C++ program uses libraries like <thread> or high-level options like OpenMP to create numerous threads, the operating system's scheduler handles the execution:
OS Scheduler: The operating system's kernel is responsible for deciding which threads run on which available hardware core at any given moment.
Time-Slicing: The scheduler gives each thread a short burst of CPU time, known as a "time slice".
Context Switching: When a thread's time slice is up, the OS saves its state (context) and loads the state of another waiting thread to run on the core.
This process is called a context switch.
Apparent Concurrency: This switching happens so quickly (often in milliseconds or less) that it appears all threads are running simultaneously to the user, even on a single-core machine.
Why This Is Done
Creating more threads than cores is a standard technique, particularly when threads frequently encounter blocking operations:
Handling I/O Operations: Threads often pause to wait for slow operations like disk I/O, network access, or user input. During this waiting time, the CPU would be idle. The OS scheduler efficiently uses this idle time by switching to a different, ready-to-run thread.
Responsiveness: In applications like web servers, where each connection might be handled by a separate thread, having many threads ensures that while some are waiting for network data, others can continue processing.
Task Management: Programs are often structured with different threads for distinct tasks (e.g., one for GUI, one for background processing), and these threads may not be continuously CPU-bound.
Performance Considerations
While you can create many threads, it's not always beneficial for performance:
Overhead: Creating and managing a large number of threads comes with overhead, primarily the cost of context switching.
Performance Degradation: If you have too many CPU-bound threads (threads that constantly need the CPU and don't wait for I/O), the excessive context switching can cause the system to "thrash" and slow down the overall application's throughput.
Optimal Number: For CPU-intensive tasks, a common recommendation is to use a number of threads equal to the available hardware concurrency (number of cores/logical processors), which can be retrieved using std:🧵:hardware_concurrency() in C++.
To manage a large number of potential tasks efficiently, developers often use thread pools, which reuse a fixed number of threads instead of constantly creating and destroying new ones.
proud oak
Woah Jesus Christ
I did not steal that from the gemini blov that appears when you google stuff
final hawk
Yeah but is it limiting the JVM?
Or outside the jvm
Who knows ig
Point is vs has a config to hopefully get around this now
proud oak
Point is vs has a config to hopefully get around this now
Nice
lofty oasis
Or outside the jvm
I am pretty sure it is limiting outside since Ptero and other panels like amp run all games inside of docker containers and I think Ptero limits how many threads the container can access since that is what amp does
onyx wren
I am pretty sure it is limiting outside since Ptero and other panels like amp ru...
The Panel Are limiting threads Its killing when to much Are created