Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Оценка потребления памяти при одновременном запуске миллиона задач"	+/–
Сообщение от opennews (?), 29-Ноя-24, 16:42
Опубликованы результаты тестирования потребления памяти при выполнении кода, создающего миллион параллельно выполняемых сопрограмм. Тестирование проведено для типовой программы, реализованной на языках программирования Rust, C#, Go, Java, Python и JavaScript... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62314
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Оценка потребления памяти при одновременном запуске миллиона..."	+36 +/–
Сообщение от ijuij (?), 29-Ноя-24, 16:42
А где C/C++? 🤬
Ответить | Правка | Наверх | Cообщить модератору

	2. "Оценка потребления памяти при одновременном запуске миллиона..."	+45 +/–
	Сообщение от Барашек (?), 29-Ноя-24, 16:44
	тренера не играют
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
	Сообщение от Аноним (45), 29-Ноя-24, 17:32
	> тренера не играют Лол, какие тренера, если в C корутин вообще нет и не будет, а в плюсах они появились лишь в стандарте 2020 года.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (53), 29-Ноя-24, 17:45
	> Лол, какие тренера, если в C корутин вообще нет и не будет, Да могли бы хотя-бы и треды заспаунить каким-нибудь posix threads. Это даже круче ибо полновесные потоки. Интересно же столь наивный brute force в сравнении будет. А так какой-нибудь lwan - готов заспорить чего там нет. Правда оно там специфичное, под задачу. Си достаточно низкоуровневый чтобы на нем делать многое из того для чего в каком-нибудь Rust придется синтаксис корежить, а в игого и прочих питонах - чешут репу и сообщают что задача нерешаема. > а в плюсах они появились лишь в стандарте 2020 года. И что? Для хруста же можно взять какие-то вообще сторонние "фреймворки" или для жабы - разные VM. А в чем проблемы взять компилер с C++23 тогда?!
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (58), 29-Ноя-24, 17:49
	> Правда оно там специфичное, под задачу. Си достаточно низкоуровневый чтобы на нем делать многое из того для чего в каком-нибудь Rust придется синтаксис корежить, а в игого и прочих питонах - чешут репу и сообщают что задача нерешаема. Угу, то-то Торвальдся жалуется, что за 30 лет нормальный менеджмент памяти не осилили. Но про "специфичное" соглашусь) > И что? Для хруста же можно взять какие-то вообще сторонние "фреймворки" или для жабы - разные VM. А в чем проблемы взять компилер с C++23 тогда?! Там есть не только фреймворк, но STD.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 18:00
	> Угу, то-то Торвальдся жалуется, что за 30 лет нормальный менеджмент памяти не осилили. Я б все понял - если б весь тот набор еще и не пользовался услугами "богов" в виде этого самого Торвальдса и прочих сишников и плюсовиков, чтобы вообще операционку запустить и из нее п...ть вообще о своей крутизне :) Ах да, даже если кто научился немного шагать по ступенькам к пантеону - это еще не верхушка, а были еще и те кто его строил, на минуточку. Прикиньте, подстава какая?! :) > Но про "специфичное" соглашусь) Ну оно там реально под задачу запилено. Зато hello world прикольный! #include "lwan.h" LWAN_HANDLER_ROUTE(hello_world, "/") {     static const char message[] = "Hello, World!";     response->mime_type = "text/plain";     lwan_strbuf_set_static(response->buffer, message, sizeof(message) - 1);     return HTTP_OK; } int main(void) { return lwan_main(); } Да, я процитировал кастомный скоростной HTTP сервак. На си. Целиком. Нормуль? :). Правда без корутин. >> разные VM. А в чем проблемы взять компилер с C++23 тогда?! > Там есть не только фреймворк, но STD. Ну так что мешало тем господам взять C++23 и сравнить? Их есть уже.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от glad_valakas (?), 30-Ноя-24, 07:45
	> жалуется, что за 30 лет нормальный менеджмент памяти не осилили. прошу уточнить что такое "нормальный менеджмент памяти". когда GC запускается по желанию своей левой пятки и по закону подлости всегда не вовремя - это "нормальный менеджмент памяти" ? почему ?
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	90. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (90), 29-Ноя-24, 18:56
	>> Лол, какие тренера, если в C корутин вообще нет и не будет, > Да могли бы хотя-бы и треды заспаунить каким-нибудь posix threads Не могли бы, ибо смысл был именно в замере корутин, а не потоков.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	127. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Совершенно другой аноним (?), 29-Ноя-24, 19:23
	Можно воспользоваться библиотекой corutine.h от Simon Tatham (необходимая часть приведена сразу в исходнике). Для компиляции в linux ;---------------------------X8 #include <stdio.h> #include <string.h> #if defined(_WIN32)   #include <windows.h>   #define usleep(x) Sleep(x) #elif defined(__linux__)   #include <unistd.h> #endif /* coroutine.h * * Coroutine mechanics, implemented on top of standard ANSI C. See * https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html for * a full discussion of the theory behind this. */ /* * coroutine.h is copyright 1995,2000 Simon Tatham. * * Permission is hereby granted, free of charge, to any person * obtaining a copy of this software and associated documentation * files (the "Software"), to deal in the Software without * restriction, including without limitation the rights to use, * copy, modify, merge, publish, distribute, sublicense, and/or * sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following * conditions: * * The above copyright notice and this permission notice shall be * included in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND * NONINFRINGEMENT.  IN NO EVENT SHALL SIMON TATHAM BE LIABLE FOR * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF * CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. * * $Id$ */ #define ccrContParam     void **ccrParam #define ccrBeginContext  struct ccrContextTag { int ccrLine #define ccrEndContext(x) } *x = (struct ccrContextTag *)*ccrParam #define ccrBegin(x)      if(!x) {x= *ccrParam=malloc(sizeof(*x)); x->ccrLine=0;}\                          if (x) switch(x->ccrLine) { case 0:; #define ccrFinish(z)     } free(*ccrParam); *ccrParam=0; return (z) #define ccrFinishV       } free(*ccrParam); *ccrParam=0; return #define ccrReturn(z)     \         do {\             ((struct ccrContextTag *)*ccrParam)->ccrLine=__LINE__;\             return (z);\           case __LINE__:;\         } while (0) #define ccrReturnV       \         do {\             ((struct ccrContextTag *)*ccrParam)->ccrLine=__LINE__;\             return; case __LINE__:;\         } while (0) #define ccrStop(z)       do{ free(*ccrParam); *ccrParam=0; return (z); }while(0) #define ccrStopV         do{ free(*ccrParam); *ccrParam=0; return; }while(0) #define ccrContext       void * #define ccrAbort(ctx)    do { free (ctx); ctx = 0; } while (0) int task(ccrContParam) {    ccrBeginContext;    int i;    ccrEndContext(foo);    ccrBegin(foo);    for (foo->i=0; foo->i<10; foo->i++) {       usleep(1000);       ccrReturn(foo->i);    }    ccrFinish(-1); } int done(ccrContext* tasks, unsigned int *j, unsigned int num_tasks) {   unsigned int i;   int ret=1;   for (i=*j; i<num_tasks; i++) {     if (tasks[i]) {       *j=i;       ret=0;       break;     }   }   return ret; } int main(int argc, char* argv[]) {   ccrContext* tasks = NULL;   unsigned int i, j, num_tasks;   char* p;   do {     if (argc<=1)       break;        num_tasks = strtoul(argv[1], &p, 10);     if ((tasks = calloc(num_tasks, sizeof(*tasks))) == NULL)       break;     j = 0;            do {       for (i=0; i<num_tasks; i++) {         printf("#%u got number %d\n", i, task(&tasks[i]));       }     } while (!done(tasks, &j, num_tasks));   } while (0);   free(tasks);   return 0; } ;---------------------------X8 у меня в Windows XP 32bit по памяти (Virtual Size) заняло 9736К.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
	Сообщение от pavlinux (ok), 30-Ноя-24, 00:31
	Абдолноним, задание читал? "Давайте запустим N одновременных задач, где каждая задача ждет 10 секунд, а затем программа существует после завершения всех задач. Количество задач контролируется аргументом командной строки." Где ты  увидело  "корутин"
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	290. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (290), 30-Ноя-24, 13:16
	> Абдолноним, задание читал? > "Давайте запустим N одновр... Следующее предложение из оригинальной статьи ты тактично решил опустить? Или ты по-английски не бум-бум? "This time, let's focus on coroutine instead of multiple threads."
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от adolfus (ok), 05-Дек-24, 00:13
	сопрограммы -- это то же самое, что и подпрограммы, но без вложенности друг в друга. Просто работают поочередно. ПООЧЕРЕДНО. Типа, как синтаксический анализатор вызывает лексический, а то, отработав, вызывает синтаксический и все это повторяется снова и снова. В PDP11 было две инструкции -- одна ля вызова процедуры, при этом в стеке сохранялся адрес возврата, который потом  использовался при выполнении инструкции ret? и вторая, котороая вызывала процедуру, которая вместо ret вызывала первую, используя адрес в стеке, потом первая опять вторую и так далее.   Сопрограммы используются для программирования конечных автоматов (finite-state-machine). Их и придумали для этого, чтобы не городить костыли с процедурами. Собственно, любой КА использует именно сопрограммы. Либо те, что предоставляет язык, либо колхозный велосипед.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:14
	>>> Лол, какие тренера, если в C корутин вообще нет и не будет, >> Да могли бы хотя-бы и треды заспаунить каким-нибудь posix threads > Не могли бы, ибо смысл был именно в замере корутин, а не потоков. Это где такое было написано? Или это измышлизмы какого-то анонма с опеннета на тему?
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	241. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (241), 30-Ноя-24, 08:26
	> List<Task>(), goroutine, сопрограммы. Была бы задача замерять треды - замеряли бы именно треды.
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (290), 30-Ноя-24, 13:18
	> Это где такое было написано? Или это измышлизмы какого-то анонма с опеннета на тему? Это написано черным по белому буквально в начале оргинальной статьи: This time, let's focus on coroutine instead of multiple threads.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	93. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от ИмяХ (ok), 29-Ноя-24, 18:58
	>>2020 года Так уже 4 года прошло
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	152. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от bircoph (ok), 29-Ноя-24, 20:21
	Да? А мужики-то не знают: https://github.com/tidwall/neco
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	309. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (309), 30-Ноя-24, 15:27
	И про это https://gnupg.org/software/npth/index.html мужики тоже не знают. "Experience with a Windows Pth emulation showed that this is a solid way to provide a co-routine based framework."
	Ответить | Правка | Наверх | Cообщить модератору

	340. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (340), 01-Дек-24, 03:46
	Gigigi, забавно что афтар переписол редис с сишки на сишку
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	185. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (185), 29-Ноя-24, 23:37
	>в C корутин вообще нет и не будет Системный вызов fork никто не отменял.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	214. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:19
	>>в C корутин вообще нет и не будет > Системный вызов fork никто не отменял. Ну вообще-то вот именно fork(), в колличестве миллион, тебе очень врядли понравится. Особенно если это именно - форк, т.е. новые процессы. Это будет долго - и сожрет изрядно памяти. Если это lwp и какой-нибудь clone()... может быть, но можно было не выделываться и стартануть тред как нормальный человек, позиксной библой.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Овцелюб (-), 29-Ноя-24, 23:04
	> Отправлено Барашек, 29-Ноя-24 16:44 > тренера не играют Один тренер уже старенький, скоро помрет. Второй может и хотел бы поучаствовать, но никто его больше не приглашает.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	12. Скрыто модератором	–11 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 16:52
	А кому придет в голову писать современный многопоточный софт на языках из прошлого тысячелетия? Их удел это легаси, то что уже никто не будет переписывать, тк никто не знает как оно работает.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	21. Скрыто модератором	+2 +/–
	Сообщение от ijuij (?), 29-Ноя-24, 17:00
	> А кому придет в голову писать современный многопоточный софт на языках из прошлого тысячелетия? Yandex написал: https://github.com/userver-framework/userver.
	Ответить | Правка | Наверх | Cообщить модератору

	28. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 17:10
	и php.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	42. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (42), 29-Ноя-24, 17:28
	Скорее всего Rust будет наиболее близким к их результатам так что можно мысленно убавить несколько позиций от Rust и получить примерный результат C/CPP
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	183. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 29-Ноя-24, 23:15
	Да, скорее всего C++ будет наравне с Rust, но кто в своём уме станет писать асинхронщину на плюсах?
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Оценка потребления памяти при одновременном запуске миллиона..."	+3 +/–
	Сообщение от Диды (ok), 30-Ноя-24, 19:49
	Только те, кто собирается что-то написать, а не только поговорить об этом
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (45), 29-Ноя-24, 17:29
	> А где C/C++? А в C нет корутин 😂 В C++ они появились только в 2020 году. Видимо, люди как пользовались Бустом, так и продолжают пользоваться.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	55. "Оценка потребления памяти при одновременном запуске миллиона..."	+6 +/–
	Сообщение от Аноним (53), 29-Ноя-24, 17:48
	> А в C нет корутин 😂 В си есть возможность их сделать - и ест реализации. И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! > В C++ они появились только в 2020 году. Видимо, люди как пользовались Бустом, > так и продолжают пользоваться. Это какой-то не особо убедительный аргумент для обоснования результатов бенчмарка и "почему нет %s".
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (62), 29-Ноя-24, 17:53
	> Это какой-то не особо убедительный аргумент для обоснования результатов бенчмарка и "почему нет %s". А кто мешает - тебе, как больше всех "надобному"? А то ты уже минимум два поста накатал, почему и как можно было бы ... Или у тебя лапки?
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (58), 29-Ноя-24, 17:54
	>> А в C нет корутин 😂 > В си есть возможность их сделать - и ест реализации. Но в стандарте нету. А стандарт это святое! Понятно, что и на брейнфаке можно сделать, но получится брейнфачно. >  И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! Потому что у хруста 2 версии - async_std и кастомщина. Можно посмотреть и решить, стоит ли заморачиваться с токио или достаточно того что "из коробки".
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	72. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 18:07
	>> В си есть возможность их сделать - и ест реализации. > Но в стандарте нету. А стандарт это святое! Да, а почему в хрусте тогда 2 нестандартные реализации и в жабе виртуалки какие-то? Или имелись в виду - ДВОЙНЫЕ стандарты? Ну, если кому двойные стандарты святое, они конечно далеко пойдут :) > Понятно, что и на брейнфаке можно сделать, но получится брейнфачно. Это конечно мощный аргумент. А цеплять какой-то сторонний брейнфак к хрусту - не брейнфачно? Хотя как по мне последние версии плюсов и хруста за звание брейнфак-2.0 могут успешно зарубиться, если что. Некоторые на них такие конструкции заворачивают что вам даже поллитра после похода по грибы в лес - не поможет. >>  И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! > Потому что у хруста 2 версии - async_std и кастомщина. Ну так в сях тоже можно кастомщину взять было. Wtf is a difference? > Можно посмотреть и решить, стоит ли заморачиваться с токио или достаточно того > что "из коробки". Судя по этому бенчу из коробки оно "не очень" оказалось. Откуда и интерес - а как там плюсы и си выглядят в всем этом жабогадюкинге.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от morphe (?), 29-Ноя-24, 20:34
	> Можно посмотреть и решить, стоит ли заморачиваться с токио или достаточно того что "из коробки". async-std - не из коробки, это сторонняя библиотека, дефолтная стандартная библиотека не включает в себя рантайм, а лишь всё что нужно для его реализации. Де-факто стандартным рантаймом же считается tokio.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	84. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Аноним (90), 29-Ноя-24, 18:50
	> В си есть возможность их сделать - и ест реализации. И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! Потому что бессмысленно, ибо сегодня удел C - это сугубо embedded, а где ты там будешь тулить корутины?
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	276. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от laindono (ok), 30-Ноя-24, 11:32
	В чём проблема использовать корутины в embedded? Более того, они там весьма активно используются. Это ведь вариация кооперативной многозадачности.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (290), 30-Ноя-24, 13:31
	> В чём проблема использовать корутины в embedded? В том, что для stackless корутин на сях нужно юзать кучу, что затратно или вообще запрещено условной Мизрой. А для stackful корутин вообще нужна поддержка компилятора, чего в сишке нет (а с setjmp/longjmp ты сразу полючаешь UB из-за мусора в локальных переменных, если они менялись после setjmp и не были промаркированы volatile).
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от laindono (ok), 30-Ноя-24, 16:36
	Значит берём язык, который лучше подходит. Например Rust. Его корутины очень хорошо подходят в том числе и для embedded. > нужно юзать кучу, что затратно Если куча слишком дорогая выходит, то надо брать более адекватные задаче камни. Что может быть дорогого в простейшем bump-аллокаторе? В любом случае, если для решения задачи в принципе нужно кооперативную многозадачность делать, то это не самые минималистическе камни уже.
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:41
	> Потому что бессмысленно, ибо сегодня удел C - это сугубо embedded, а > где ты там будешь тулить корутины? А твое сообщение сюда, конечно же, было написано из Servo - под Redox или Fuchsia, не меньше? А если нет - тогда это wishful thinking очередного утенка, не более :)
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	133. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Страдивариус (?), 29-Ноя-24, 19:28
	> В си есть возможность их сделать - и ест реализации. И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! Сразу видно человека, который никогда не пользовался какой-нибудь из реализаций на Си, и какой-нибудь реализацией на расте. Невозможно сделать stackless корутину без помощи компилятора. Кто будет код твоей функции в конечный автомат превращать?
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	217. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:24
	>> В си есть возможность их сделать - и ест реализации. И если для хруста можно брать сторонние "фреймворки" то почему и для си так же нельзя?! > Сразу видно человека, который никогда не пользовался какой-нибудь из реализаций на Си, > и какой-нибудь реализацией на расте. > Невозможно сделать stackless корутину без помощи компилятора. Кто будет код твоей функции > в конечный автомат превращать? В сях есть setjmp/longjmp коих достаточно для - внезапно - создания корутин. Чем дофига народа и развлекается. А еще есть наконец и просто треды, позиксные или даже уже и - таки - стандартные сишные. Но, видимо, хрустикам прикольнее избивать жаб и гадюк палкой, а то от этих ведь еще и получить можно!
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Страдивариус (?), 30-Ноя-24, 20:17
	Я же тебе написал про stackless. Причем тут setjmp, чудо ты в перьях? А что касается тредов - ну создай миллион тредов, хоть позиксных, хоть сишных - посмотрю на тебя, клоун-школотрон =)
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (124), 29-Ноя-24, 19:20
	setjump - longjump.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	79. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
	Сообщение от 12yoexpert (ok), 29-Ноя-24, 18:41
	с ними график был бы некрасивый, один пиксель и С/С++ и все пиксели у остальных
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	117. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (62), 29-Ноя-24, 19:14
	> с ними график был бы некрасивый, один пиксель и С/С++ и все пиксели у остальных "Talk is cheap, show me the code!"(c)
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (159), 29-Ноя-24, 21:00
	Вышел бы за границы буфера?
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	146. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (146), 29-Ноя-24, 19:55
	А Ruby?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	251. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (251), 30-Ноя-24, 10:17
	Пожалуйста не надо, не хочу скролить страницу вбок.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (265), 30-Ноя-24, 10:40
	А common lisp, а free pascal? Интересно же глянуть как мэтры с этим справляются?!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Оценка потребления памяти при одновременном запуске миллиона..."	+16 +/–
