Здравствуйте, DiPaolo, Вы писали:
Аё>>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io.
DP>У некоторых Путин во всем виноват, а у Артема — плюсы во всем виноваты
Ну смотри: Линух гонит плюсников от ядра поганой метлой. Результат: ядро Линукса быстрей и стабильней ядра макоси. Которая затащила в ядро кресты, а в юзермод драйвера- COM.
Здравствуйте, Артём, Вы писали:
Аё>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io.
Ох фантазёр!
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>Что такое LBA? CC>Грубо говоря это номер сектора на диске.
OK. В этом смысле давно знаю, но не предположил без контекста.
CC> Начинается с нуля, отрицательных значений не существует. Все железяки работают строго с unsigned значениями.
Сам по себе LBA — да. А если нужно работать с их разностями? Вполне ведь типовой подход для некоторых задач.
Взять int64_t, который заведомо шире двойного максимального LBA в реальности ближайшие лет 50, и работать со знаковыми — тривиально удобно.
Эти соображения в той дискуссии тоже звучали, но ты явно пропустил, потому что не понравились.
Здравствуйте, netch80, Вы писали:
N>Сам по себе LBA — да. А если нужно работать с их разностями?
Ещё раз, для тех кто в танке: есть функция чтения конкретного сектора, какие ещё нафиг могут быть разности?
Давай туда double передавать вообше, вдруг кому то надо не целый сектор
N>Взять int64_t, который заведомо шире двойного максимального LBA в реальности ближайшие лет 50
Гнать из инженеров ссаными тряпками за такое.
N> и работать со знаковыми — тривиально удобно. N>Эти соображения в той дискуссии тоже звучали, но ты явно пропустил, потому что не понравились.
Эти "сообрвжения" не имеют под собой инженерной основы.
"Удобно" это не обоснование. Более того, на практике это нам УЖЕ вылезло в огромную кучу разнообразного "неудобно".
Так что нафиг.
для идиотов, проводящих собеседование — первичен.
вот зачем прикладнику на C# знать как работает сборщик мусора и прочее, если ему надо будет только формы накидывать и простую бизнес-логику править?
Здравствуйте, Артём, Вы писали:
DP>>У некоторых Путин во всем виноват, а у Артема — плюсы во всем виноваты
Аё>Ну смотри: Линух гонит плюсников от ядра поганой метлой. Результат: ядро Линукса быстрей и стабильней ядра макоси. Которая затащила в ядро кресты, а в юзермод драйвера- COM.
Ты так говоришь, как будто в ядре линупса не используют таблицы указателей на функции
Здравствуйте, DiPaolo, Вы писали:
Аё>>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io.
DP>У некоторых Путин во всем виноват, а у Артема — плюсы во всем виноваты
Здравствуйте, CreatorCray, Вы писали:
Аё>>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io. CC>Ох фантазёр!
Береги коллектор
Of 86 benchmarks carried out across all three operating systems, Ubuntu 19.10 was the fastest 48% of the time followed by Windows 10 with leads 31% of the time and macOS 10.15 at just under 20%.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, CreatorCray, Вы писали:
Аё>>>Меня уже почему-то не удивляет, что на одном и том же железе, макось рутинно сливает линуху в операциях io. CC>>Ох фантазёр! Аё>Береги коллектор
Твой коллектор, сам его и береги.
Аё>https://www.phoronix.com/review/macos1015-win10-ubuntu/10
Ты сам то хоть читал что там написано?
Где там хоть один IO тест?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>Сам по себе LBA — да. А если нужно работать с их разностями? CC>
Да-да, я знаю, что это типовая реакция с твоей стороны, когда ты даже не пытаешься подумать пару минут и понять собеседника.
CC>Ещё раз, для тех кто в танке: есть функция чтения конкретного сектора, какие ещё нафиг могут быть разности?
Управление непосредственно устройством диска: работа с кэшом. Например, по стоящим в очереди запросам, имеет ли смысл вместо чтения, например, секторов 0, 5, 10, 15 прочитать в кэш целиком дорожку. (Для SSD проблемы аналогичны с заменой дорожки на блок стирания.)
Чуть повыше — драйвер файловой системы: поиск оптимальной группировки по экстентам, определение размещения файла по полосам.
Это только те задачи, которые я видел сам. А их сильно больше.
CC>Давай туда double передавать вообше, вдруг кому то надо не целый сектор
Красивый передёрг, но мимо.
N>>Взять int64_t, который заведомо шире двойного максимального LBA в реальности ближайшие лет 50 CC> CC>Гнать из инженеров ссаными тряпками за такое.
Аргументы так и не появились.
N>> и работать со знаковыми — тривиально удобно. N>>Эти соображения в той дискуссии тоже звучали, но ты явно пропустил, потому что не понравились. CC>Эти "сообрвжения" не имеют под собой инженерной основы. CC>"Удобно" это не обоснование. Более того, на практике это нам УЖЕ вылезло в огромную кучу разнообразного "неудобно".
Здравствуйте, SkyDance, Вы писали:
SD>Иными словами, в отличие от С++, который больше про добровольное участие, в Го вливаются огромные деньги. Ибо понятно, зачем. Но в этом же и проблема: если в Гугл появится новый политик, который поменяет направление денежных потоков, будущее языка уже не будет столь безоблачным.
SD>PS: но сам рантайм прикольный. Если здесь на форуме есть кто-то, работающий над этим рантаймом, черканите весточку — интересно обсудить некоторые идеи.
А что там именно такого ценного? (не работаю над ним, но интересно)
Ну кроме того, что они не повторили основные дебилизмы Erlang?
Здравствуйте, CreatorCray, Вы писали:
N>>2. А почему кого-то должны волновать твои персональные флэшбеки и рефлексы? CC>Это было к вопросу почему люди со знанием С++ не заинтересовались.
"Отучаемся говорить за всех" (tm)
Твои персональные тараканы очевидно не распространяются на все объекты класса "люди со знанием C++". Я лично знаю таких, которые радостно перешли на Go.
И знаю таких, которые говорили "мы устали от проблемы = против ==, пусть будет язык, где фигня просто не скомпилируется".
N>>насколько легче зажать людей в прокрустово ложе и потом получать более-менее равномерный результат, чем разбираться со сложностью. CC>Для мазохистов уже есть С, где всё приходится хреначить врукопашную. Нафига козе баян?
В Go не "всё" надо "хреначить врукопашную". Только отдельные места — в первую очередь обработку ошибок. Зато масса того, что в C "врукопашную", в Go решено удобным образом.
Здравствуйте, netch80, Вы писали:
N>Твои персональные тараканы очевидно не распространяются на все объекты класса "люди со знанием C++". Я лично знаю таких, которые радостно перешли на Go.
Если со "знанием С++" как у Артёмки?
N>И знаю таких, которые говорили "мы устали от проблемы = против ==
Мда, тяжко быть такими...
Здравствуйте, netch80, Вы писали:
N>Да-да, я знаю, что это типовая реакция с твоей стороны, когда ты даже не пытаешься подумать пару минут и понять собеседника.
У меня на подобные предложения от таких собеседников реакция как у профессора Преображенского:
CC>>Ещё раз, для тех кто в танке: есть функция чтения конкретного сектора, какие ещё нафиг могут быть разности? N>Управление непосредственно устройством диска: работа с кэшом. Например, по стоящим в очереди запросам, имеет ли смысл вместо чтения, например, секторов 0, 5, 10, 15 прочитать в кэш целиком дорожку.
Это всё я делал и не раз. Нахрена тут signed LBA?
N>Чуть повыше — драйвер файловой системы: поиск оптимальной группировки по экстентам, определение размещения файла по полосам.
Это я тоже делал и тоже не раз. Нахрена тут signed LBA?
N>Аргументы так и не появились.
Ну ок, щас за шотганом схожу
CC>>"Удобно" это не обоснование. Более того, на практике это нам УЖЕ вылезло в огромную кучу разнообразного "неудобно". N>Хотя бы два реальных примера — в студию.
Невозможность обращаться к LBA у которых самый старший бит == 1 потому что у куска стека, где было насрано signed значениями коду сносило крышу.
И это практический случай: девайсы бывают не только с непрерывным адресным пространством, детали рассказать не могу.
Так что не надо лепить отсебятину, сказано в стандарте unsigned 64 bit значит unsigned 64 bit!
N>А что там именно такого ценного? (не работаю над ним, но интересно)
Мне интересны идеи работа его scheduler'а, который, по заявлениям разных блогов, вроде как более эффективен (меньше overhead) чем у, скажем, BEAM.
N>Ну кроме того, что они не повторили основные дебилизмы Erlang?
Это, например, какие? И что в данном контексте означает Erlang? Это же не рантайм, а язык. Или имелся в виду Ericsson'овский BEAM?
Здравствуйте, CreatorCray, Вы писали:
CC>Невозможность обращаться к LBA у которых самый старший бит == 1 потому что у куска стека, где было насрано signed значениями коду сносило крышу. CC>И это практический случай: девайсы бывают не только с непрерывным адресным пространством, детали рассказать не могу. CC>Так что не надо лепить отсебятину, сказано в стандарте unsigned 64 bit значит unsigned 64 bit!
Хм, а вот это аргумент. Бить, конечно, извращенцев, что это реализуют, но соответствовать надо.
"Детали рассказать не могу" — хоть намёк, при каком интерфейсе реализуют подобные чудеса?
CC>Это всё я делал и не раз. Нахрена тут signed LBA?
Просто удобнее.
Но если приходится работать с (см. выше) — тады ой, включать аккуратиста на полную.
CC>Здравствуйте, netch80, Вы писали:
N>>Да-да, я знаю, что это типовая реакция с твоей стороны, когда ты даже не пытаешься подумать пару минут и понять собеседника. CC>У меня на подобные предложения от таких собеседников реакция как у профессора Преображенского: CC>Image: b935c1813bed304ba2266082aabbf76a.png
"Профессор" Преображенский тот ещё кусок дерьма. Осознав это, я стараюсь его не цитировать.
Здравствуйте, CreatorCray, Вы писали:
N>>Твои персональные тараканы очевидно не распространяются на все объекты класса "люди со знанием C++". Я лично знаю таких, которые радостно перешли на Go. CC>Если со "знанием С++" как у Артёмки?
Нет, нормальных.
Почему это вдруг хорошее знание C++ не может сочетаться с отсутствием идиосинкразии к знаку `:=`?
N>>И знаю таких, которые говорили "мы устали от проблемы = против == CC>Мда, тяжко быть такими...
Я один раз на сотню (особенно задумавшись) тоже пишу = вместо ==. Обычно замечаю сам при пересмотре. Компилятор обычно отлавливает остатки.
Но оценил пользу записи в стиле if (0 == x)...
Вообще правильнее всего было бы как-то особо помечать "у этого присвоения используется значение". Я предлагал для этого слово take.
