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

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

Сообщения

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

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

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

	45. "Оценка потребления памяти при одновременном запуске миллиона..."	–4 +/–
	Сообщение от Аноним (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ообщить модератору

	90. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (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ообщить модератору

	191. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от pavlinux (ok), 30-Ноя-24, 00:33
	> у меня в Windows XP 32bit по памяти (Virtual Size) заняло 9736К. Ща тя Растыры закидают
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

	21. Скрыто модератором	+/–
	Сообщение от 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ообщить модератору

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

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

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

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

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

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

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

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

	117. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

	219. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:26
	> Говорят, на .нет 9.х неплоха Что-что, говорите, вы не лоха? Вот тут с вами хрустики которых хантит МАЙКРОСОФТ на замену нетчиков могут поспорить :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

	47. "Оценка потребления памяти при одновременном запуске миллиона..."	–5 +/–
	Сообщение от НяшМяш (ok), 29-Ноя-24, 17:37
	Потому что без уязвимостей потом денег за исправление не заплатят.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

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

	204. Скрыто модератором	+/–
	Сообщение от Советский инженер и пенсионер 79 лет (?), 30-Ноя-24, 03:53
	> НяшМяш Tы клoyн aвaтaркy смени не в дeтском caду.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

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

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

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

	182. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (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ообщить модератору

	192. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от pavlinux (ok), 30-Ноя-24, 00:35
	> крейтами, тулингом,   дебаге,  кросс-компиляцией, деплоем. Загоните этого хипстера обратно в офис или переводи на русский
	Ответить | Правка | Наверх | Cообщить модератору

	194. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 01:34
	>> крейтами, тулингом,   дебаге,  кросс-компиляцией, деплоем. > Загоните этого хипстера обратно в офис или переводи на русский Ты с какого завода метелок сбежал? Не знаешь терминологии - значит тебе место двор мести.
	Ответить | Правка | Наверх | 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. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от th3m3 (ok), 29-Ноя-24, 21:48
	Сливает даже Питону)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	69. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

14. "Оценка потребления памяти при одновременном запуске миллиона..."	–3 +/–
Сообщение от Аноним (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ообщить модератору

	205. Скрыто модератором	+1 +/–
	Сообщение от Советский инженер и пенсионер 79 лет (?), 30-Ноя-24, 03:55
	Ты Kлoyн У тебя мoзгa нет чтобы что-то там понимать Ты же тpaнсгeндepный биoмуcop Скоро всех нaйдeм, кacтриpyeм и на Koлымy с киpкой!!! Мpaзь!
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	207. Скрыто модератором	+/–
	Сообщение от Советский инженер и пенсионер 79 лет (?), 30-Ноя-24, 03:57
	Пpидypoк!!!!! кacтpaт хoдячий ! ! !!
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от Советский инженер и пенсионер 79 лет (?), 30-Ноя-24, 03:58
	Ты жу идищт! !!! ! Сын осла и пpoститутки ! !! ! Вceх найдём Всех yбьём. . .!
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

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

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

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

	221. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Ноя-24, 04:28
	> блин, я только что понял что Python и Go находятся в отношении > Хищник - жертва Но, таки, поскольку вселенная любит стебаться - хомчок нагло и демонстративно пожрал гадюку в вебе от души.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	76. "Оценка потребления памяти при одновременном запуске миллиона..."	–1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

75. "Оценка потребления памяти при одновременном запуске миллиона..."	+3 +/–
Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

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

	193. "Оценка потребления памяти при одновременном запуске миллиона..."	+/–
	Сообщение от chdlb (?), 30-Ноя-24, 00:39
	ты лучше не пиши больше, а то маршрутка подняться не может
	Ответить | Правка | Наверх | 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ообщить модератору

120. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
Сообщение от Пишу с 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ообщить модератору

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

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

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

	186. Скрыто модератором	+/–
	Сообщение от Аноним (186), 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ообщить модератору

	187. Скрыто модератором	+/–
	Сообщение от Аноним (186), 29-Ноя-24, 23:38
	Это выглядит как заказная джинса от растовиков. Не стоит внимания.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

198. "Оценка потребления памяти при одновременном запуске миллиона..."	+2 +/–
Сообщение от Семен (??), 30-Ноя-24, 02:50
Очередной тест на тупых обезьян на опеннете... А ведь у большей части горе комментаторов нет за душой реальных проектов даже в 10к строк, зато эксперты по производительности, начитавшихся таких же горе тестеров, которые нормально методологию не могут разработать и использовать объективные тесты, вместо измерения погоды на марсе ректальным градусником. Не понятно, как проводились тесты, любой язык можно испортить и сказать, смотрите какой он плохой, кривым кодом и не правильными настройками. Та жа бигдата в очень большом количестве использует Java, а не С# или Go. Собственно jvm считаются одними из самым прогрессивных виртуальных маших, и имеют кучу настроек для сборки мусора, по тестам не понятно какой сборщик мусора использовался и с какими настройками, а там может быть отложенная чистка, чтобы не замедлять код во время работы и не ставить на паузу ради чистки heap, плюс heap кешируется, чтобы не отдавать блоки памяти ОС, и приложение могло быстро переиспользовать эту паять. Над комментами насчет медленной джавы поржал, это осталось в 5й джаве, а оверхед современных виртуальных машин не превышает пары процентов, и приближается к машинному кода, я даже делал тесты на математические вычисления и в некоторых Java в 2 раза быстрее С кода была, за счет Jit и кеширования. Собственно какой язык не бери, все пригодны для продакшена, портят языки только программисты с непониманием их особенностей и не оптимальными алгоритмами, не раз проходили, что замена пары строк кода этих горе программистов могла ускорить код в десятки и сотни раз. Я еще не говорю, про то, что кучу дорого инженерного софта написано на Java, и использует ее для обработки больших данных и симуляции разных физических процессов.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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