Сообщение от Андрей (??), 29-Ноя-24, 16:45
Вот тебе и Go...
Ответить | Правка | Наверх | Cообщить модератору

	77. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Человек из глубинки (?), 29-Ноя-24, 18:35
	То что у него GC кривой - это совсем не новость.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (360), 01-Дек-24, 17:44
	А где лучше? Вы о чём.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от OpenEcho (?), 30-Ноя-24, 01:48
	> Вот тебе и Go... Абстрактный тест с нереальной задачей, и все, - разочарование... :) И вообще, приведенная Го программа этим тестировщиком, не должна компилироваться в принципе, так как содержит банальную ошибку. Люди забывают кажется уже в этой абстрактности, что есть банальное, реальное железо, в 4, 8..500 корок ЦПУ, но никак уж не 1М, даже с сетевыми задачами, где приходится ожидать, можно несколько тысяч на кор, можно даже несколько десятков тысяч если проц силен, но точно уж не миллион. Реальные задачи с одним миллионом конкурентности - это чушь, если конечно они не спешат дождаться выполнения. Такие задачи выполняются в очередях, учитывая реальное количество процессоров
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	260. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 10:29
	> Такие задачи выполняются в очередях, учитывая реальное количество процессоров А здесь, что думаешь под капотом? Там есть сет ожидающих задач, которым абсолютно нечего делать, пока что-то не произойдёт, и очередь задач которым есть что делать и они ждут процессорного времени. > Абстрактный тест с нереальной задачей, и все, - разочарование... :) Это потому что у тебя завышенные ожидания. А это, как я понимаю, из-за того что нет контекста, позволяющего правильно интерпретировать заголовок. Лет пять-десять назад было модно выкатывать демонстрации для всяких разных язычков, что этот язычок может тащить 1M коннектов. Это ассоциация номер раз, которая должна всплывать при виде заголовка. Вторая ассоциация, связанная с первой, это C10k. Все эти миллионы соединений в качестве демонстрации потенции языка родились именно из C10k. Просто железо стало мощнее, и софтовый стек лучше заточили под такое, поэтому миллион одновременных соединений тянуть не проблема. Да, делать что-то осмысленное на них может быть проблемой, потому что процессорная мощь делится на миллион, если не считать накладных расходов, но это не значит, что это бессмысленно, как полагаешь ты. Задачи разные бывают. 1M соединений может большую часть времени находится в спячке, иногда просыпаясь чтобы отправить запрос, обработка которого занимает микросекунду.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от OpenEcho (?), 30-Ноя-24, 13:22
	> А здесь, что думаешь под капотом? Там есть сет ожидающих задач, которым > абсолютно нечего делать, пока что-то не произойдёт, и очередь задач которым > есть что делать и они ждут процессорного времени. И где это там ты очередь разглядел ? :))) В банальном цикле запускается в паралель(!!!) лимон горутин, а очередь это как в магазине - две продавщицы в паралель(всего две!!!) обслуживают, а остальные в линеечку ждут > Это потому что у тебя завышенные ожидания. А это, как я понимаю, из-за того что нет контекста, позволяющего правильно интерпретировать заголовок. Ты сам то понял что сказал, телепат >  Да, делать что-то осмысленное на них может быть проблемой, потому что процессорная мощь делится на миллион, если не считать накладных расходов, но это не значит, что это бессмысленно, как полагаешь ты. Задачи разные бывают Тебе не кажется, что ты просто все переиначил и сказал тоже самое что и я?
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 17:49
	> И где это там ты очередь разглядел ? А как по-твоему рантайм шедулит таски? Рантайм делает именно то, о чём ты говоришь, берёт таски, готовые выполняться и складывает о очередь. Ты можешь заглянуть в любой такой рантайм. Хоть в libpth. > В банальном цикле запускается в паралель(!!!) лимон горутин Ты слышал про вытесняющую/кооперативную многозадачность? Открой википедию и почитай. Они не для того, чтобы выполнять что-то _параллельно_, они для того, чтобы выполнять последовательно. Чтобы параллельно нужно много процессоров, и тогда каждый из них может выполнять свой таск, и это будет параллельно. А когда один таск останавливается, чтобы выполнялся другой -- это не параллельность, это иллюзия её. То, что "многозадачность" может при этом утилизировать много процессоров осложняет ситуацию, потому что таски выполняются и в параллели тоже, но подумай вот над чем: если бы 1M тасков действительно выполнялись бы все параллельно, то есть если бы у нас был бы 1M процессоров, то какой смысл был бы разводить всю эту бодягу многозадачности с рантаймами или с ядерными шедулерами? Многозадачность в любом случае для того, чтобы выполнять не параллельно, а последовательно. > Ты сам то понял что сказал, телепат Да, а ты что нет? лол. Этот удивительный мир не прекращает подкидывать сюрпризы. Думаешь уже видел всё, и вдруг выясняешь, что настоящего дна ещё не видел. > Тебе не кажется, что ты просто все переиначил и сказал тоже самое что и я? Нет. Во-первых, ты сказал больше этого, во-вторых, ты выдрал здесь лишь одну фразу из того, что сказал я. Но, с другой стороны, если в формализмы не погружаться глубоко, то да, я сказал то же, что и ты, чтобы обозначить те утверждения, с которыми мы согласны оба. Это обычно помогает в дискуссии приходить к общему мнению, не знаю чего это ты вдруг стриггерился на этот общепринятый приём.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от OpenEcho (?), 01-Дек-24, 04:11
	>> И где это там ты очередь разглядел ? > А как по-твоему рантайм шедулит таски? Рантайм делает именно то, о чём > ты говоришь, берёт таски, готовые выполняться и складывает о очередь. О чем ты, человек ? Посмотри еще раз на исходный код программы ! где ты там шедулеры разглядел? На код смотри, а не на то, как оно там под капотом и как оно тебе кажется
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Прохожий (??), 01-Дек-24, 13:58
	>Посмотри еще раз на исходный код программы ! где ты там шедулеры разглядел? >На код смотри, а не на то, как оно там под капотом и как оно тебе кажется Так вам же написали, что шедулер обеспечивается рантаймом. Почитайте, как организованы корутины и асинхронщина в Го для начала.
	Ответить | Правка | Наверх | Cообщить модератору

	359. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от OpenEcho (?), 01-Дек-24, 16:28
	В код смотрите, специалисты. Вы в натуре не в той области тусуетесь, если думаете что всё за вас рантаймы и фрэймфорки  делать будут
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 01-Дек-24, 18:10
	> Вы в натуре не в той области тусуетесь, если думаете что всё за вас рантаймы и фрэймфорки  делать будут Ключевое слово "если". Нет, мы не думаем, что рантаймы и фреймворки за нас будут делать всё. Я думаю, это ты думаешь, что мы так думаем, но это твои особенности, держи их при себе.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от OpenEcho (?), 02-Дек-24, 13:30
	> Ключевое слово "если". Вот именно что ключевое! Смотрят в код из 10 строк, в котором на уровне языка нет никаких шедулеров и очередй, но упрямо толкуют что типа они такие крутые, что знают про магию из википедии, и о том как работают шедулеры кернела и рантайм Го, и что я просто не понимаю важность анонимных гадалок. Разговор был про код теста и там нет в этом коде ни очередей ни шедулеров, если до вас еще не дошло. И да, для того чтоб ездить на машине, надо знать только про элементы управления которые вывели для пользования, а не гадать как оно там под капотом работает. Знать концепты, да - полезно, но не гадать и не надеятся на магию. Го вполне себе низкоуровневый язык, чтоб самим заботиться о потреблении памяти и понимать реальность, что есть реальное железо, на котором можно и правда в паралель, а также есть и виртуальная обманка, на которую нельзя расчитывать в реал тайм задачах... но те кто верят в чудеса и пишут подобные тесты, сравнивая стэклесс решения с горутинами, которые приходят по умолчанию, КАЖДАЯ со стеком достойны только зарабатывать  рекламой на подобных вбросах для олухов на публичых ресурсах
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (360), 01-Дек-24, 17:46
	Абсолютно согласен. Совершенно синтетический тест: как будто никто не знал что горутины жрут много памяти из-за стека, вот это сюрприз. Такие ситуации разруливаются просто по-другому: https://github.com/valyala/fasthttp/tree/master/stackless
	Ответить | Правка | К родителю #292 | Наверх | Cообщить модератору

	382. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от OpenEcho (?), 02-Дек-24, 13:11
	> Абсолютно согласен. > Совершенно синтетический тест: как будто никто не знал что горутины жрут много > памяти из-за стека, вот это сюрприз. Такие ситуации разруливаются просто по-другому: > https://github.com/valyala/fasthttp/tree/master/stackless Да не о чем говорить и тем более спорить с людьми, которые банальный цикл не видят, зато разглагольсвуют о гипотетической магии шедулеров рантайма и тыкают в википедию, при этом вообще не понимая, что делает программа
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (282), 30-Ноя-24, 12:26
	Просто Go создаёт реальные горутины, готовые к исполнению (легковесные потоки), а остальные очередь на исполнение кода (список задач). Просто разные подходы под разные потребности.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	363. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (360), 01-Дек-24, 17:50
	Нормально всё с Go. Да, Rust лучше/быстрее/надёжнее, но вы пробовали обучить Rust'у команду мидлов за 3 месяца? А с Go всё получилось.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "Оценка потребления памяти при одновременном запуске миллиона..."	+8 +/–
