-
Notifications
You must be signed in to change notification settings - Fork 374
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Slight readme clarification on C# choice, for #3
I'm still unsure how to best rewrite this, but this gets a little closer/clearer for the moment.
- Loading branch information
1 parent
82d9bc9
commit 8d02e78
Showing
1 changed file
with
1 addition
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -72,7 +72,7 @@ See [the documentation folder](docs). | |
|
||
The "Swarm" name is in reference to the original key function of the UI: enabling a 'swarm' of GPUs to all generate images for the same user at once (especially for large grid generations). | ||
|
||
This project is built with a C# backend server to maximize performance while only minimally increasing code complexity. While most ML projects tend to be written in Python, that language is simply insufficient to meet performance goals, notably it lacks "true" multithreading capabilities, which was deemed strongly necessary for StableSwarmUI. It is also hoped that building Stable Diffusion tools in C# will enable a wider range of developers to make use of Stable Diffusion (vs being limited to the Python ecosystem). | ||
This project is built with a C# backend server to maximize performance while only minimally increasing code complexity. While most ML projects tend to be written in Python, that language is simply insufficient to meet the performance goals of this project (ie to provide a very fast and responsive multi-user-ready multi-backend service), notably it lacks "true" multithreading capabilities (due to Python GIL), which was deemed strongly necessary for StableSwarmUI (it must be able to use available CPU cores while serving user requests and managing internal data to be able to respond to all requests as quickly as possible). It is also hoped that building Stable Diffusion tools in C# will enable a wider range of developers to make use of Stable Diffusion (vs being limited to the Python ecosystem). | ||
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
Sorry, something went wrong.
saint4eva
|
||
|
||
The project was designed to be heavily modular, such that backends are fully separated from the middle-layer which is fully separated from the frontend UI, and all components are interswappable. This is to enabled extensibility and customization. For example, an extension can easily provide alternative backend generators (this project comes with several built-in, such as ComfyUI, Auto WebUI, StabilityAPI, ...) without having to edit anything else to work. The limitation of this approach is some tools may not easily be intercompatible, eg the StabilityAPI backend has only a select few limited inputs, vs the local backends that have a wider range, and so many parameters don't work with StabilityAPI. | ||
|
||
|
I would like to reiterate again that this reasoning is spurious and it seems that you've only reiterated your original message with stronger language.
See https://docs.python.org/3/library/multiprocessing.html
The problems you're talking about are technical details and engineering problems that you may want to attack in C# because its more familiar to you, or perhaps because the tool set is richer. However, python is certainly has the characteristics you are claiming are absent and it is matter of good design and architecture beyond that to maintain performance goals.
I find it hard to believe the performance requirements of this project will near the theoretical limits of physics - in which case, C# is, in an academic way, also a poor choice. But, the absurdity of that statement is kind of my point - python is not fundamentally a bad choice; it sounds more like that you or your team knows C# better to do what you think swarm needs, which is fine, but that doesn't justify claiming the whole python language is prima facie, to borrow a legal term, insufficient.