Автор упустил всего одну вещь - наличие RISC ядра внутри процессоров Intel и наличие конвертации CISC команд в RISC. А следующее уже просто конкретные оптимизации конкретного процессора. После того как уперлись в физическую невозможность увеличивать частоту начали увеличивать размер кремния и фичи которые ответственны за трансляцию CISC->RISC. Уже много лет оптимизации строятся за счёт трасляции x86 команд в микроинструкции выполняемые внутри процессора. У интела каждые 4 года появляется новая микроархитектура с дополнительными улучшениями и удивительно что он это только недавно заметил. Судя по патенту прошло уже 2+ цикла, т.е. на рынке должно быть как минимум 4 поколения процессоров (разных по архитектуре и техпроцессу) где этот функционал реализован
Помню стажировался лет 15 назад в Intel Российском. Непонятно что вас удивляет. 1. То что команды выполняются параллельно? Ну да выполняются начиная с архитектуры Pentium. С тех пор количество "магии" и оптимизаций в микроархитектуре только выросло. Современные чипы CISC имеют внутри RISC-ядра и когда команды транслируются, они еще и оптимизируются. Независимые команды исполняются параллельно, несколько подряд идущих команд могут группироваться. Регистров в процессоре на самом деле сильно больше чем тех что вы видите в ассемблере. rax,rbx регистры - это лишь обозначение ассемблера, на самом деле их внутри сильно больше и процессор способен с каждым из них проводить операции независимо. 2. Каждый процессор имеет свои определенные особенности. Компилятор Intel и их библиотеки имеет оптимизированные версии распространенных функций для каждой микроархитектуры и особенностей кэша(!). Даже простое копирование будет по-разному выполнено на разных архитектурах. 3. Использовать VTune или аналогичный профайлер обязательно начиная с появления технологии Hyper Threading. Внезапно даже включая и выключая HT код может начать вести себя по-разному даже на одном и том же процессоре (потому что HT это неполноценная многоядерность).
Немного подумав я даже сформулировал философские вопросы которые рождаются в теории пульсирующей Вселенной. 1. Была ли в прошлых циклах жизнь? 2. Будет ли в будущих циклах жизнь? 3. Если в прошлых циклах была жизнь, то пережила ли она сжатие? 4. Если в прошлых циклах была жизнь и она не пережила сжатие, то смогла ли она оставить послание и сможем ли мы в свою очередь оставить читаемое в астрономических масштабах послание. Послание должно передавать информацию между фазами сжатия и быть читаемо хотя бы цивилизацией следующего цикла. 5. И только тут вопрос - сможем ли мы пережить сжатие.
Ну и вариант, что космологические аномалии видимые нами являются результатом работы устройства/устройств блокирущего доступ других цивилизаций в наш участок космоса тоже не следует исключать. "Мертвая зона" большая чем продолжительность жизни любого живого индивидуума во Вселенной куда более надежный заслон чем любые законы и условности. В таком случае мы вообще до момента нахождения такого устройства, мы ничего не можем сказать об устройстве Вселенной, но по идее должны иметь возможность такое устройство найти.
Интересная статья. Но у такой теории должно быть еще одно предсказание: если есть циклы, то должны быть цивилизации прошлых циклов. Т.е. они либо должны пережить цикл, либо оставить читаемые послания для цивилизаций следующих циклов (что логично после понимания цикличности).
Другой более фантастический вариант (в рамках концепции космического зоопарка) Наблюдаемые искажения могут быть вызваны защитным устройством оставленным сверхцивилизацией, чтобы закрыть Землю от посягательств других цивилизаций. В этом случае это устройство должно находиться в пределах досягаемости ракетного принципа движения
Про мак не скажу, не использую, но в линуксе добавление единички поверх количества логических(а nprocесли у тебя HyperThreading возвращает количество ядер умноженное на два) процессоров чаще всего помогает чтобы быстро работало на виртуальных машинах в хостинге.
Собственно у тебя есть два три варианта как распараллелить компиляцию: 1. Минимальное по CPU: количество джоб равно количеству процессоров - меньше делать не стоит по причине того что все что меньше будет работать медленее 2. Максимальное по CPU: количество джоб равно количеству процессоров умноженному на 2 - больше делать не стоит по причине того что ты точно не знаешь какие из задач компилятора требуют максимальной нагрузки на процессор, а какие на подсистему ввода вывода и большее количество джоб уже будет радикально снижать производительность. 3. Оптимальное по памяти: количество джоб равно количество RAM в гигабайтах деленное на 2 или 4 в зависимости от наличия HT.
На своём компьютере ты должен в зависимости от конфигурации самостоятельно подобрать это число (ну если ты используешь линукс постоянно). Оно у тебя будет больше того что в пункте 1, но меньше чем в пункте 2. Если у тебя число 3 меньше чем 1 - то на компьютер нужно добавить памяти.
Вот в советах всегда советуют нижнюю планку + 1 просто потому что с большой долей вероятности это будет оптимальный вариант на незнакомой конфигурации, а также для облака. На своём компе который ты постоянно используешь ты конечно же должен уже знать точное число )
P.S. Судя по всему для мака будет всегда использоваться количество физических процессоров, в то время как для линукса - логических. Это наводит на мысль что люди перепечатывают инструкции не думая )
На али же телефонные в основном такого типа. Я нигде мезониновые или slimstack на али не видел. Даже для ПЛИС не то что для квадриков :-( А вот интересно тут у дрона все разъемы одной фирмы?
Я вообще выключаю S-режимы и использую гибернацию при переноске ноутбука. Если свои ноутбуки я более менее могу настраивать, то на рабочих в явном виде прошу для себя это отключить - никаких проблем
3 - там специальная реализация для интерфейсов-операторов, чтобы сделать Generic Math. Следствием этого будет поддержка этого функционала
4 - Анонимные реализации интерфейсов потому и не нужны, что это антипаттерн. Просто нужно делать через события. В Java нет событий и делегатов, поэтому это делается через реализацию интерфейса.
Тут не сбитая нумерация, а просто это связанные между собой вещи. Делегаты в C# и анонимные реализации интерфейсов в Java созданы по сути для одной цели. Поэтому похожий функционал в них реализован просто разными средствами языка и виртуальной машины.
1 - Enum должны быть быстрыми. Они для этого и целочисленные
2 - В Java Generic это синтаксический сахар языка, с точки зрения виртуальной машины IList<ClassA> и IList<ClassB> это одно и то же из-за Type Erasure (https://docs.oracle.com/javase/tutorial/java/generics/erasure.html). В .NET Generic реализованы на уровне виртуальной машины специальными опкодами.
3 - они .NET 7 появятся
4 - в C# для этих целей сделаны делегаты
Ну т.е. не нужно на C# писать также как пишут на Java, это отдельный язык и несмотря на его похожесть - это всё же не то же самое
В последние 2 моих рабочих места я приходил именно так. И во всех случаях все было охрененно. Собеседования для разработчика это нихреновый такой стресс. И ко концу второй недели хочется определиться. У бэк-разработки так вообще стеки во всех компаниях похожи, задачи тоже. К чему вообще это знание о компании - оно вообще ничего не говорит, т.к. разработчику важно что внутри компании, а не что снаружи. А это он может узнать только от других разработчиков
Мы пробовали один из микросервисов в варианте Debug на где-то около тысячи RPS запускать когда искали утечку памяти на .NET Core 2.1 и 2.2 (её так и не нашли, а переход на 3.1 её волшебным образом убрал). Для этого мы просто в кубере удвоили количество инстансов на всякий случай. И не было никакой ощутимой просадки по выполнению запросов. Разница наверно была, но меньше времени выполнения сетевых запросов, например, обращения к SQL Server. Т.е. на .NET Core 2.1 версия собранная в Debug режиме не особо-то и медленнее чем в Release.
Автор упустил всего одну вещь - наличие RISC ядра внутри процессоров Intel и наличие конвертации CISC команд в RISC. А следующее уже просто конкретные оптимизации конкретного процессора. После того как уперлись в физическую невозможность увеличивать частоту начали увеличивать размер кремния и фичи которые ответственны за трансляцию CISC->RISC. Уже много лет оптимизации строятся за счёт трасляции x86 команд в микроинструкции выполняемые внутри процессора. У интела каждые 4 года появляется новая микроархитектура с дополнительными улучшениями и удивительно что он это только недавно заметил. Судя по патенту прошло уже 2+ цикла, т.е. на рынке должно быть как минимум 4 поколения процессоров (разных по архитектуре и техпроцессу) где этот функционал реализован
out-of-order execution
register renaming
Помню стажировался лет 15 назад в Intel Российском. Непонятно что вас удивляет.
1. То что команды выполняются параллельно? Ну да выполняются начиная с архитектуры Pentium. С тех пор количество "магии" и оптимизаций в микроархитектуре только выросло. Современные чипы CISC имеют внутри RISC-ядра и когда команды транслируются, они еще и оптимизируются. Независимые команды исполняются параллельно, несколько подряд идущих команд могут группироваться. Регистров в процессоре на самом деле сильно больше чем тех что вы видите в ассемблере. rax,rbx регистры - это лишь обозначение ассемблера, на самом деле их внутри сильно больше и процессор способен с каждым из них проводить операции независимо.
2. Каждый процессор имеет свои определенные особенности. Компилятор Intel и их библиотеки имеет оптимизированные версии распространенных функций для каждой микроархитектуры и особенностей кэша(!). Даже простое копирование будет по-разному выполнено на разных архитектурах.
3. Использовать VTune или аналогичный профайлер обязательно начиная с появления технологии Hyper Threading. Внезапно даже включая и выключая HT код может начать вести себя по-разному даже на одном и том же процессоре (потому что HT это неполноценная многоядерность).
Немного подумав я даже сформулировал философские вопросы которые рождаются в теории пульсирующей Вселенной.
1. Была ли в прошлых циклах жизнь?
2. Будет ли в будущих циклах жизнь?
3. Если в прошлых циклах была жизнь, то пережила ли она сжатие?
4. Если в прошлых циклах была жизнь и она не пережила сжатие, то смогла ли она оставить послание и сможем ли мы в свою очередь оставить читаемое в астрономических масштабах послание. Послание должно передавать информацию между фазами сжатия и быть читаемо хотя бы цивилизацией следующего цикла.
5. И только тут вопрос - сможем ли мы пережить сжатие.
Ну и вариант, что космологические аномалии видимые нами являются результатом работы устройства/устройств блокирущего доступ других цивилизаций в наш участок космоса тоже не следует исключать. "Мертвая зона" большая чем продолжительность жизни любого живого индивидуума во Вселенной куда более надежный заслон чем любые законы и условности. В таком случае мы вообще до момента нахождения такого устройства, мы ничего не можем сказать об устройстве Вселенной, но по идее должны иметь возможность такое устройство найти.
Интересная статья. Но у такой теории должно быть еще одно предсказание: если есть циклы, то должны быть цивилизации прошлых циклов. Т.е. они либо должны пережить цикл, либо оставить читаемые послания для цивилизаций следующих циклов (что логично после понимания цикличности).
Другой более фантастический вариант (в рамках концепции космического зоопарка) Наблюдаемые искажения могут быть вызваны защитным устройством оставленным сверхцивилизацией, чтобы закрыть Землю от посягательств других цивилизаций. В этом случае это устройство должно находиться в пределах досягаемости ракетного принципа движения
Про мак не скажу, не использую, но в линуксе добавление единички поверх количества логических(а
nproc
если у тебя HyperThreading возвращает количество ядер умноженное на два) процессоров чаще всего помогает чтобы быстро работало на виртуальных машинах в хостинге.Собственно у тебя есть два три варианта как распараллелить компиляцию:
1. Минимальное по CPU: количество джоб равно количеству процессоров - меньше делать не стоит по причине того что все что меньше будет работать медленее
2. Максимальное по CPU: количество джоб равно количеству процессоров умноженному на 2 - больше делать не стоит по причине того что ты точно не знаешь какие из задач компилятора требуют максимальной нагрузки на процессор, а какие на подсистему ввода вывода и большее количество джоб уже будет радикально снижать производительность.
3. Оптимальное по памяти: количество джоб равно количество RAM в гигабайтах деленное на 2 или 4 в зависимости от наличия HT.
На своём компьютере ты должен в зависимости от конфигурации самостоятельно подобрать это число (ну если ты используешь линукс постоянно). Оно у тебя будет больше того что в пункте 1, но меньше чем в пункте 2. Если у тебя число 3 меньше чем 1 - то на компьютер нужно добавить памяти.
Вот в советах всегда советуют нижнюю планку + 1 просто потому что с большой долей вероятности это будет оптимальный вариант на незнакомой конфигурации, а также для облака. На своём компе который ты постоянно используешь ты конечно же должен уже знать точное число )
P.S. Судя по всему для мака будет всегда использоваться количество физических процессоров, в то время как для линукса - логических. Это наводит на мысль что люди перепечатывают инструкции не думая )
Да посмотрел похожи. А на мавике 3 уже другие делают. Там полукруглые внутри разъёмы. И судя по вариантам на сайте Панасоника это уже не панасоник.
Вообще как они их так выбирают что разные модели используют разные типы разъемов?
На али же телефонные в основном такого типа. Я нигде мезониновые или slimstack на али не видел. Даже для ПЛИС не то что для квадриков :-(
А вот интересно тут у дрона все разъемы одной фирмы?
Я вообще выключаю S-режимы и использую гибернацию при переноске ноутбука. Если свои ноутбуки я более менее могу настраивать, то на рабочих в явном виде прошу для себя это отключить - никаких проблем
А как вы опознаёте разъёмы? Вот интересно бы было это почитать
На сколько людей ради этого пришлось увеличить штат? Отдельная SRE команда?
Не надо вот так.
if (value is DateOnly)
{
writer.WriteValue(((DateOnly)value).ToString(DateFormat, CultureInfo.InvariantCulture));
У меня аж глаз задергался. Нужно if (value is DateOnly date)
R5S же есть. С 3-мя сетевыми (2.5+2.5 на LAN и 1 на WAN)
А почему бы не использовать jupyter notebook на десктопе и carnets на яблоко мобилке?
В качестве хранилища можно использовать git.
R5S дешевле и отлично работает. В R6S слишком много памяти для роутера
3 - там специальная реализация для интерфейсов-операторов, чтобы сделать Generic Math. Следствием этого будет поддержка этого функционала
4 - Анонимные реализации интерфейсов потому и не нужны, что это антипаттерн. Просто нужно делать через события. В Java нет событий и делегатов, поэтому это делается через реализацию интерфейса.
Тут не сбитая нумерация, а просто это связанные между собой вещи. Делегаты в C# и анонимные реализации интерфейсов в Java созданы по сути для одной цели. Поэтому похожий функционал в них реализован просто разными средствами языка и виртуальной машины.
Присоединяюсь с просьбой по написанию статьи или просто названием итоговой прошивки, которую использовали
1 - Enum должны быть быстрыми. Они для этого и целочисленные
2 - В Java Generic это синтаксический сахар языка, с точки зрения виртуальной машины IList<ClassA> и IList<ClassB> это одно и то же из-за Type Erasure (https://docs.oracle.com/javase/tutorial/java/generics/erasure.html). В .NET Generic реализованы на уровне виртуальной машины специальными опкодами.
3 - они .NET 7 появятся
4 - в C# для этих целей сделаны делегаты
Ну т.е. не нужно на C# писать также как пишут на Java, это отдельный язык и несмотря на его похожесть - это всё же не то же самое
Вы ничего не знаете о компании (-20 баллов)
В последние 2 моих рабочих места я приходил именно так. И во всех случаях все было охрененно. Собеседования для разработчика это нихреновый такой стресс. И ко концу второй недели хочется определиться. У бэк-разработки так вообще стеки во всех компаниях похожи, задачи тоже. К чему вообще это знание о компании - оно вообще ничего не говорит, т.к. разработчику важно что внутри компании, а не что снаружи. А это он может узнать только от других разработчиков
Мы пробовали один из микросервисов в варианте Debug на где-то около тысячи RPS запускать когда искали утечку памяти на .NET Core 2.1 и 2.2 (её так и не нашли, а переход на 3.1 её волшебным образом убрал). Для этого мы просто в кубере удвоили количество инстансов на всякий случай. И не было никакой ощутимой просадки по выполнению запросов. Разница наверно была, но меньше времени выполнения сетевых запросов, например, обращения к SQL Server. Т.е. на .NET Core 2.1 версия собранная в Debug режиме не особо-то и медленнее чем в Release.