The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход/выход
слежка
RSS


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

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

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62314

Ответить | Правка | Cообщить модератору

Оглавление

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


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

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

45. "Оценка потребления памяти при одновременном запуске миллиона..."  –1 +/–
Сообщение от Аноним (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. "Оценка потребления памяти при одновременном запуске миллиона..."  +/–
Сообщение от Аноним (-), 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 
Заголовок читай "How Much Memory Do You Need in 2024 to Run 1 Million Concurrent Tasks?"
Где ты увидело  "корутин"?
Ответить | Правка | К родителю #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ообщить модератору

180. "Оценка потребления памяти при одновременном запуске миллиона..."  +/–
Сообщение от Овцелюб (-), 29-Ноя-24, 23:04 
> Отправлено Барашек, 29-Ноя-24 16:44
> тренера не играют

Один тренер уже старенький, скоро помрет.
Второй может и хотел бы поучаствовать, но никто его больше не приглашает.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

21. Скрыто модератором  +/–
Сообщение от ijuij (?), 29-Ноя-24, 17:00 
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Потому что бессмысленно, ибо сегодня удел C - это сугубо embedded, а где ты там будешь тулить корутины?

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

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

Сразу видно человека, который никогда не пользовался какой-нибудь из реализаций на Си, и какой-нибудь реализацией на расте.

Невозможно сделать stackless корутину без помощи компилятора. Кто будет код твоей функции в конечный автомат превращать?

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

161. "Оценка потребления памяти при одновременном запуске миллиона..."  +/–
Сообщение от _kp (ok), 29-Ноя-24, 21:01 
Да. В Wine никаких проблем.

Зачем так? Если разработчик, и можешь собрать как угодно?
Да возникла проблема с библиотекой, с открытой, и кроссплатформенной, которая нативная для Linux имела проблемы.
А надо сдавать, а не в чужом и большом коде копаться. Ну сделали через Wine. Временно.
А потом подумали, и нафига версии для Linux и Windows делать, если в Wine все отлично.
И тут с c# все проблемы как рукой сняло. ;)

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

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

46. "Оценка потребления памяти при одновременном запуске миллиона..."  –2 +/–
Сообщение от Аноним (-), 29-Ноя-24, 17:34 
> А почему не раст?)

Может у человека 10-20 лет опыта плюсов и он все грабли знает наизусть.
А может проекты не стоят затрат сил на обеспечение надежности и безопасности.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

188. "Оценка потребления памяти при одновременном запуске миллиона..."  +/–
Сообщение от turbo2001 (ok), 30-Ноя-24, 00:06 
Сам тест у C# тоже любопытный, это тест миллиона таймеров, а не задач.
Ответить | Правка | К родителю #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. "Оценка потребления памяти при одновременном запуске миллиона..."  +4 +/–
Сообщение от Rev (ok), 29-Ноя-24, 17:14 
Это не тайные знания, это понимание базовой функциональности.
Ответить | Правка | Наверх | Cообщить модератору

32. "Оценка потребления памяти при одновременном запуске миллиона..."  –3 +/–
Сообщение от Аноним (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. "Оценка потребления памяти при одновременном запуске миллиона..."  +5 +/–
Сообщение от Аноним (53), 29-Ноя-24, 17:53 
> Як так, почему пихон жрёт меньше гошечки?

Ползает медленно, энергии много тратить не надо. Сожрал себе что-нибудь и переваривает неделю. А у go вы видели логотип? Он и носится в своем колесе до упаду, жрать хочет чаще.

Ответить | Правка | Наверх | Cообщить модератору

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

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

а в гошечке куда более мощных рантайм, который все эти проблемы решает
и горутины могут и вычислять и блокировать, а рантайм их по ядрам процессора распределяет
полноценные грин-треды

некорректно так сравнивать

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

23. "Оценка потребления памяти при одновременном запуске миллиона..."  +3 +/–
Сообщение от Аноним (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 +/–
Сообщение от аНОНИМemail (?), 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. "Оценка потребления памяти при одновременном запуске миллиона..."  +/–
Сообщение от Карлос Сношайтилис (ok), 29-Ноя-24, 19:35 
Питон прекрасен для прототипов, для любых.

Но тащить его в нагруженный прод...
Сил этим героям.

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

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

Ты будешь удивлен, но питон именно в проде в дохерище крупнейших проектах. Погуглить за тебя?

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

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

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

173. Скрыто модератором  +/–
Сообщение от Аноним (-), 29-Ноя-24, 22:24 
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ну а на более низком уровне это как выглядит: fork(2), clone(2) ?

Ответить | Правка | Наверх | Cообщить модератору

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру