При этом в 95% случаев вариант 5 работает. Причём даже если установщик был собран для Windows 98 в далёком 2000-м году. И история "поставил винду, накатил на неё проверенные версии любимых программ" работает как часы уже много лет.
Офис это прямо боль. Чуть только длинная какая-то xls-ка (на пару-тройку тысяч строк) или заковыристый док - либра начинает тормозить даже на компе с кучей памяти и свободных ядер CPU. Вот что ему не хватает - непонятно совсем.
Та же самая история - сколько раз уже пытался настроить VNC-доступ к Linux, постоянно то клавиатура ведёт себя странно, то разрешение экрана прибивается "гвоздями" к тому, какое у физического монитора на сервере, то просто адовые тормоза. У кого-то вообще получилось его приготовить так, чтобы оно работало не хуже, чем RDP из винды в винду?
Вполне возможно смысл в том, чтобы изучающий придумал альтернативное (весьма, вероятно, сложное) решение, а потом показать ему, как задача решается проще.
Как говорил наш препод по диффурам: дифференциальные уравнения можно разделить на 2 категории: первая - это те, что есть в вашем задачнике, вторая - это те, которые нельзя решить аналитически.
Ну почему же - сразу с первого курса идут параллельно аналитическая геометрия (привет, все 2d и 3d движки) и линейная алгебра (которая нужна чтобы геометрические задачи решать, ага). Вот с диффурами и том что на них основано (вариационное исчисление, ТУ всякое там) - сложно. Да и диффуры сами по себе мозг ломают.
В вузе объясняют, "почему так". Ну т.е. если мы говорим про пределы (которые я в школе не понимал от слова "совсем"), то он сначала строго определяется, а потом уже (опять же, с доказательством) выводятся все его свойства. В результате чего 80% (а то и 90%) университетского курса запоминать не надо - всё можно вывести, если понимать принципы доказательств (и помнить, чего вообще доказать хотим).
Почему и написал эту статью - как по мне, получился хороший пример принципа дырявых абстракций. Мораль - если воспринимать TCP-коннект просто как канал, куда можно посылать и получать байты - можно получить неожиданные и неприятные эффекты.
Да, именно так. Причем получилось, что я делаю 2 раза write (длина, потом тело), а затем read. А в доке не delayed ack написано, что именно такой кейс работает плохо.
Почитать бы где-нибудь на тему "а как оно правильнее всего делается". Без учёта многопоточности конечно (т.е. оптимизируем именно обмен между двумя процессами, без попыток сэкономить CPU).
Или если мы тут упираемся в переключения контекста (система не отдаёт нам управление раньше, чем через 10мс) - тогда в таком варианте больше "выжать" не получится. Могу сказать, что у меня эксперимент не совсем чистый - на машине помимо этого теста много всякого крутится, потому это может влиять.
А чем iperf поможет для организации IPC между плюсовым и PHP-шным приложениями? Изначально-то задача именно в этом стояла. А тут я решил детально разобраться, почему вариант "обмениваться через TCP сокеты" так странно себя ведёт.
Я разобрался https://habr.com/ru/post/724682/. Дело действительно в Nagle. TL;DR: NODELAY надо выставлять с обеих сторон. Сочетание write+write+read - проблемное, ненадотак.
При этом в 95% случаев вариант 5 работает. Причём даже если установщик был собран для Windows 98 в далёком 2000-м году. И история "поставил винду, накатил на неё проверенные версии любимых программ" работает как часы уже много лет.
Офис это прямо боль. Чуть только длинная какая-то xls-ка (на пару-тройку тысяч строк) или заковыристый док - либра начинает тормозить даже на компе с кучей памяти и свободных ядер CPU. Вот что ему не хватает - непонятно совсем.
Та же самая история - сколько раз уже пытался настроить VNC-доступ к Linux, постоянно то клавиатура ведёт себя странно, то разрешение экрана прибивается "гвоздями" к тому, какое у физического монитора на сервере, то просто адовые тормоза. У кого-то вообще получилось его приготовить так, чтобы оно работало не хуже, чем RDP из винды в винду?
Вполне возможно смысл в том, чтобы изучающий придумал альтернативное (весьма, вероятно, сложное) решение, а потом показать ему, как задача решается проще.
Как говорил наш препод по диффурам: дифференциальные уравнения можно разделить на 2 категории: первая - это те, что есть в вашем задачнике, вторая - это те, которые нельзя решить аналитически.
Гарднера решительно плюсую. Добрался до него только в 11 классе школы, но качественный скачок в плане мышления и логики ощутил очень сильно.
Ну почему же - сразу с первого курса идут параллельно аналитическая геометрия (привет, все 2d и 3d движки) и линейная алгебра (которая нужна чтобы геометрические задачи решать, ага).
Вот с диффурами и том что на них основано (вариационное исчисление, ТУ всякое там) - сложно. Да и диффуры сами по себе мозг ломают.
В вузе объясняют, "почему так". Ну т.е. если мы говорим про пределы (которые я в школе не понимал от слова "совсем"), то он сначала строго определяется, а потом уже (опять же, с доказательством) выводятся все его свойства.
В результате чего 80% (а то и 90%) университетского курса запоминать не надо - всё можно вывести, если понимать принципы доказательств (и помнить, чего вообще доказать хотим).
CPU not found, running software emulation...
Почему и написал эту статью - как по мне, получился хороший пример принципа дырявых абстракций. Мораль - если воспринимать TCP-коннект просто как канал, куда можно посылать и получать байты - можно получить неожиданные и неприятные эффекты.
Да, именно так. Причем получилось, что я делаю 2 раза write (длина, потом тело), а затем read. А в доке не delayed ack написано, что именно такой кейс работает плохо.
Почитать бы где-нибудь на тему "а как оно правильнее всего делается".
Без учёта многопоточности конечно (т.е. оптимизируем именно обмен между двумя процессами, без попыток сэкономить CPU).
Или если мы тут упираемся в переключения контекста (система не отдаёт нам управление раньше, чем через 10мс) - тогда в таком варианте больше "выжать" не получится. Могу сказать, что у меня эксперимент не совсем чистый - на машине помимо этого теста много всякого крутится, потому это может влиять.
А как получилось, что оно именно в память упиралось? Или там размер доступной памяти меньше чем MSS у TCP?
А чем iperf поможет для организации IPC между плюсовым и PHP-шным приложениями? Изначально-то задача именно в этом стояла. А тут я решил детально разобраться, почему вариант "обмениваться через TCP сокеты" так странно себя ведёт.
Не ставил себе такую цель. Хотя интересно, можно ли к варианту с shared memory приблизиться.
Да, оказалось, что именно в нём дело https://habr.com/ru/post/724682/.
TL;DR: NODELAY надо с обеих сторон выставлять.
Я разобрался https://habr.com/ru/post/724682/. Дело действительно в Nagle.
TL;DR: NODELAY надо выставлять с обеих сторон. Сочетание write+write+read - проблемное, ненадотак.
APCu я бы тут отнёс к читерству, потому что добраться из не-php процесса до этого самого APCu будет проблемно.
Да, почитал, там внутрях SysV https://github.com/krakjoe/apcu/blob/master/apc_shm.c
И совершенно логичным образом всех заруливает "ручная" работа с памятью через FFI :-)