Сообщение от Пью чай и греюсь пледом (?), 29-Ноя-24, 16:45
В целом шарп неплохой коспромис по производительности, удобству и кроссплатформенности.
Ответить | Правка | Наверх | Cообщить модератору

	13. "Оценка потребления памяти при одновременном запуске миллиона..."	+7 +/–
	Сообщение от ijuij (?), 29-Ноя-24, 16:54
	Вы пробовали использовать его на Debian/Ubuntu/Arch Linux? Каковы ваши впечатления?
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (18), 29-Ноя-24, 16:57
	Я не программист всех языков, в отличии от остальных комментаторов, но мои хеллоуворлды работали исправно :-)
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Оценка потребления памяти при одновременном запуске миллиона..."	+6 +/–
	Сообщение от nume (ok), 29-Ноя-24, 17:06
	Использую, проблем нет
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	38. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (38), 29-Ноя-24, 17:20
	Говорят, на .нет 9.х неплоха
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	161. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от _kp (ok), 29-Ноя-24, 21:01
	Да. В Wine никаких проблем. Зачем так? Если разработчик, и можешь собрать как угодно? Да возникла проблема с библиотекой, с открытой, и кроссплатформенной, которая нативная для Linux имела проблемы. А надо сдавать, а не в чужом и большом коде копаться. Ну сделали через Wine. Временно. А потом подумали, и нафига версии для Linux и Windows делать, если в Wine все отлично. И тут с c# все проблемы как рукой сняло. ;)
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	271. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Илья (??), 30-Ноя-24, 11:00
	> Да. В Wine никаких проблем. Но зачем, если дотнет сейчас полностью кроссплатформенный?
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:49
	>> Да. В Wine никаких проблем. > Но зачем, если дотнет сейчас полностью кроссплатформенный? Вот прямо полностью? И можно написать 1 графическую прогу на винду, линух и мак и это даже работать будет? Или у вас как обычно у майрософт - звездочки пятым шрифтом, с множествлм уточнений и подлянок?
	Ответить | Правка | Наверх | Cообщить модератору

	336. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 01-Дек-24, 00:32
	Есть AvaloniaUI и бинды на тулкиты типа gtk. Но официально, first-party как говорится, ничего, да.
	Ответить | Правка | Наверх | Cообщить модератору

	350. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Илья (??), 01-Дек-24, 11:41
	> И можно написать 1 графическую прогу на винду, линух и мак и это даже работать будет? Avalonia. Или можно вообще ксамарин попробовать, тогда ещё и с мобилками общий гуй будет
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	365. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от _kp (ok), 01-Дек-24, 20:54
	>> Да. В Wine никаких проблем. > Но зачем, если дотнет сейчас полностью кроссплатформенный? Я ж написал. Если нативная библиотека с багом, уже кроспатформенность остального не важна. Просто до следующего крупного обновления, просто так переделывать никто не станет, и тем более за даром. А с Wine можно много что перетащить, ибо свое ПО подправить быстрее, чтоб в Wine было хорошо, чем переписать, не все же на дотнет переписано.
	Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

	378. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Прохожий (??), 02-Дек-24, 07:48
	Случаем не в 1С работаете?
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	380. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от _kp (ok), 02-Дек-24, 09:45
	> Случаем не в 1С работаете? Никогда! ;)
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от AleksK (ok), 02-Дек-24, 15:53
	Ты там все ещё на 7.7 колупаешься? 1С с 2012 года имеет нативный клиент на линукс, а сервер и того раньше.
	Ответить | Правка | К родителю #378 | Наверх | Cообщить модератору

	163. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (163), 29-Ноя-24, 21:22
	Использую в арче, все устраивает. Только скорость появления новых версий в репозиториях так себе
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	200. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от мяв (?), 30-Ноя-24, 03:38
	да. mono хорошо работает. правда, в девуане были какие-то непонятки с GAC, из-за чего он не работал в 11й версии. сейчас все норм. больше скажу, даже под freebsd все хорошо.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	273. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Илья (??), 30-Ноя-24, 11:03
	> mono хорошо работает Пацаны, вы из какой криокамеры? Дотнет максимально кроссплатформенный и устанавливается в 2-3 команды на любую ОС. Моно давно в историю должен уйти
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Ан (??), 30-Ноя-24, 12:35
	Любитель телеметрии?
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от мяв (?), 30-Ноя-24, 14:49
	>вы из какой криокамеры? Вы под какими спидами? новость о переходе разработок в dotnet/runtime была где-то в середине лета, если не под его конец. в дебиане и рхел'е все так же mono.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	319. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:47
	> Вы под какими спидами? Маркетинга майкрософта сэр явно пережрал. Хотя у него в маздае оно вообще - ставится добровольно-принудительно, хрен откажешься от этого летающего макаронного монстра. > новость о переходе разработок в dotnet/runtime была где-то в середине лета, если > не под его конец. > в дебиане и рхел'е все так же mono. И гуя кроссплатформенного там нет даже в проекте. Но когда бесстыжих фанбоев MS пишущих о кроссплатформе из маздайки такое смущало? А потом эти люди почему-то удивляются что в Linux их таких - в гробу видали, и программ на этом полторы штуки за все время существования этой хтони.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от мяв (?), 01-Дек-24, 02:17
	так-то, есть GTK#, полноценная мультиплатформа: https://www.mono-project.com/docs/gui/gtksharp/ и даже смотрится хорошо: https://monodevelop.com https://wiki.gnome.org/Apps(2f)Tomboy.html но пока только GTK3, к сожалению.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 01-Дек-24, 05:08
	> так-то, есть GTK#, полноценная мультиплатформа: > https://www.mono-project.com/docs/gui/gtksharp/ > и даже смотрится хорошо: Полноценно - по какому критерию? Ни 1 программы на этом для винды - я не видел. Как тулкит дотнета - не поставляется в рамках дотнета, так что стороння штука, на правах граждан 2 сорта. GTK под виндой и без шарпея - такое себе весьма. А с шарпеем - это вообще хотя-бы собрать под винду кто-то смог? > https://monodevelop.com > https://wiki.gnome.org/Apps(2f)Tomboy.html Целая 1 приложуха? Для которой как раз написали штук пять аналогов - чтобы с нетом вообще не связываться? :) > но пока только GTK3, к сожалению. Я так и вижу завалы программ на сишарпее с GTK3 на винде. А вот почему-то программы на Qt под винду я найти могу без особых проблем. Или к вопросу о том кто тут кроссплатформенный...
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от User (??), 02-Дек-24, 07:41
	> И гуя кроссплатформенного там нет даже в проекте. Но когда бесстыжих фанбоев MS пишущих о кроссплатформе из маздайки такое смущало? А потом эти люди почему-то удивляются что в Linux их таких - в гробу видали, и программ на этом полторы штуки за все время существования этой хтони. И накой тебе тот гуй на сервере? А десктопа под онтопик один черт нет, и уже не будет - фигли под него писать? Электрон есть, им и обмазывайся.
	Ответить | Правка | К родителю #319 | Наверх | Cообщить модератору

	318. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:45
	> Пацаны, вы из какой криокамеры? Дотнет максимально кроссплатформенный и устанавливается > в 2-3 команды на любую ОС. Моно давно в историю должен уйти При том настолько максимально кроссплатформенный - что кроссплатформенного в нем UI нету от слова вообше. Фанбои майкрософта - не лучше чем сам майкрософт, тоже врут с три короба на каждом углу. И что на этой какахе делать предлагается? Веб? Это там мучительно и безблагодатно. Go какой-нибудь в 5 раз проще и компактнее, и сразу в нативный код компилится - без гигабайтов ассемблей и виртуалок.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	339. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от мяв (?), 01-Дек-24, 02:22
	>UI нету от слова вообше. есть биединги к qt и gtk. >Веб? хоть cli - с появлением AOT это больше не проблема. в гноме даже заметки были на С#. >без гигабайтов ассемблей и виртуалок. во-первых, кто и где Вам показал "гигабайты ассемблей" ? во-вторых, man ".NET AOT" >Фанбои майкрософта - не лучше чем сам майкрософт, тоже врут с три короба на каждом углу. хейтеры - тоже не ахти.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 01-Дек-24, 05:14
	>>UI нету от слова вообше. > есть биединги к qt и gtk. Но штатно майкрософт почему-то сватает совсем не это... Хотя кому-то и гражданином 2 сорта быть нормуль, конечно. >>Веб? > хоть cli - с появлением AOT это больше не проблема. Сколько я себя помню сишарперские потуги что-то делать с вебом были ужасны. В плане соотношения времени убитого на это к результату. > в гноме даже заметки были на С#. Они насколько я помню там довольно сбоку и не по дефолту в большей части дистров, и как раз вот этого написали более 5 вариантов без шарпея, как раз чтобы не таскать ацкого размера рантайм ради 1 фиговины. >>без гигабайтов ассемблей и виртуалок. > во-первых, кто и где Вам показал "гигабайты ассемблей" ? Комп на который я когда-то вьюжлстудию ставил. Незабываемый экспериенс. Полдня траха, 3 ребута, оставшиеся полдня оно дико тупило генеря ассембли. Майкрософт такой майкрософт. > во-вторых, man ".NET AOT" Да в пень, я на этом прогать не собираюсь, к счастью. >>Фанбои майкрософта - не лучше чем сам майкрософт, тоже врут с три короба на каждом углу. > хейтеры - тоже не ахти. У меня етсь причины не жаловать майков, это личное. Я отлично в курсе что они из себя представляют.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Илья (??), 01-Дек-24, 11:53
	> Сколько я себя помню сишарперские потуги что-то делать с вебом были ужасны. Можно подробнее? > Комп на который я когда-то вьюжлстудию ставил. Незабываемый экспериенс... Устанавливаешь VS Code запускаешь скрипт, который тебе доставляет дотнет https://learn.microsoft.com/ru-ru/dotnet/core/tools/dotnet-i... Запускаешь Всё занимает полчаса на любом линуксе
	Ответить | Правка | Наверх | Cообщить модератору

	351. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Илья (??), 01-Дек-24, 11:49
	> кроссплатформенного в нем UI нету от слова вообше. AvaloniaUI, Android и IOS обёртки, GTK, QT, там много чего > Фанбои майкрософта - не лучше чем сам майкрософт, тоже врут с три короба на каждом углу. Все сговорились. Но ты не проверяй, мы тебе врём, да > И что на этой какахе делать предлагается? Веб? Да > Go какой-нибудь в 5 раз проще и компактнее, и сразу в нативный код компилится - без гигабайтов ассемблей и виртуалок. Нет. На дотнете веб гораздо лучше выходит. Там с годами наработанная инфраструктура. Производительность выше.
	Ответить | Правка | К родителю #318 | Наверх | Cообщить модератору

	366. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от _kp (ok), 01-Дек-24, 20:57
	>Дотнет максимально кроссплатформенный Если что то сильно крупнее хелловордов, то оно и библиотеки использует, а там может и API чуть отличаться, и работатать чуть иначе, а  моем случае и явные баги попались.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	274. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Илья (??), 30-Ноя-24, 11:04
	> Вы пробовали использовать его на Debian/Ubuntu/Arch Linux? Каковы ваши впечатления? Примерно лучшее, что есть на сегодняшний день.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	65. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (65), 29-Ноя-24, 17:58
	А джава по памяти. Посмеялся, спасибо.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	140. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Анон1110м (?), 29-Ноя-24, 19:47
	Может всё таки не C# а .NET?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

7. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
Сообщение от Аноним (7), 29-Ноя-24, 16:49
Результаты Go поражают 🤦‍♂️
Ответить | Правка | Наверх | Cообщить модератору

	16. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от ijuij (?), 29-Ноя-24, 16:56
	Это вполне ожидаемо. Я применяю его для разработки MVP, а если продукт окажется успешным, то перепишу его на C++.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
	Сообщение от Аноним (38), 29-Ноя-24, 17:19
	А почему не раст?)
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 17:34
	> А почему не раст?) Может у человека 10-20 лет опыта плюсов и он все грабли знает наизусть. А может проекты не стоят затрат сил на обеспечение надежности и безопасности.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 09:54
	>А может проекты не стоят затрат сил на обеспечение надежности и безопасности Гугл продемонстрировал, что производительность программистов на Rust выше, чем у программистов на C++. И качество кода тоже лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Омномним (?), 30-Ноя-24, 10:22
	Вот ети все статистики работют для больших чисел. Когда есть хотя б 40-50 прогеров. Для одного единственного, может и не сработать.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:03
	>Для одного единственного, может и не сработать. Ну да, если это программист на Питоне.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Вася Пупкин (?), 29-Ноя-24, 17:41
	Замени го на питон. И плюсы на раст. и тогда все будет правильно, быстрее, удобно и надежнее.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	60. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (53), 29-Ноя-24, 17:51
	> Замени го на питон. А чего все остальные в вебе - наоборот делают? А, вы наверное продаете серваки и недовольны падением продаж?! :) > И плюсы на раст. и тогда все будет правильно, быстрее, удобно и надежнее. И заодно програмер через годик-другой сольется от постоянной гонки за скачайте ночнушку - и проект помрет. Зато можно будет продать еще серваков - уже новому лоху.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (182), 29-Ноя-24, 23:14
	А я пришёл к выводу что проще сразу писать на Rust. Скорость разработки на нём не намного ниже чем на питоне и компенсируется более качественными крейтами, тулингом, отсутствием необходимости в дебаге, безболезненной кросс-компиляцией и простым деплоем. При этом я поразился насколько питон всё-таки неэффективный. Вебсервис - io-bound говорили они, производительности питона хватит на всех, потому что всё что он делает - ждёт ответа базы. Xep там, даже мой cpаный сервис с 10RPS нагрузки, который в питоне никаких вычислений даже не производит кроме отрисовки шаблонов, на слабенькой VPS'ке грузит процессор на десятки процентов, значит у меня нет запаса под рост и пиковые нагрузки. Кроме того, каждый uwsgi воркер этого приложения жрёт 100MB+ памяти (а их нужно с десяток чтобы обработать пачку запросов без задержек). А переписывание на rust дало мне в 10-20x больше пропускной способности по stress-тестам, или 2-3x быстрее отдачу страницы под обычной нагрузкой, и 10MB памяти на ВСЁ приложение. Я, правда, уверен что не совсем корректно сравнивать синхронный flask с асинхронным axum, и скорее всего переписывание с flask на quart (а говорят оно почти бесплатное) дало бы часть профита. Но вряд-ли много, потому что загрузка CPU под стресс тестами 100%, значит больше он не вытянет. Памяти меньше будет есть, это да, ну и может немного оверхеда сэкономится на переключение между процессами. Поэтому я уж лучше сразу на Rust, особенно при всех его остальных профитах.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	275. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Илья (??), 30-Ноя-24, 11:19
	> Скорость разработки на нём не намного ниже чем на питоне На питоне в итоге худшая скорость разработки получается. Там скорость чтения кода очень низкая. Хрупкий, куски кода часто приходится переписывать с нуля. Я думал, от питона сознательные люди отказались давно
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:52
	>> Скорость разработки на нём не намного ниже чем на питоне > На питоне в итоге худшая скорость разработки получается. > Там скорость чтения кода очень низкая. Хрупкий, куски кода часто приходится переписывать > с нуля. Я думал, от питона сознательные люди отказались давно А чтобы не скучали - в каждой новой версии что-нибудь ломают или меняют. В какой-то момент Гвидо наконец и самого припекло жить на вулкане, он сказал что устал и уходит, свалив с трона.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Илья (??), 01-Дек-24, 11:55
	Питон вообще одноразовым у нас считался. Ребята пишут код, потом вместо того, чтобы баги править всё с нуля переписывают. Хз, для каких проектов его используют, думаю, люди сами себе не враги, чтобы так мучиться
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от _kp (ok), 01-Дек-24, 21:03
	> Скорость разработки на нём не намного ниже чем на питоне Странно, после Питона что угодно быстрее. Точнее, чем больше ПО, тем медленнее и труднее его разработка на Питоне, а для небольших повседневных скриптов конфетка. Скриптов замечу, где с данными можно манипулировать как угодно, затратив минимум времени на написание.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	385. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:15
	> flask Товарищ разработчик! Настоятельно рекомендуем смотреть на дату, когда вы что-то читаете на stack overflow. Питон, конечно не быстрый, но 10 rps на простых шаблонах, это надо умудриться. Даже на фляжке. FastAPI и jinja2 спасут отца русской демократии. Хотя там тоже можно упорото промахнуться, но я надеюсь, что шаблон проекта можно найти без проблем. > каждый uwsgi воркер этого приложения жрёт 100MB+ памяти То есть ты, на каждый запрос, поднимешь новый инстанс питона и удивляешься, что оно жрёт много памяти и работает медленно? Тогда предлагаю пойти дальше, развернуть кубер и поднимать сразу отдельный под. Чо уш мелочиться...
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	199. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (199), 30-Ноя-24, 03:04
	> если продукт окажется успешным, то перепишу его на C++ ... и окажешься первым на планете, кто гошное приложение переписал на плюсы, а не просто докупил железа. Хотя, возможно, это потому, что окажешься первым, кто написал на го УСПЕШНЫЙ продукт...
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	206. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (206), 30-Ноя-24, 03:55
	>применяю его для разработки MVP, Почему не matlab?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

8. "Оценка потребления памяти при одновременном запуске миллиона..."	+5 +/–
Сообщение от Пью чай и греюсь пледом (?), 29-Ноя-24, 16:49
Кстати, ноде вообще пофиг, она тут лидер по стабильности :-)
Ответить | Правка | Наверх | Cообщить модератору

	168. "Оценка потребления памяти при одновременном запуске миллиона..."	+3 +/–
	Сообщение от th3m3 (ok), 29-Ноя-24, 21:48
	Сливает даже Питону)
	Ответить | Правка | Наверх | Cообщить модератору

	323. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:53
	> Сливает даже Питону) Жабогадюкинг как он есть )
	Ответить | Правка | Наверх | Cообщить модератору

10. "Оценка потребления памяти при одновременном запуске миллиона..."	–9 +/–
Сообщение от Аноним (-), 29-Ноя-24, 16:51
Java тормознутая. Легенда о тормознутости Жабы доказана. Что и требовалось доказать.
Ответить | Правка | Наверх | Cообщить модератору

	22. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (18), 29-Ноя-24, 17:00
	Ты вообще читал новость? 🤦
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (90), 29-Ноя-24, 18:58
	Да он даже заголовок не осилил 😂
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (37), 29-Ноя-24, 17:19
	Ты различаешь скорость работы и жручесть памяти? По скорости ява вполне сравнима даже с компилируемыми в нативщину языками, а вот по жручести памяти полное днище. Это было основное, что мне в ней крайне не нравилось.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	88. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (88), 29-Ноя-24, 18:55
	Жручесть памяти в JVM это примерно как жручесть памяти в Линукс. Новички тоже порой удивляются — почему Линукс использует почти 100% оперативки во время работы. Но это и не удивительно, «VM» в акрониме «JVM» как бы намекает, но не все намёк поняли, и уж тем более не все дочитали до конца мануал как объяснить JVM сколько памяти ей доступно. Да и зачем вникать, когда можно просто повторять услышанное ща гаражами от старших пацанов и прослыть сведущим человеком? Для примера, у меня есть в проде микросервис на Яве с потреблением памяти в районе 128 MB, при этом каждый инстанс перемалывает пару сотен мегабит трафика в секунду. Перемалывали бы и больше, но бэкэнд не успевает так быстро токены валидировать. Что иронично, бэкэнд на C++, но проблема конечно же не в языке реализации, а в том что БД за ними не успевает.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Анон1110м (?), 29-Ноя-24, 19:49
	Пользовался IDE на Java и по ощущениям — сплошные тормоза.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:55
	> Пользовался IDE на Java и по ощущениям — сплошные тормоза. Да что там, Arduino - по уровню фич чуть лучше нотпада, ну ладно, может на уровне Mousepad какого-нибудь микроскопического. Но тормозит и лагает эта лабуда - как Qt Creator какой, только этот - мощный дредноут для разборки с проектами космического масштаба, а ардуино - так, блокнотик с прошивалкой.
	Ответить | Правка | Наверх | Cообщить модератору

	379. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от anon111 (?), 02-Дек-24, 07:49
	Поставь 1.8. Тормоза добавили с 2.0.
	Ответить | Правка | Наверх | Cообщить модератору

	386. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:17
	Специально?
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от microcoder (ok), 30-Ноя-24, 10:21
	> Ты различаешь скорость работы и жручесть памяти? Жручесть памяти = выделение памяти, а выделение памяти это процессорное время + время на GC, что является "лишними" вычислениями, а равно - ТОРМОЗНУТОСТИ. Эта простая формула.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	69. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (65), 29-Ноя-24, 18:00
	Какие легенды? Это ещё деды в учебники по физике записали.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

11. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
Сообщение от Шарп (ok), 29-Ноя-24, 16:52
По сути c# с AOT победитель, потому что память потребляет чуть больше раста, но при этом является нормальным языком без необходимости приседать с borrow checker.
Ответить | Правка | Наверх | Cообщить модератору

	15. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (18), 29-Ноя-24, 16:55
	В долгосрочной перспективе победитель нода :-) Потому что вообще не надо конпилять, уже занимает львиную долю рынка и относительно простая в плане освоения. Но шарп хорош тем, что он не только для вэба.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Rev (ok), 29-Ноя-24, 17:13
	Ага, а дистрибутивы продукта занимают гигабайты, состоя из 30000 файлов. Нода - самый отстой из всего. На втором месте руби.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от анонимище (?), 29-Ноя-24, 17:40
	а Руби чем вам не угодил?
	Ответить | Правка | Наверх | Cообщить модератору

	387. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:19
	Руби не смог занять нишу и находится в режиме заката.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Оценка потребления памяти при одновременном запуске миллиона..."	–4 +/–
	Сообщение от НяшМяш (ok), 29-Ноя-24, 17:41
	Пакет ноды занимает 50-60 мегабайт в моём дистрибутиве после распаковки. Даже меньше, чем питон. Найти приложение на ноде с гигабайтами исходников надо ещё постараться. Да и есть кучи компилеров, транспилеров и бандлеров, чтобы это всё упаковать в компактный вид.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	145. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Анон1110м (?), 29-Ноя-24, 19:51
	Это всё без разницы потому что ЯваСцэнарий один из худших языков на планете.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от fuggy (ok), 29-Ноя-24, 22:40
	Легко средний проект занимает 50-90К файлов. Всё это добро занимает 400-700МБ. И это только исходники. Ведь каждый пакет это однострочная функцию, к которой в комплекте source map, файл лицензии, readme, changelog, тесты, данные для тестов. И всё это только для одного пакета из одной функции. И таких пакетов тысячи.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	126. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (124), 29-Ноя-24, 19:23
	Нет, не самый. Есть ещё Electron - это нода вместе с движком от Хромиума...
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	242. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Илья (??), 30-Ноя-24, 08:44
	> Нода - самый отстой из всего. На втором месте руби. питон ужасен
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	100. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Олололололололо (-), 29-Ноя-24, 19:02
	Любой проект на ноде тащит за собой миллиарды миллиардов файлов с npm сайта. Кто-то проверят, что в этих файлах понаписали? Нет, нет и нет. В результате если писать хоть сколько либо серьёзный проект на ноде нужно писать всё с нуля и не использовать ни одного пакета с npm,  а так на ноде не бывает.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	203. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (203), 30-Ноя-24, 03:51
	Разве язык виноват в том, что репозиторий превратился в пoмoйку? Не хочешь тащить вacянскиe библиотеки и фреймворки? — Пиши с нуля. (вопреки популярному мнению среди смyзиxлeбoв, это не самая худшая практика)
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (265), 30-Ноя-24, 10:23
	Вот это походу и называется дэпэндэнси хэл
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	258. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от microcoder (ok), 30-Ноя-24, 10:27
	> Кто-то проверят, что в этих файлах понаписали? Нет, нет и нет. Кто-то Винду проверяет что там понаписано? А Линукс, где десятки тысяч пакетов от "васянов", кто это всё проверяет, каждую строчку, что там понаписано?
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	335. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (335), 01-Дек-24, 00:24
	>Кто-то Винду проверяет что там понаписано? А как её проверишь? Не проверишь даже при остром желании.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 01-Дек-24, 14:06
	Вообще-то код Винды можно получить для аудита. Но для этого надо иметь веские основания. Например, вы - госучреждение какое. Или работаете на правительство.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Liin (ok), 30-Ноя-24, 13:36
	> Кто-то проверят, что в этих файлах понаписали? Нет, нет и нет. Конечно проверяют, случаи выпиливания троянов известны. А Вы думаете в других открытых проектах по-другому? Наивный Вы, конечно. Погуглите, к примеру, недавний случай с XZ backdoor.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	188. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от turbo2001 (ok), 30-Ноя-24, 00:06
	Сам тест у C# тоже любопытный, это тест миллиона таймеров, а не задач.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	201. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от мяв (?), 30-Ноя-24, 03:41
	тоже хотела написать. и самое интересное, уровень портабельности идентичный, ибо оба на LLVM.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	227. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (227), 30-Ноя-24, 04:40
	Вот совсем не ожидал того что .NET выступит настолько достойно!
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	232. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Andrey (??), 30-Ноя-24, 07:19
	Но при желании в шарпе можно будет с ref поприседать.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	246. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от мяв (?), 30-Ноя-24, 09:28
	а Вы в курсе вообще, что такое ref? "поприседать" можно будет с unsafe-контекстами. а ref - вполне безопасная и простая вещь.
	Ответить | Правка | Наверх | Cообщить модератору

14. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
Сообщение от Аноним (14), 29-Ноя-24, 16:55
> Some folks pointed out that in Rust (tokio) it can use a loop iterating over the Vec instead of join_all to avoid the resize to the list introduced by join_all. So I added a new test case Rust (tokio-for) here Как всегда с Растом: если просто использовать API как обычно, без тайного знания, всё будет неоптимально
Ответить | Правка | Наверх | Cообщить модератору

	31. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Rev (ok), 29-Ноя-24, 17:14
	Это не тайные знания, это понимание базовой функциональности.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Вова (?), 01-Дек-24, 21:39
	Чушь не пиши! Если задача решена "в лоб" (очевидными классами) и она тормозит, значит разрабы ПЛОХО работали над оптимизацией. Для того ЯОНы и придумали, чтобы НИКОГДА не лезть "под капот" и что-то там химичить с битами/указателями ради выжимания герц.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Оценка потребления памяти при одновременном запуске миллиона..."	–5 +/–
	Сообщение от Аноним (32), 29-Ноя-24, 17:15
	Rust (async_std) Стандартная библиотека
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	64. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (62), 29-Ноя-24, 17:57
	> Как всегда с Растом: если просто использовать API как обычно, без тайного знания, всё будет неоптимально То ли дело сишка или плюсы с их стандартными либами, да?
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

19. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Ананий (?), 29-Ноя-24, 16:59
Як так, почему пихон жрёт меньше гошечки?
Ответить | Правка | Наверх | Cообщить модератору

	61. "Оценка потребления памяти при одновременном запуске миллиона..."	+8 +/–
	Сообщение от Аноним (53), 29-Ноя-24, 17:53
	> Як так, почему пихон жрёт меньше гошечки? Ползает медленно, энергии много тратить не надо. Сожрал себе что-нибудь и переваривает неделю. А у go вы видели логотип? Он и носится в своем колесе до упаду, жрать хочет чаще.
	Ответить | Правка | Наверх | Cообщить модератору

	66. Скрыто модератором	+2 +/–
	Сообщение от анонимище (?), 29-Ноя-24, 17:59
	блин, я только что понял что Python и Go находятся в отношении Хищник - жертва
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Оценка потребления памяти при одновременном запуске миллиона..."	+8 +/–
	Сообщение от Аноним (82), 29-Ноя-24, 18:44
	потому что в приведенном бенчмарке питон создает пустые коллбэки на однопоточном эвентлупе (тоесть внутри питоно-тасок нельзя вызывать ничего вычистительно тяжелого\блокирующего, это просто стейт-машина) а в гошечке куда более мощных рантайм, который все эти проблемы решает и горутины могут и вычислять и блокировать, а рантайм их по ядрам процессора распределяет полноценные грин-треды некорректно так сравнивать
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	388. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:28
	Так тут на всех языках пустые колбэки, которые ничего не делают. Этот тест меряет память. У гошки большие проблемы при создании множества горутин, она на это не рассчитана.
	Ответить | Правка | Наверх | Cообщить модератору

23. "Оценка потребления памяти при одновременном запуске миллиона..."	+5 +/–
Сообщение от Аноним (23), 29-Ноя-24, 17:04
>при одновременном запуске миллиона задач А что там по одновременному выполнению миллиона задач?
Ответить | Правка | Наверх | Cообщить модератору

	39. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (38), 29-Ноя-24, 17:24
	Вы про корутины начитались что ли?
	Ответить | Правка | Наверх | Cообщить модератору

51. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Дед Анон (?), 29-Ноя-24, 17:42
А где PHP? Хотелось бы посмотреть на фоне Go
Ответить | Правка | Наверх | Cообщить модератору

	74. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Anyone (?), 29-Ноя-24, 18:32
	В РНР уже завезли сопрограммы без костылей?
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 20:04
	плюсы-расширения подойдут?
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 29-Ноя-24, 20:16
	ну, все свои классы и эррейры основные через плюсы компилить и в пхп-экстеншн_со класть - так проще и, возможно, производительней. у меня прод не паблик многоК+, однозначно сказать не могу.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	172. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Hck3r (?), 29-Ноя-24, 22:20
	Давно завезли
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	174. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 29-Ноя-24, 22:25
	Fibers (stackful coroutines) начиная с версии 8.1
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

59. "Оценка потребления памяти при одновременном запуске миллиона..."	+5 +/–
Сообщение от аНОНИМ (?), 29-Ноя-24, 17:51
То есть это не про процессы и даже не про OS-треды, а про какие-то у каждой пепяки собственные симулякры. Значимость=0
Ответить | Правка | Наверх | Cообщить модератору

	76. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 18:33
	Если ты кликнешь на ссылку на прошлогодний тест, то там тестируются и ядерные треды, но результаты для них показаны только для 10k задач, а для 100k уже написано "I could not launch 100,000 threads on my system, so the threads benchmarks had to be excluded. Probably this could be somehow tweaked byt changing system settings, but after trying for an hour I gave up." Я не знаю, сколько там современный десктоп вытянет ядерных тасков, но давным-давно, ещё на кор2дуо, я игрался с форк-бомбой (мне было очень интересно, можно ли анти-форк-бомбу подорвать рядом с форк-бомбой, чтобы вторая потушила бы первую), и нну я скажу это такие тормоза системы...
	Ответить | Правка | Наверх | Cообщить модератору

	389. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:34
	Миллион процессов в системе? Хорошо, что не перевелись ещё эксперты на опеннете...
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

