The OpenNET Project / Index page

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



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

Оглавление

Линус Торвальдс опроверг проблемы с планировщиком задач, всп..., opennews (??), 06-Янв-20, (0) [смотреть все] +1

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


23. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +3 +/
Сообщение от anonymous (??), 06-Янв-20, 11:17 
По такой же логике можно обвинить компилятор, если программа не работает, когда на самом деле она не работает из-за UB (мол "на другом-то компиляторе всё good!").
Ответить | Правка | Наверх | Cообщить модератору

56. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  –5 +/
Сообщение от Аноним (8), 06-Янв-20, 12:48 
Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так ляпнул, авось за умного сойти?
Ответить | Правка | Наверх | Cообщить модератору

78. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +2 +/
Сообщение от Аноним (6), 06-Янв-20, 13:53 
> Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так
> ляпнул, авось за умного сойти?

Это ты челюсть поставил вот этой заявой и предположениям выше про MuQSS. Так что ждём от тебя результатов и сорцов для повторения тестов (ты ведь не будешь подгонять цифирки, просто -- так принято).

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

101. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  –4 +/
Сообщение от Аноним (8), 06-Янв-20, 14:48 
Поздравляю, Шарик, ты балбес. Иди чекни статью по оп ссылке
Ответить | Правка | Наверх | Cообщить модератору

119. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +1 +/
Сообщение от Аноним (6), 06-Янв-20, 15:14 
Тебе надо, ты и иди. Заодно челюсть спасёшь.
Ответить | Правка | Наверх | Cообщить модератору

325. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от anonymous (??), 07-Янв-20, 11:07 
Я предпочитаю просто обсуждать вопрос в плоскости логики и/или ссылок на факты. "Челюсть" не буду "ставить" в любой дискуссии.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

231. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +2 +/
Сообщение от Аноним (231), 06-Янв-20, 21:01 
Тут сразу вспоминается история с memcpy(), glibc и adobe flash
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

364. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от JL2001 (ok), 08-Янв-20, 00:03 
> Тут сразу вспоминается история с memcpy(), glibc и adobe flash

а что там было?

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

395. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +1 +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 09:27 
я так понимаю, имеется в виду вот это: https://www.linux.org.ru/news/linux-general/5545961
Ответить | Правка | Наверх | Cообщить модератору

394. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 09:26 
Сложно сказать, как в этом случае. Возможно в данном случае Линус прав: не понимаешь что это и как его правильно использовать - не используй. С memcpy(), имхо, он был не прав, причём по аналогичной логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся безопасным и более медленным memmove()-ом.
Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

399. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от nobody (??), 09-Янв-20, 13:29 
Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать дураками всех и отберём memcpy() у ВСЕХ"
Ответить | Правка | Наверх | Cообщить модератору

401. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:15 
> Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые
> не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать
> дураками всех и отберём memcpy() у ВСЕХ"

Ну так, к сожалению, Линус такое и предлагает в https://bugzilla.redhat.com/show_bug.cgi?id=638477#c101

I'd personally suggest that glibc just alias memcpy() to memmove().

И в этом я с ним не согласен.

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

402. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от nobody (??), 09-Янв-20, 15:20 
А я что написал?..
Ответить | Правка | Наверх | Cообщить модератору

404. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:39 
> А я что написал?..

Прошу прощения, значит я неправильно понял Ваш посыл.

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

403. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Аноним (6), 09-Янв-20, 15:33 
> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав:
> не понимаешь что это и как его правильно использовать - не
> используй. С memcpy(), имхо, он был не прав, причём по аналогичной
> логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся
> безопасным и более медленным memmove()-ом.

Прошу прощения за свою лень, напишу, не смотря в исходники. В упомянутых функциях уже столько проверок, что ещё одна мало что изменит.

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

405. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:49 
>> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав:
>> не понимаешь что это и как его правильно использовать - не
>> используй. С memcpy(), имхо, он был не прав, причём по аналогичной
>> логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся
>> безопасным и более медленным memmove()-ом.
> Прошу прощения за свою лень, напишу, не смотря в исходники. В упомянутых
> функциях уже столько проверок, что ещё одна мало что изменит.

простая, но оптимизированная для x86, memcpy() выглядит так:
;------------------X8
void *memcpy(void *d, void const *s, size_t n)
{
  __asm__ __volatile__(
    "rep ; movsl\n"
    "movl %1,%%ecx\n"
    "andl $3,%%ecx\n"
    "jz 1f\n"
    "rep ; movsb\n"
    "1:"
    :
    :"c"(n / 4), "g"(n), "S"(s), "D"(d)
    :"memory"
  );

  return d;
}
;------------------X8
а memmove() - так:
;------------------X8
void *memmove(void *d, const void *s, size_t n)
{
  __asm__ __volatile__(
    "cmpl %%esi,%%edi\n"
    "jb 1f\n"
    "addl %1,%%edi\n"
    "addl %1,%%esi\n"
    "decl %%edi\n"
    "decl %%esi\n"
    "std\n"
    "1:"
    "rep ; movsl\n"
    "movl %1,%%ecx\n"
    "andl $3,%%ecx\n"
    "jz 2f\n"
    "rep ; movsb\n"
    "2:\n"
    "cld"
    :
    :"c"(n / 4), "g"(n), "S"(s), "D"(d)
    :"memory"
  );
  return d;
}
;------------------X8
как можете видеть, разница таки есть. как минимум в анализе перекрытия областей и прочей математики, для обеспечения копирования "назад".

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

406. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Аноним (6), 09-Янв-20, 16:09 
> простая

"I'd personally suggest that glibc just alias memcpy() to memmove()."

В glibc она не такая простая, насколько помню, там есть выбор от размера копируемых данных. А если добавить проверку перекрытия в простой код: на больших объёмах не играет роли; на малых memcpy() не эффективна.

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

407. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 16:22 
>> простая
> "I'd personally suggest that glibc just alias memcpy() to memmove()."
> В glibc она не такая простая, насколько помню, там есть выбор от
> размера копируемых данных. А если добавить проверку перекрытия в простой код:
> на больших объёмах не играет роли; на малых memcpy() не эффективна.

Не могу с Вами, как и с Линусом, согласиться. На малых и известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в последовательность команд mov). По крайней мере я такое точно наблюдал в своих проектах. На больших объёмах - да, лишние потери будут меньше, но всё-равно будут. А если это какой-нибудь там Intel Atom с тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с сотнями гигабайт памяти ОЗУ.

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

408. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Аноним (6), 09-Янв-20, 16:35 
>>> простая
>> "I'd personally suggest that glibc just alias memcpy() to memmove()."
>> В glibc она не такая простая, насколько помню, там есть выбор от
>> размера копируемых данных. А если добавить проверку перекрытия в простой код:
>> на больших объёмах не играет роли; на малых memcpy() не эффективна.
> Не могу с Вами, как и с Линусом, согласиться. На малых и
> известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может
> заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в
> последовательность команд mov). По крайней мере я такое точно наблюдал в
> своих проектах.

Тоже наблюдал такое и очень давно. Именно это и имел ввиду, когда писал что сама функция не эффективна (это и обуславливает инлайн mov). В таком случае замена не должна играть роли, поскольку аналогичная оптимизация происходит и с memmove(), и с ручным (в смысле, в цикле) копированием.

> На больших объёмах - да, лишние потери будут меньше,
> но всё-равно будут. А если это какой-нибудь там Intel Atom с
> тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний
> 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с
> сотнями гигабайт памяти ОЗУ.

Пенальти на неверно предсказанный переход, навскидку, тактов 10-20, а вот скорость копирования упирается в ширину пропускания шины памяти, которая поуже чем у кеша, то есть процессор часть времени в любом случае как бы простаивает. Ну и если проверок несколько, значит и пенальти при неверном предсказании потенциально и так есть.

С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм при написании кода и нарушает переносимость на другие ОС и libc.

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

409. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Совершенно другой аноним (?), 09-Янв-20, 16:49 
> С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм
> при написании кода и нарушает переносимость на другие ОС и libc.

Тоже думал про такой аспект, но забыл написать.

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

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

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




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

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