Ядро Линукс, думаю, вполне подходит в качестве контрпримера. Актуальные вещи успешно эволюционируют и переписываются, некоторые и не по одному разу (неоднократная замена реализации файрвола, например)
Позвольте и тут не согласиться.
Кол-во тепловых переходов не играет роли, т.к. важна только эффективность теплоотдачи в окружающую среду. Тепловые трубки, конечно, рулят, но они только доносят тепло до радиатора, а вот снять его оттуда уже проблема посерьезней.
Сами знаете, какая печка происходит внутри корпуса под нагрузкой, если внутри стоит эффективная «башня», но отсутствует продув самого корпуса…
С видеокартами, на самом деле, то же самое — мне удалось было в разы понизить разницу температур внутри корпуса и окружающей среды, просто загерметизировав все щели в кожухе видеокарты (ирония ещё в том, что сама карта была из серии IceCool или что там), чтобы горячий воздух выходил строго наружу (плюс уменьшил зазор между лопастями турбины и кожухом до субмиллиметрового, чтобы турбина работала ещё больше на продув радиатора, а не выбрасывала часть воздуха обратно в корпус).
Принципиальное преимущество СВО в том, что такая она позволяет вынести отдачу тепла на периметр корпуса, в отличие от классических систем, гда надо использовать либо открытый корпус (как у автора), либо изолировать воздушный поток (в ноутах работает, но в десктопах затруднительно), чтобы сравняться с эффективностью с СВО.
А Вы обратили внимание на расстояние между вентилятором и площадкой кулера? Как по Вашему, во сколько раз эффективная площать сечения поступления воздуха меньше площади собственно вентилятора?..
Интересно, эта последовательность так же хорошо себя ведет при использовании не полной себя, а только части, например, если брать только каждый n-й элемент?
Без вентилятора не пойдет. В режиме минимальной нагрузки ещё будет работать, но при полной загрузке дойдет до 90С (а дальше жесткий тротлинг либо зависнет).
Водяная система охлаждения и миниатюризация вещи не совместимые.
Есть компактные СВО с радиаторами под кулер 120х120 и низкопрофильными водоблоками. Для малин крупновато, конечно, но для miniITX плат вполне подходит.
Если же радиатор делать не большой, примерно того же размера, что на процессоре стоит, то водянка не даст практически никакого эффекта.
Радиаторы СВО продуваются насквозь, с минимальным сопротивлением воздуха и без турбулентностей, в отличие от большинства обычных воздушных СО. А то меньшинство воздушных СО, что продувается насквозь либо имеют монструозные габариты (т.н. «башни»), либо в разы менее эффективны при сравнимых с компактными СВО размерах и уровне шума.
Так что можно собрать вполне компактный 6л корпус (24х19х13 см) под miniITX плюс видеокарту на базе СВО.
Весьма достойно.
Правда, без кожуха не очень практично (хотя и более впечатляющий вид), а с ним вентиляция сильно пострадает (
Имхо, есть смысл смотреть на компактные системы водяного охлаждения — ставить в цепочку CPU+GPU, и устроить поток воздуха так, чтобы продувался БП — тогда можно будет обойтись без вентилятора в БП, самотоком.
Нет ошибки в том, чтобы исправить свою ошибку…
Это я про то, что way of Go можно подкорректировать, если есть way получше )
Задача любого языка — предоставить программисту хороший инструмент для реализации его (программиста) идей. Понятие «хороший», имхо, включает в себя и лаконичность — когда алгоритм записывается кратко и четко, без необходимости излишне углубляться в низкоуровневые детали, как выделение/освобождение памяти, управление блокировками либо постоянная обработка ошибок на каждом! шагу (наш случай). И если с управлением памятью и многопоточностью у Go получилось вполне неплохо, то обработке ошибок в первой версии Go уделили все-таки недостаточно внимания.
Так что очень хорошо, что этот вопрос не теряет в актуальности и активно прорабатывается.
Спасибо, расписано очень доступно и в то же время весьма подробно.
Я пока только присматриваюсь к Tarantool, в связи с чем у меня такой вопрос:
Допустим, есть большой плоский массив, скажем, на 100М штук uint64.
Может ли кластер Tarantool эффективно реплицировать работу с таким массивом — поддерживать консистентное состояние, хранить данные в компактном виде (т.е. именно массив, а не хеш-таблица), и пересылать обновления только для изменяемых элементов массива, а не весь массив целиком при каждой операции?
Сработает только для рисованных мультиков. Фотошоп порезал кучу деталей изображения, особенно видно на артефактах кодирования, например нижняя стрелка часов или левая двойка. Да, границы разноцветовых областей стали четче, а однотонные фоны ровнее, но кроме мультиков такое больше нигде не встречается.
Проект, с одной стороны, интересный, но польза его сомнительна.
Во первых, это все ещё сырая альфа, которая развивается совершенно неспешно.
Во вторых — развитие 3d ускорения от Интел тоже стагнирует уже который год, увы.
В третьих, на ноутбуках обычно кроме встроенной графики от Интел присутствует и дискретная графика, вот её пробрасывать в виртуалку гораздо перспективнее.
И на десктопах тоже интереснее вариант, когда к монитору идет два кабеля — один от встроенной графики, а второй от дискретной, который железно! работает через классический проброс PCI.
Далее пошли налить чашечку кофе, монитор выключился, ...
Монитор выключается не сам по себе — сигнал с кабеля снимает ОС (условно говоря, там наверняка более сложный обмен сообщениями), а уже потом монитор это видит и уходит в спячку. Соответственно, возвращение сигнала на кабель с последующим включением монитора полностью контролируется ОС, осталось только делать это правильно )
Имхо, тут вообще не надо городить решение, требующее действий от пользователя, вся проблема в том, что ОС решает перенести окна до того как монитор успевает включиться. Всего-то надо после подачи сигнала на кабель подождать секунду-другую — если окажется что монитора на нем уже нет, тогда и переносить окна.
Скачайте бинарную софтину для линукса (буквально вчера скачал anydesk, а запустить не смог), а потом поищите отсутствующие библиотеки, тогда будет понятно преимущество статических бинарников.
Это не баг, а полезная фича.
Элементы списка унифицированы, их можно комментировать, копипастить и т.д. без необходимости следить, есть ли запятая на последнем элементе или нет.
Это уменьшает кол-во ошибок при разработке софта.
Так что это очко в пользу Go.
Справедливости ради стоит отметить, что ещё в 5-th Gen CPU (Broadwell) используется 48 EU в Iris Pro 6200, так что сравнение 64 EU Gen11 vs 24 EU Gen9 не совсем корректно :)
И пиковая производительность Broadwell была over 0.8 TFLOPS.
Так что улучшение на пару десятков процентов, конечно, приятно, но не идет ни в какое сравнение с кратным ростом производительности у конкурентов.
Ну молодцы, движутся потихоньку в направлении Qubes OS
Ждем полную виртуализацию приложений и вкладок в браузере.
Вирусы навряд ли полностью исчезнут, но писать их будет уже существенно сложнее.
Если зеленой шашки не обнаружилось в F4, то вероятность её обнаружения в D4 должна составить 100% (по правилам квантовой механики, конечно)
При этом 50% вероятность нахождения шашки в клетке C5 сохраняется
Опять же, если фиолетовая шашка на E5 была бита, то вероятность её обнаружения в C5 теперь 0%. Или же, если фиолетовая шашка будет обнаружена на С5, то на E5 её нет и битой там она не может быть.
Кванты, они не только про вероятности, но и про корреляцию событий.
Все пишут насколько ZFS крутая, но при этом нигде не упоминается, насколько она тормознутая в работе ;(
Начиная от огромного потребления памяти и заканчивая убогой производительностью в многопоточной загрузке.
На домашний комп или резервный стор пойдет, но для high load категорически не годится, увы.
У меня нет достаточно информации, чтобы взвешенно принять чью-то сторону. Именно поэтому я ни опровергаю этот текст, ни поддерживаю его. Возможно, это же является причиной, почему я вижу в тексте кроме анализа ещё и попытку манипуляции мнением (которую я, опять же, ни осуждаю ни поддерживаю — все имеют право на отстаивание своих убеждений, в конце концов).
Кол-во тепловых переходов не играет роли, т.к. важна только эффективность теплоотдачи в окружающую среду. Тепловые трубки, конечно, рулят, но они только доносят тепло до радиатора, а вот снять его оттуда уже проблема посерьезней.
Сами знаете, какая печка происходит внутри корпуса под нагрузкой, если внутри стоит эффективная «башня», но отсутствует продув самого корпуса…
С видеокартами, на самом деле, то же самое — мне удалось было в разы понизить разницу температур внутри корпуса и окружающей среды, просто загерметизировав все щели в кожухе видеокарты (ирония ещё в том, что сама карта была из серии IceCool или что там), чтобы горячий воздух выходил строго наружу (плюс уменьшил зазор между лопастями турбины и кожухом до субмиллиметрового, чтобы турбина работала ещё больше на продув радиатора, а не выбрасывала часть воздуха обратно в корпус).
Принципиальное преимущество СВО в том, что такая она позволяет вынести отдачу тепла на периметр корпуса, в отличие от классических систем, гда надо использовать либо открытый корпус (как у автора), либо изолировать воздушный поток (в ноутах работает, но в десктопах затруднительно), чтобы сравняться с эффективностью с СВО.
Интересно, эта последовательность так же хорошо себя ведет при использовании не полной себя, а только части, например, если брать только каждый n-й элемент?
Радиаторы СВО продуваются насквозь, с минимальным сопротивлением воздуха и без турбулентностей, в отличие от большинства обычных воздушных СО. А то меньшинство воздушных СО, что продувается насквозь либо имеют монструозные габариты (т.н. «башни»), либо в разы менее эффективны при сравнимых с компактными СВО размерах и уровне шума.
Так что можно собрать вполне компактный 6л корпус (24х19х13 см) под miniITX плюс видеокарту на базе СВО.
Правда, без кожуха не очень практично (хотя и более впечатляющий вид), а с ним вентиляция сильно пострадает (
Имхо, есть смысл смотреть на компактные системы водяного охлаждения — ставить в цепочку CPU+GPU, и устроить поток воздуха так, чтобы продувался БП — тогда можно будет обойтись без вентилятора в БП, самотоком.
Это я про то, что way of Go можно подкорректировать, если есть way получше )
Задача любого языка — предоставить программисту хороший инструмент для реализации его (программиста) идей. Понятие «хороший», имхо, включает в себя и лаконичность — когда алгоритм записывается кратко и четко, без необходимости излишне углубляться в низкоуровневые детали, как выделение/освобождение памяти, управление блокировками либо постоянная обработка ошибок на каждом! шагу (наш случай). И если с управлением памятью и многопоточностью у Go получилось вполне неплохо, то обработке ошибок в первой версии Go уделили все-таки недостаточно внимания.
Так что очень хорошо, что этот вопрос не теряет в актуальности и активно прорабатывается.
Я пока только присматриваюсь к Tarantool, в связи с чем у меня такой вопрос:
Допустим, есть большой плоский массив, скажем, на 100М штук uint64.
Может ли кластер Tarantool эффективно реплицировать работу с таким массивом — поддерживать консистентное состояние, хранить данные в компактном виде (т.е. именно массив, а не хеш-таблица), и пересылать обновления только для изменяемых элементов массива, а не весь массив целиком при каждой операции?
Проект, с одной стороны, интересный, но польза его сомнительна.
Во первых, это все ещё сырая альфа, которая развивается совершенно неспешно.
Во вторых — развитие 3d ускорения от Интел тоже стагнирует уже который год, увы.
В третьих, на ноутбуках обычно кроме встроенной графики от Интел присутствует и дискретная графика, вот её пробрасывать в виртуалку гораздо перспективнее.
И на десктопах тоже интереснее вариант, когда к монитору идет два кабеля — один от встроенной графики, а второй от дискретной, который железно! работает через классический проброс PCI.
Имхо, тут вообще не надо городить решение, требующее действий от пользователя, вся проблема в том, что ОС решает перенести окна до того как монитор успевает включиться. Всего-то надо после подачи сигнала на кабель подождать секунду-другую — если окажется что монитора на нем уже нет, тогда и переносить окна.
Элементы списка унифицированы, их можно комментировать, копипастить и т.д. без необходимости следить, есть ли запятая на последнем элементе или нет.
Это уменьшает кол-во ошибок при разработке софта.
Так что это очко в пользу Go.
И пиковая производительность Broadwell была over 0.8 TFLOPS.
Так что улучшение на пару десятков процентов, конечно, приятно, но не идет ни в какое сравнение с кратным ростом производительности у конкурентов.
Ждем полную виртуализацию приложений и вкладок в браузере.
Вирусы навряд ли полностью исчезнут, но писать их будет уже существенно сложнее.
Опять же, если фиолетовая шашка на E5 была бита, то вероятность её обнаружения в C5 теперь 0%. Или же, если фиолетовая шашка будет обнаружена на С5, то на E5 её нет и битой там она не может быть.
Кванты, они не только про вероятности, но и про корреляцию событий.
Начиная от огромного потребления памяти и заканчивая убогой производительностью в многопоточной загрузке.
На домашний комп или резервный стор пойдет, но для high load категорически не годится, увы.