75. "Оценка потребления памяти при одновременном запуске миллиона..."	+4 +/–
Сообщение от Аноним (82), 29-Ноя-24, 18:32
Автор не понимает как устроен tokio-runtime и как им пользоваться Автор создал мильен футур, которые ничего не весят и не делают, по-сути мильен пустых коллбэков (только ждут события таймера от epoll\etc) по-дефолту в tokio сейчас включен multi_threaded_runtime, и, чтобы использовать который, простых футур недостаточно, а нужно использовать специальный апи task::block_in_place https://docs.rs/tokio/latest/tokio/task/index.html#block_in_... чтобы на честных условиях сравниваться с Java VirtualThreads и с горутинами Golang
Ответить | Правка | Наверх | Cообщить модератору

	92. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от jobserver (ok), 29-Ноя-24, 18:57
	интересно каким будет на расте правильное потребление памяти
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от chdlb (?), 29-Ноя-24, 19:12
	неа, виртуальные потоки в джава это не реальные потоки, так что хоть это не одно и тоже, то что ты пишешь не будет реальным соотвествим читай что я ниже пишу про Java и С# не понимаю кто притянул сюда этот говнотест
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	157. "Оценка потребления памяти при одновременном запуске миллиона..."	+4 +/–
	Сообщение от morphe (?), 29-Ноя-24, 20:42
	> нужно использовать специальный апи task::block_in_place Кому нужно? Замени таймер на сеть - и вот у тебя обрабатывается сеть, без всяких block_in_place, а именно что через ожидания событий от epoll. Тут сравниваются стеклес корутины (Rust/C#), которые потребляют ровно столько памяти сколько им нужно, и не байтом больше, и стекфул корутины (зелёные потоки/горутины/VirtualThread), которые резервируют под каждую свой виртуальный стек И разумеется стеклес в C#/Rust выходят дешевле чем зелёные потоки, и разницы тут не будет между таймером/сетью/прочим работающим через epoll
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	334. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Kuku (?), 30-Ноя-24, 23:58
	Наконец-то, хоть один человек сообразил, в чем причина
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 02-Дек-24, 23:36
	Этот комментарий надо вставить в статью.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

78. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
Сообщение от Аноним (78), 29-Ноя-24, 18:40
Я разочарован питоном :(
Ответить | Правка | Наверх | Cообщить модератору

	98. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от anonymous (??), 29-Ноя-24, 19:00
	python оказался довольно удобным калькулятором с подходящим набором инструментов - jupyter и pandas.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:09
	Некоторые считают pandas тормознутым и с кривым API, переходят на polars поэтому.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 29-Ноя-24, 19:35
	Питон прекрасен для прототипов, для любых. Но тащить его в нагруженный прод... Сил этим героям.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	166. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (78), 29-Ноя-24, 21:32
	>тащить его в нагруженный прод Ты будешь удивлен, но питон именно в проде в дохерище крупнейших проектах. Погуглить за тебя?
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:30
	> Ты будешь удивлен, но питон именно в проде в дохерище крупнейших проектах. > Погуглить за тебя? Зачем?! Достаточно сказать что гугл сделал го - для замены у себя в проде питона :). Это все что надо знать о использовании питона в проде и его производительности.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от чатжпт (?), 30-Ноя-24, 10:31
	Зачем это (замена питона на го) гуглу понятно, с их нагрузками. Зачем это остальным - не понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 19:59
	> Зачем это (замена питона на го) гуглу понятно, с их нагрузками. Зачем > это остальным - не понятно. Затем что у них денег (на сервера и проч) - еще меньше чем у гугеля. Вон там тушка с VPSкой отписал как оно. Первое же минимальное нашествие ботов, да даже чуть ли не активировавшиеся к ночи краулеры - положит сервак на лопатки с такой нагрузочной способностью. Да и фреймворки на питоне - ужасные и все сложно и криво. Так что в вебе питон по сути вымер, и игогошка его там пылающим мечом просто косит. Все знакомые пыхпшники и питонисты на это в вебе свалили.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (169), 29-Ноя-24, 21:53
	Проблема не в самом питоне, и даже не в том, что он интерпретируемый. Если хотите понять, почему дефлотные библиотеки (и подавляющее большинство того, что пишут вокруг них, потому что одни и те же примитивы использую) - говно, посмотрите, что cpython делает, когда вы, хз, строки пополам пилите, или делаете ещё какие-то операции, которые не меняют память, а только меняют начало и конец объекта, который ДОЛЖЕН БЫЛ БЫТЬ просто двумя указателями. При этом некоторые методы объектов ВНЕЗАПНО работают эффективнее, хотя выглядит это как полный бред (гуглите сравнение скорости слайсинга bytearray через [1:] и del [0])
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	240. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (240), 30-Ноя-24, 08:25
	Проблема что в реальной жизни и реальных веб задачах производительность языка не имеет значения потому что упираешься в производительность базы данных, а не кода. Даже на пхп. Все эти задачи вычисления пи на скорость имеют мало отношения к реальной жизни. Причем никто не пишет бенс на каком языке лучше всего написать базу данных. Там итак все без тестов понятно. И языка на котором написаны все нормальные базы данных в сабже например вообще нет.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:13
	>нормальные базы Их нормальность часто заключается только в богатстве функциональности, а не в стабильности работы. То есть, это ограниченное понимание.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (268), 30-Ноя-24, 10:49
	Ну раз тебе функционал не нужен пиши данные своего Фейсбука в редис и скидывай на диск. Рано или поздно все равно наступит предел производительности.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:49
	Где я сказал, что функциональность не нужна? Я просто заметил об ограниченности понимания этого термина предыдущим высказывающимся.
	Ответить | Правка | Наверх | Cообщить модератору

83. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от jobserver (ok), 29-Ноя-24, 18:45
java 8ГБ. его тест на java для 10_000_000 зелёных потоков.
Ответить | Правка | Наверх | Cообщить модератору

	111. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от chdlb (?), 29-Ноя-24, 19:10
	этот тест кал читай ниже а в джаве виртуальные потоки фиг пойми сколько будут создавать реальных потоков в ОС
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 29-Ноя-24, 19:14
	здесь про корутины посты уместны?
	Ответить | Правка | Наверх | Cообщить модератору

95. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
Сообщение от RM (ok), 29-Ноя-24, 18:58
Erlang нет, нещитово
Ответить | Правка | Наверх | Cообщить модератору

96. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от chdlb (?), 29-Ноя-24, 18:59
Я может чего-то не понимаю, но вот это: int numTasks = int.Parse(args[0]); List<Task> tasks = new List<Task>(); for (int i = 0; i < numTasks; i++) {     tasks.Add(Task.Delay(TimeSpan.FromSeconds(10))); } await Task.WhenAll(tasks); вызовется на ThreadPool, а у него есть максимальный размер, что-то не вижу я кода увеличивающий пул притом Task.Delay ничего не делает, только асинхронно ждет НЕ БЛОКИРУЯ поток, правильнее было бы запустить Thread.Sleep, но в других языках похожи подходы, например Rust тоже не блокирует поток, но даже если тесты эквивалентны, то что они тестируют? производительность DFSM для тасков? бред кстати здесь нет capcacity для листа, т.е. они плюсуют время на релокейшен внутреннего массива для листа (4,8,16,32) и тд, это же лютая дичь, плюньте в морду тем кто писал такие тесты смотрите, я поменял код на такой чтобы подтвердить свои изыскания for (int i = 0; i < numTasks; i++) {     tasks.Add(Task.Run(() => {         Console.WriteLine(ThreadPool.ThreadCount);     })); } Output: 4 4 5 5 16 16 16 6 16 7 16 8 16 9 16 16 16 16 16 10 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 он уперся в 16 ядер которые у меня есть и точка
Ответить | Правка | Наверх | Cообщить модератору

	171. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 29-Ноя-24, 22:15
	> смотрите, я поменял код на такой чтобы подтвердить свои изыскания > он уперся в 16 ядер которые у меня есть и точка Не убедительно. Твои потоки могут жить нетривиальное время только если они будут блокироваться на Console.WriteLine. Я не знаю, что это за язык, тем более я не знаю как там у тебя рантайм себя ведёт в таких ситуациях, и может там Console.WriteLine асинхронный? Хотя нет, наверное, не асинхронный, await'а то нету, так? Но я к тому, что твой пример нисколько не убеждает меня в том, что рантайм просто не видит смысла прерывать только что запущенный гринтред, чтобы запустить ещё один. Он их последовательно запускает и выполняет: рантайм естественным образом оптимизирует задачу сформулированную тобою, потому что ты не озаботился создать ему сложностей, через которые его оптимизатор не прорвётся и не сможет редуцировать твою задачу до банального цикла (в твоём случае банальных 16 циклов выполняющихся параллельно). Верни Task.Delay взад, и посмотри что будет. Причём, я думаю, именно Task.Delay, а не Thread.Sleep: что-то мне подсказывает, что каждый Thread.Sleep просто подвесит тебе один из ядерных потоков пула потоков, и когда ты сделаешь 16 Thread.Sleep, у тебя все потоки пула повиснут, и рантайм встанет колом. Сравниваются _асинхронные_ рантаймы, поэтому в качестве примера берутся задачи, которые ничего не делают, но зато асинхронно получают одно событие ("таймер истёк"). Без таймера или другого источника асинхронных событий там никак, потому что есть шансы получить что-то типа твоего результата. Надо как-то убедить рантайм, что таск надо перевести в состояние WAITING.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 22:40
	Лол, так ThreadPool.ThreadCount это же количество ядерных потоков в пуле, так? Их *естественно* будет столько сколько ядер или может чуть больше чем ядер. Нет никакого смысла увеличивать дальше, даже более того есть огромный смысл не увеличивать, чтобы снизить нагрузку на ядерный шедулер, который со всеми его расчётами приоритетов и переключением между kernel и user spaces только процессорные такты жрёт. Так что у меня есть уверенный ответ на: > Я может чего-то не понимаю Да, ты вообще ничего не понимаешь. Несёшь какую-то чушь, пытаясь увидеть миллион ядерных тредов там, где речь про миллион асинхронных тасков, выполненных гринтредами.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	189. Скрыто модератором	+/–
	Сообщение от chdlb (?), 30-Ноя-24, 00:21
	это был риторический вопрос, но не суть... -- тебя никто не спрашивал есть смысл или нет и их будет столько сколько засетишь, по умолчанию равно В ТОЧНОСТИ количеству ядер public static bool SetMaxThreads (int workerThreads, int completionPortThreads); --- "одновременном запуске миллиона задач" (заголовок статьи) и "создание экземпляров тасков" не равнозначные вещи, особено учитывая то, что в некоторых других языках накодили во-первых не одновременное выполнение, во вторых это не выполнение задачи, пока таск не получил управление потоком хотя кому я говорю, ты же местный смешила )))
	Ответить | Правка | Наверх | Cообщить модератору

	252. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 10:17
	> тебя никто не спрашивал есть смысл или нет А я ответил, вот и живи теперь с этим. > во-первых не одновременное выполнение, во вторых это не выполнение задачи, пока таск не получил управление потоком Одновременное, миллион таймеров выполняется одновременно. Точно так же, одновременно может выполняться ожидание на миллионе сокетов. Асинхронность она именно о том, чтобы распараллелить ничегонеделанье. > хотя кому я говорю, ты же местный смешила ))) Давай, добавь ещё личностных атак, может от этого ты перестанешь выглядеть таким тупым?
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (331), 30-Ноя-24, 20:56
	Ты немного путаешься в понимании. Task.Delay как раз используется, чтобы показать, как система обрабатывает большое количество асинхронных операций без блокировки потоков. Это тестирование способности управления задачами, а не ThreadPool. Thread.Sleep тут вообще неуместен, потому что он блокирует поток, ломая саму идею асинхронности. Лимит в 16 потоков связан с количеством ядер, но к тесту он не имеет прямого отношения — тест про управление задачами, а не про пределы ThreadPool.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	371. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от chdlb (?), 01-Дек-24, 23:01
	Ну откуда вы лезете? > Ты немного путаешься в понимании. В понимании кого/чего? Тебя? ОК согласен. > Task.Delay как раз используется, чтобы показать, как система обрабатывает большое количество асинхронных операций без блокировки потоков. Delay там, чтобы таск не завершался мгновенно, и всего то. Даже если бы его не было, то все равно были бы созданы все экземпляры тасков. Delay в теле вообще не определяет полное время жизни, только время "не менее чем", но верхняя планка задается реальным временем выполнения на ThreadPool (и создание тасков тоже кстати от него зависит). Поток все равно должен взять на себя completed task и вернуть управление to caller. И чем больше потоков участвует в этом, тем быстрее будет это происходить. > Это тестирование способности управления задачами, а не ThreadPool. Много тасков это не "одновременном запуске". Читай заголовок статьи. Даже в оригинале автор теста пишет "concurrent", но это вранье - asynchronous не равно concurrent! Более того виртуальные потоки Java не соответствует концепции тасков и пула потоков в шарпе. В каждом из языков внутри свой механизм под капотом, настолько отличные, что происходит сравнение ужа с бегеметом. В общем это тестирование подкожного творожка, может даже с натяжкой ДКА в async, или еще чего, но точно ни того не другого, что ты упоминаешь. > Thread.Sleep тут вообще неуместен, потому что он блокирует поток, ломая саму идею асинхронности. Вот это новость, т.е. когда таск у тебя реально выполняет работу на потоке, и поток занят, но не Thread.Sleep, а реальной числодробилкой, то код "ломает саму идею асинхронности"? поржал ))) Асинхронность никуда не исчезает, она по-прежнему существует. Такое поведение лишь означает, что у тебя потоки пула, будут дольше заняты, перед тем как начнут обрабатывать другой таск. И чем больше у тебя потоков в пуле, тем более параллельно будут выполняться задачи, кроме тех, конечно которые просто ждут IO (через Completion Ports в винде или epoll/io_uring в Linux). > Лимит в 16 потоков связан с количеством ядер, но к тесту он не имеет прямого отношения — тест про управление задачами, а не про пределы ThreadPool. Ты видать не в курсе что таски создаются и выполняются на потоках из ThreadPool? Даже если просто ждут таймера, для них все равно используется этот пул, само собой что на время ожидания поток освободится. Но ничего кроме thread pool для их выполнения не участвует. И масштабируемость по задачам НАПРЯМУЮ зависит от капасити пула, при этом объем памяти будет сильно зависеть от того сколько обрабатывается тасков конкурентно, а еще от того сколько тасков оно успеет создать конкурентно, до того момента, когда они начнут освобождать свои ресурсы, на что помимо делея в 10 мс будет влиять все тот же thread pool (сам же объект таска конечно никуда не исчезнет пока лежит в листе). Я уже писал, что 16 потоков это дефолтовые значение от количества SMT ядер. Все, не могу твой бред больше коментировать...
	Ответить | Правка | Наверх | Cообщить модератору

	399. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (399), 10-Дек-24, 12:39
	Ты вообще не понимаешь, что такое асинхронность
	Ответить | Правка | Наверх | Cообщить модератору

	401. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от chdlb (?), 11-Дек-24, 11:12
	> Ты вообще не понимаешь, что такое асинхронность ты не понимаешь, что такое логика и интеллект
	Ответить | Правка | Наверх | Cообщить модератору

120. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Пишу с 3 пня (?), 29-Ноя-24, 19:16
Интересно бы сравнить все это на старом железе типа 3 пня без читерства в виде задействованных инструкций.
Ответить | Правка | Наверх | Cообщить модератору

160. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (160), 29-Ноя-24, 21:00
Ну-ну очередное сравнение мягкого, пушистого и розового? Запустили бы хотя бы что-нить посчитать в этих задачах, даже 2+2 и то было был бы маленький, но смысл, а так вообще дурoсть, для любителей обсасывать дурoсти.
Ответить | Правка | Наверх | Cообщить модератору

	173. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 29-Ноя-24, 22:24
	Асинхронный рантайм не для того, чтобы считать, он для того, чтобы мультиплексировать ввод/вывод. С расчётами туго, потому что они по-сути блокирующие операции, и их бы лучше выносить из рантайма вон. Понятно, что из-за 2+2 никто так не заморачивается, но если твой код зависнет считать что-то на секунду, то один ядерный поток пула потоков будет целую секунду заниматься твоими расчётами, а все асинхронные задачи будут проталкиваться через остальные ядерные потоки, и вытеснить заблокированный не будет никакой возможности. В рантаймах попроще в очереди этого заблокированного потока могут стоять задачи, которые будут тупо ждать. В более сложных рантаймах потоки могут steal'ить задачи из чужих очередей, но даже это не гарантированно, это если им заняться будет нечем. Асинхронный рантайм не для того, чтобы считать, он для того, чтобы мультиплексировать ввод/вывод. Запомни это.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:22
	>С расчётами туго, потому что они по-сути блокирующие операции Это зависит от того, как многозадачность реализована. Если она кооперативная (потоку даётся квант времени на работу, потом переходим к следующему потоку), ничего там блокироваться не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 12:16
	> Если она кооперативная (потоку даётся квант времени на работу, потом переходим к следующему потоку) Если потоку даётся квант времени и рантайм/ядро отнимает управление у потока по истечении этого кванта, то это вытесняющая многозадачность (поток вытесняется). Кооперативная, это когда поток кооперирует с рантаймом и другими потоками и сам отдаёт управление. В асинхронных рантаймах используется именно кооперативная многозадачность, потому что с ней меньше накладных расходов на организацию всего этого хозяйства. А это значит, что если гринтред сделает while(1);, то весь рантайм встанет колом без какой-либо возможности продолжить работу.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:12
	Определение термина кооперативной (вытесняющей по-вашему) многозадачности я взял из одной статьи про асинхронщину в Rust. Собственно, не в термине суть. Кажется в Го или Свифт такое было реализовано. В смысле такой планировщик потоков (корутин). Но я не специалист по этим языкам. Пересказываю то, что прочитал. А так - да, вы правы. В том же Питоне асинхронная функция станет колом, если начнёт что-то вычислять.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Диды (ok), 30-Ноя-24, 20:07
	>Определение термина кооперативной (вытесняющей по-вашему) многозадачности я взял из одной статьи про асинхронщину в Rust Пропал дом (с)
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 02-Дек-24, 04:38
	Вам шашечки или ехать? (c)
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (206), 30-Ноя-24, 07:35
	Зачем создавать пул потоков, что за странная идея? Пусть ядро занимается тем, что оно хорошо умеет: управляет потоками.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

	280. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 12:23
	Ядро очень медленно стартует потоки. Лучше стартануть их однократно, и потом многократно использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (206), 01-Дек-24, 08:51
	Значит в ядре и надо фиксить это, а не танцевать вокруг языка программирования.
	Ответить | Правка | Наверх | Cообщить модератору

162. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Легивон (?), 29-Ноя-24, 21:15
Го приятно порадовал. На практически осмысленном количестве рутин (тысячи) он второй. Обходит его только ненужная ржавчина. Хорошо сделали!
Ответить | Правка | Наверх | Cообщить модератору

	224. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:32
	> Го приятно порадовал. На практически осмысленном количестве рутин (тысячи) он второй. Обходит > его только ненужная ржавчина. > Хорошо сделали! Ржавчина настолько ненужная - что успешно выпилила го с серверов Dropbox'а, на минуточку :)
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Легивон (?), 30-Ноя-24, 07:51
	Что такое Dropbox? Это какой-то проприетарный Saas сторадж для файлов из 90х? Чем это лучше self-hosted или пускай даже public cloud s3? Почему мнение проприетарщиков должно быть важно?
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:33
	>Чем это лучше self-hosted или пускай даже public cloud s3? Тем, что людей, собирающих свои собственные велосипеды, гораздо меньше в мире, чем людей, покупающих готовые. Про специализацию и разделение труда слышали когда-нибудь? Вот это оно.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 01-Дек-24, 05:20
	> Что такое Dropbox? Это какой-то проприетарный Saas сторадж для файлов из 90х? Это пример довольно нагруженного вебсервиса для вываливания филезов. Они сначала накорябали на питоне. Вскоре они заметили что с "докупите серверов" есть какая-то подстава. И переписали на go. А потом и на хрусте как раз. По все тем же причинам. > Чем это лучше self-hosted или пускай даже public cloud s3? > Почему мнение проприетарщиков должно быть важно? Как пример эволюции нагруженного сервиса - сойдет. А у майкрософта есть не менее забавные вакансии - заменить дотнетчиков на хруст на бэке онлайнового офиса. Так что на тему ненужности с вами не согласится сразу несколько жирных котов.
	Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

	259. "Оценка потребления памяти при одновременном запуске миллиона..."	–2 +/–
	Сообщение от Читатель разных статей про Golang (?), 30-Ноя-24, 10:29
	Всё-таки среди двух названных языков более ненужный - это Го: убогие абстракции, убогая система типов, убогая обработка ошибок, убогая интероперабельность с другими языками программирования, убогая кросс-платформенность (кривой API по работе с файлами для Windows, например), непредсказуемая мутабельность переменных внутри функций. И в довершение ко всему сказанному - GC. Кажущаяся простота Го обманчива.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

176. "Оценка потребления памяти при одновременном запуске миллиона..."	+7 +/–
Сообщение от Аноним (176), 29-Ноя-24, 22:32
если вы столкнулись с необходимостью создать миллион горутин то надо выпит таблеточку и лечь спать а утром подумать о смене работы
Ответить | Правка | Наверх | Cообщить модератору

	186. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
	Сообщение от Аноним (268), 29-Ноя-24, 23:37
	Первый нормальный комментарий во всем треде.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от голос_из_леса (ok), 30-Ноя-24, 01:59
	Ему уже попытались объяснить... https://github.com/hez2010/async-runtimes-benchmarks-2024/pu...
	Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

184. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Аноним (185), 29-Ноя-24, 23:34
>при выполнении кода, создающего миллион параллельно выполняемых сопрограмм Ну а на более низком уровне это как выглядит: fork(2), clone(2) ?
Ответить | Правка | Наверх | Cообщить модератору

	216. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:24
	> Ну а на более низком уровне это как выглядит: fork(2), clone(2) ? Погуглите что такое корутины. До fork или clone они не имеют никакого отношения.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:34
	>>при выполнении кода, создающего миллион параллельно выполняемых сопрограмм > Ну а на более низком уровне это как выглядит: fork(2), clone(2) ? Корутины могут и свой тред шедулить. А запуск полноценного треда в Linux - ну да, clone() с определенными флагами. Собссно тред, процесс и контейнер отличаются в основном флагами и что там у них unshare()'d как таковое. У треда почти все общее, самая легкая конструкция. В процессе unshared больше, а в контейнере - еще больше.
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	281. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (281), 30-Ноя-24, 12:24
	Корутины вошли в моду, когда выяснилось, что fork и clone — слишком тяжелы и несут слишком много накладных расходов, как по памяти, так и по вычислительным ресурсам. Это C10M Problem — задача из мира серверов и обработки гигантского количества одновременно приходящих соединений. https://ru.wikipedia.org/wiki/C10k Только в той реализации, в которой оно представлено в данном бенчмарке, это не показывает ровным счётом ничего.
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

209. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (206), 30-Ноя-24, 04:00
Какие вообще отношение к многозадачности имеет язык программирования? Нельзя создать задачу иначе чем через системный вызов.
Ответить | Правка | Наверх | Cообщить модератору

	226. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:37
	> Какие вообще отношение к многозадачности имеет язык программирования? > Нельзя создать задачу иначе чем через системный вызов. Вообще-то корутины это как раз пример создания задач без системных вызовов, на минуточку. Оказывается шедулить задачи можно и в пределех своего треда(ов). Ну вот такой вложенный шедулинг, ничему не противоречит. Есть всякие граничные вещи - скажем threads.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (206), 30-Ноя-24, 06:18
	Шедулить можно сколько угодно, но ваши задачи не будут параллельно выполняться, значит толку от них никакого нет.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:38
	Толк всё-таки есть, если мы говорим про такие задачи, которые могут какое-то время ожидать операций ввода-вывода. Почитайте про асинхронщину на досуге.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (327), 30-Ноя-24, 20:16
	> Шедулить можно сколько угодно, но ваши задачи не будут параллельно выполняться, значит > толку от них никакого нет. Вообще-то иногда толк все же есть. Представь себе что я хочу програмить обработчик клиента - как более-менее независимую сущность, т.е. ничего не зная в этом контексте о соседних 100500 клиентах, работая так, будто клиент один, и handler целиком занят - им. Это просто удобно в программировании этого. Но сервер с 1 клиентом - это полный отстой. Если сделать форк миллиона процессов, для максимально полной абстракции - скорее всего умрет. Миллион тредов? В принципе наверное уже можно и попытаться. Но оверхед имхо будет. А тут вот возникает идея - шедулить еще и каждый тред внутрях более мелко. В треде целая пачка обработчиков, и пока они там ждут IO, например, с тормозным клиентом - тред вместо отвисания в блокирующем сисколе - свичит задачу и уходит в другой handler, который может работать. При этом в handler - иллюзия простой модели с блокирующим IO и одним клиентом. Реально, конечно, все намного круче. И такое умеют - даже, цук, сишники. Посмотрите как Lwan например ЭТО сделал. Но корутины есть и еще в дофига вариантах, не обязательно именно для сети даже, там это просто удобно бывает.
	Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

	346. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (206), 01-Дек-24, 06:43
	Магии не существует. Параллельный ввод-вывод это не магические операции, а точно такие же инструкции cpu, которые читают байты из одной памяти и перекладывают в другую. Если ввода не ждёт программа, значит его ждёт ядро. Вы можете использовать "асинхронный ввод и вывод" (который был стандартизирован в posix 2001, 23 года назад), (https://linux.die.net/man/7/aio), но по сути это то же самое, что "сделать поток и заставить его подождать".
	Ответить | Правка | Наверх | Cообщить модератору

231. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
Сообщение от голос_из_леса (ok), 30-Ноя-24, 06:58
Все логично. Победили тесты где в качестве функции использовались функции стандартной библиотеки. Где сами создавали функцию, там и память откушали. Автору теста жирную двойку.
Ответить | Правка | Наверх | Cообщить модератору

	237. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (240), 30-Ноя-24, 08:04
	Это каждому понятно что в этом тесте победили те, кого хотели выбрать победителем теста создатели теста. Вплоть до того что невозможно проверить проводился ли тест в реальности или нет и с какими настройками.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:39
	Библиотека tokio на является стандартной для языка Rust.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

238. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Аноним (240), 30-Ноя-24, 08:16
При желании код на там же р#сте можно оптимизировать сколько угодно долго а том числе желая всякие ансейфные штуки https://habr.com/ru/articles/598219/ И при том же желании не делать этого для других языков.
Ответить | Правка | Наверх | Cообщить модератору

239. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (239), 30-Ноя-24, 08:18
Попробовали бы Nim с Malebolgia. А в этом представлении — баловство.
Ответить | Правка | Наверх | Cообщить модератору

	245. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (245), 30-Ноя-24, 09:28
	Да о чём говорить, если зиг не представлен. Тогда у всех растомананов сразу бы спала пелена с глаз.
	Ответить | Правка | Наверх | Cообщить модератору

	266. Скрыто модератором	–2 +/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:42
	>Тогда у всех растомананов сразу бы спала пелена с глаз. Очевидно, зиганутые просто не в курсе, что абстракции в языке Rust бесплатны, а рантайм - минимален.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:23
	Современному веб рабу В Rust можно неиспользовать рантайм при желании. То есть, программисту предоставлен выбор. Про абстракции, которые никому не нужны. Именно поэтому программисты на Си изобретают хеш-мап в своём коде из проекта в проект. Да?
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	312. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (245), 30-Ноя-24, 17:49
	Сам ты раб. В расте хеш-мап при работе не занимает память и не задействует такты процессора, а работает исключительно на тайной магии. Да?
	Ответить | Правка | Наверх | Cообщить модератору

	357. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 01-Дек-24, 14:18
	>Сам ты раб. Я отвечал человеку, который сам себя назвал "Современный веб раб". Его сообщение сначала заблокировал, а потом удалил модератор. Никого оскорблять не хотел. >В расте хеш-мап при работе не занимает память и не задействует такты процессора, а работает исключительно на тайной магии. Да? Причём здесь это? Речь шла о " ненужных абстракция". Оказывается, они нужны. Но в одних языках их реализация стоит гораздо дороже, чем в других.
	Ответить | Правка | Наверх | Cообщить модератору

243. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
Сообщение от Илья (??), 30-Ноя-24, 08:49
int numTasks = int.Parse(args[0]); List<Task> tasks = new List<Task>(); for (int i = 0; i < numTasks; i++) {     tasks.Add(Task.Delay(TimeSpan.FromSeconds(10))); } await Task.WhenAll(tasks); На сишарпе надо было использовать ValueTask - тогда бы память практически не выделялась. Плюс, надо было указать изначальный размер листа - тогда бы удвоения размера листа не происходило - и по памяти  еще можно сэкономить было Таким образом, c# работал бы со скоростью раста
Ответить | Правка | Наверх | Cообщить модератору

	286. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Нуну (?), 30-Ноя-24, 13:09
	при ValueTask память не выделяется в куче отдельно для этого экземпляра ValueTask, но память он все равно занимает и будет она заниматься в куче внутри List А вот Task.WhenAll создает дополнительный массив для себя.
	Ответить | Правка | Наверх | Cообщить модератору

	370. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Вова (?), 01-Дек-24, 21:51
	Зачем WhenAll'у создавать ЕЩЁ массив, если ему и так передали массив?!  Он просто будет по нему бегать, пока все задачи не завершатся.
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Нуну (?), 02-Дек-24, 03:43
	аргумент принимается. они в итоге убрали создание защитного массива вроде в дотнет 8, а так как в тесте дотнет, в котором это есть, то я признаю что мое замечание в этом аспекте лишается силы
	Ответить | Правка | Наверх | Cообщить модератору

244. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Илья (??), 30-Ноя-24, 08:52
Про питон - враньё. Скорее всего под результат подогнали. При реальной нагрузке производительность примерно в 10-50 раз падает.
Ответить | Правка | Наверх | Cообщить модератору

	329. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 20:22
	> Про питон - враньё. Скорее всего под результат подогнали. При реальной нагрузке > производительность примерно в 10-50 раз падает. Да просто обычный синтетический бенч, они все такие.
	Ответить | Правка | Наверх | Cообщить модератору

247. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
Сообщение от Аноним (247), 30-Ноя-24, 09:47
> для типовой программы, реализованной на языках программирования Читаю все эти опусы и задаю вопрос, а какая разница, на каком высокоуровневом языке исходники?
Ответить | Правка | Наверх | Cообщить модератору

	267. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 10:46
	Разница такая, что высокий уровень (абстракции) в том или ином языке обеспечивается разными способами. Например, в Rust такие абстракции бесплатные. А в том же Питоне - нет. Как и в Го, Джаве.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (268), 30-Ноя-24, 13:08
	В Расте все платное. Поэтому им никто не пользуется. Кроме писателей синтетических тестов.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:27
	Гугл в Андроиде. Амазон в инфраструктуре. Клаудфлэр в прокси. Дропбокс, Дискорд в своих програмах. Мозилла в браузере. Эти все - никто?
	Ответить | Правка | Наверх | Cообщить модератору

	373. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (373), 01-Дек-24, 23:05
	А что у Гугл, Амазона, Клаудфлер и Мозилла опять есть свои ООО в России?
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 30-Ноя-24, 13:10
	> Например, в Rust такие абстракции бесплатные. А в том же Питоне - нет. Как и в Го, Джаве. Что такое бесплатная абстракция? Корутина — это абстракция? Да. Бесплатная с точки зрения ресурсов? Нет. От языка не зависит.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	301. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:32
	>Бесплатная с точки зрения ресурсов? Нет. От языка не зависит. Зависит, конечно. Корутины в Го более дорогие, чем асинхронщина в Раст, читал. Бесплатная абстракция - это такая абстракция, которая кроме своего собственного кода не требует каких-то дополнительных ресурсов для своей реализации. Например, выделение памяти в куче вместо использования памяти в стеке. И так далее. Если интересно, могу поискать статью на эту тему про асинхронщину в Раст.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 20:23
	>> Например, в Rust такие абстракции бесплатные. А в том же Питоне - нет. Как и в Го, Джаве. > Что такое бесплатная абстракция? Корутина — это абстракция? Да. Бесплатная с точки > зрения ресурсов? Нет. От языка не зависит. Как показал этот пример, таки - от языка, походу зависит. И от реализации. Это так странно?
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	391. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 03-Дек-24, 08:18
	Никакая модель не бесплатная, очевидно, но реализация зависит от языка. Есть несколько моделей асинхронщины. Можно разбить на две группы: stateless и statefull. В го они стэйфул, в расте стэйтлес. Горутины в го, это почти треды, но на уровне рантайма, а не ОС, с динамическим стэком и прочими накладными расходами. Отлично работают, когда их мало. Но при большом кол-ве все плохо. В расте таски это просто ленивые структуры в памяти, как ёжики, пока не пнёшь – не полетят. Это конечные автоматы, переходят из одного состояния в другое (в точках await).
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	394. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 03-Дек-24, 19:53
	> Никакая модель не бесплатная, очевидно, но реализация зависит от языка. > Есть несколько моделей асинхронщины. Можно разбить на две группы: stateless и statefull. > В го они стэйфул, в расте стэйтлес. > Горутины в го, это почти треды, но на уровне рантайма, а не > ОС, с динамическим стэком и прочими накладными расходами. Отлично работают, когда > их мало. Но при большом кол-ве все плохо. > В расте таски это просто ленивые структуры в памяти, как ёжики, пока > не пнёшь – не полетят. Это конечные автоматы, переходят из одного > состояния в другое (в точках await). Этот ответ ближе к телу в отличие от фанбойства Прохожего, где в расте у него все басплатно!)
	Ответить | Правка | Наверх | Cообщить модератору

253. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (251), 30-Ноя-24, 10:20
Для задач такого типа был придуман Erlang.
Ответить | Правка | Наверх | Cообщить модератору

	269. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (268), 30-Ноя-24, 10:51
	Для того чтобы не верить синтетика достойно иметь мозг.
	Ответить | Правка | Наверх | Cообщить модератору

	306. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:59
	А кому тогда верить? Ну кроме каких-то всем известных вещей, типа, интерпретатор всегда медленнее компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

277. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (277), 30-Ноя-24, 11:56
Как они меряли память? Нет вообще ни слова про методику измерения
Ответить | Правка | Наверх | Cообщить модератору

	287. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
	Сообщение от Аноним (268), 30-Ноя-24, 13:10
	Посмотри на автора бенчмарка. Это какой-то недоучившийся студент. Непонятно зачем мы его тут вообще обсуждаем.
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (310), 30-Ноя-24, 16:07
	Автор бенчмарка матёрый разработчик на Java https://pkolaczk.github.io/about/ студент лишь повторил тест год спустя с новыми версиями.
	Ответить | Правка | Наверх | Cообщить модератору

278. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Аноним (277), 30-Ноя-24, 12:00
Kotlin Корутины обошли яву и даже native image с ~90000 кб на 100000 задач
Ответить | Правка | Наверх | Cообщить модератору

285. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Аноним (285), 30-Ноя-24, 13:08
Добавьте в тест Haskell, он в этом плане всех порвет. Ну я так предполагаю.
Ответить | Правка | Наверх | Cообщить модератору

296. "Оценка потребления памяти при одновременном запуске миллиона..."	+1 +/–
Сообщение от Liin (ok), 30-Ноя-24, 13:39
К сожалению, все эти синтетические тесты имеют крайне мало отношения к реальности. В реальной жизни код куда сложнее, а средний разработчик довольно мало знает/помнит об оптимальной конструкции с точки зрения производительности. Вот если бы сравнили реальный код, написанный средними разрабами - это было бы интересно, хоть и с претензиями на объективность.
Ответить | Правка | Наверх | Cообщить модератору

	303. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 30-Ноя-24, 14:42
	>а средний разработчик довольно мало знает/помнит об оптимальной конструкции с точки зрения производительности У нас, например, чтобы средний разработчик об этом не забывал, прямо в договоре с клиентом прописывается гарантированное время реакции программы на действия пользователя. Код средних разработчиков никому не интересен. Потому что они, во-первых, средние. А во-вторых, как вы заметили, часто о чем-то забывают. Ну и напоследок. Безотносительно качества разработчика. Код на Питоне всегда будет более медленным, чем код на Си, Раст и других подобных языках.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Liin (ok), 30-Ноя-24, 15:04
	> Код на Питоне всегда будет более медленным, чем код на Си, Раст и других подобных языках. Кэп, ты? Вы думаете, это откровение для кого-то? Вопрос же не в том, что медленнее, а насколько медленнее.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Прохожий (??), 01-Дек-24, 14:28
	>Вы думаете, это откровение для кого-то? Думаю, да. Для многих "экспертов" данного сайта. Сужу исключительно на основе своего многолетнего опыта общения с ними. >Вопрос же не в том, что медленнее, а насколько медленнее. Если "средний" синоним слову "плохой", то и на Плюсах можно написать такой код по незнанию, который окажется медленнее кода на Питоне. Но почему это должно быть кому-то интересно? Предполагается же, что со временем квалификация растёт и человек перестаёт наступать на те грабли, на которые наступал ранее по молодости.
	Ответить | Правка | Наверх | Cообщить модератору

313. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
Сообщение от Аноним (313), 30-Ноя-24, 17:49
А вы не задумывались что возможно golang действительно готов все это параллельно обрабатывать? Другой вопрос что все одно столько тредов процесса нет, а значит и полноценных горутин зачем столько. И это влпрос к golang. Однако вче равно хотелось бы не только графики потребления памяти, но и графики скорости выполнения всех этих задач, а то может оказаться что на деле остальные то в один поток делать будут миллиард лет
Ответить | Правка | Наверх | Cообщить модератору

	332. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (245), 30-Ноя-24, 21:23
	Ну так сделай, разрешаю.
	Ответить | Правка | Наверх | Cообщить модератору

348. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Аноним (206), 01-Дек-24, 08:55
Для таких задач существует Cisco Chez Scheme.
Ответить | Правка | Наверх | Cообщить модератору

369. Скрыто модератором	+/–
Сообщение от Вова (?), 01-Дек-24, 21:46
Тест очевидно тyn0й, нет никакого смысла в миллионе задач! Для того многопроцы и придумали, чтобы всё нещадно параллелить в пределах разумного (т.е. насколько тянет ОСь). А если одной системы недостаточно - распределённые вычисления. А главное, да пофиг все эти выкрутасы с памятью! Вы много решаете таких задач? Я - ни одной. Вот и занимайтесь РЕАЛЬНЫМИ задачами!
Ответить | Правка | Наверх | Cообщить модератору

	372. Скрыто модератором	+/–
	Сообщение от Аноним (373), 01-Дек-24, 23:02
	А ну тогда добавьте что и для параллельности нужна видеокарта, именно они такими задачами сейчас занимаются. И я говорю об ИИ.
	Ответить | Правка | Наверх | Cообщить модератору

393. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Соль земли (?), 03-Дек-24, 17:22
почему java все еще лидирует в энтерпрайзе? ведь программисты дешевле серверов
Ответить | Правка | Наверх | Cообщить модератору

395. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Аноним (395), 04-Дек-24, 05:12
Тест больше похож на рекламу C#. Конечно C# потребляет памяти меньше Java, но по сравнению с C и C++ кушает её немерено. Тут для примера взять КОМПАС-3D, не каждый компьютер его потянет, по сравнению с blender память жрёт немерено. А так для примера на micropython можно тоже сделать распараллеливание используя _thread, и кушать памяти будет поменьше чем Python и скорость выполнения будет выше раза так в три. На счёт Rust, то его бинарники значительно больше по размеру по сравнению с C++, есть конечно варианты, когда бинарники значительно меньше, но это когда он использует сторонние библиотеки на C,С++, т.е. использует не свой функционал. Всё это нужно для своих задач. Вот теперь когда санкции и столкнулись лбом, когда нужно портировать КОМПАС-3D на Linux, а ни как, только через вайн. Там план у них на сайте висит на 2025 год, а в другом месте уже написано что на 2026, срок всё продлевается.
Ответить | Правка | Наверх | Cообщить модератору

396. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от Фанат (?), 04-Дек-24, 13:07
Мда... Раст настолько плох что сравним с С#. Это фиаско.
Ответить | Правка | Наверх | Cообщить модератору

398. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
Сообщение от uis (??), 05-Дек-24, 13:12
Как говорят в LKML, >2) the fastest model: is a pure, minimal state-machine tailored to the task/workload we want to do.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема