Немного подумав я даже сформулировал философские вопросы которые рождаются в теории пульсирующей Вселенной. 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.
Всё о чем вы говорите мало влияет на скорость пользовательского кода. Просто потому что никто никогда в здравом уме не делает ни на C# ни на Java задачи требующие серьёзных вычислений. Большая часть вычислений веб-приложений происходит внутри библиотек ASP.NET и Kestrel. Для графического интерфейса в DirectX и их обертках (WPF и WinUI). CPU-bound задачи на C# никто не делает (нужно сделать библиотеку на С++ из которой вытащить функции с нормальными именами и использовать её в C# проекте).
Оптимизации для большинства задач оказывают не такое влияние как многопоточность или SIMD-инструкции. Например я однажды делал графический интерфейс для АЦП. Часть кода преобразующая данные благодаря SSE работала в 6-7 раз быстрее чем написанная на C#. При этом всё на C# могло работать в любой конфигурации что Release что Debug. Если у вас программа на C# сильно замедляется в Debug - это значит что вам нужно оптимизировать hot path чтобы такого не случалось.
Основное преимущество языков вроде Java и C# в том, что код скомпилированный в debug режиме по скорости мало отличается от кода скомпилированного в release. Причина в том что для JIT библиотеки классов и рантайм библиотеки всегда используются Release. В тех же плюсах рантайм библиотеки для release и debug - разные
Кстати владелец ГитХаба же MS? Можно в суд подать в российской юрисдикции и вполне себе его выиграть. Даже наличие аппеляции не спасет, т.к. действия компании нарушают презумпцию невиновности.
Немного подумав я даже сформулировал философские вопросы которые рождаются в теории пульсирующей Вселенной.
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.
Всё о чем вы говорите мало влияет на скорость пользовательского кода. Просто потому что никто никогда в здравом уме не делает ни на C# ни на Java задачи требующие серьёзных вычислений. Большая часть вычислений веб-приложений происходит внутри библиотек ASP.NET и Kestrel. Для графического интерфейса в DirectX и их обертках (WPF и WinUI). CPU-bound задачи на C# никто не делает (нужно сделать библиотеку на С++ из которой вытащить функции с нормальными именами и использовать её в C# проекте).
Оптимизации для большинства задач оказывают не такое влияние как многопоточность или SIMD-инструкции. Например я однажды делал графический интерфейс для АЦП. Часть кода преобразующая данные благодаря SSE работала в 6-7 раз быстрее чем написанная на C#. При этом всё на C# могло работать в любой конфигурации что Release что Debug. Если у вас программа на C# сильно замедляется в Debug - это значит что вам нужно оптимизировать hot path чтобы такого не случалось.
Основное преимущество языков вроде Java и C# в том, что код скомпилированный в debug режиме по скорости мало отличается от кода скомпилированного в release. Причина в том что для JIT библиотеки классов и рантайм библиотеки всегда используются Release. В тех же плюсах рантайм библиотеки для release и debug - разные
Кстати владелец ГитХаба же MS? Можно в суд подать в российской юрисдикции и вполне себе его выиграть. Даже наличие аппеляции не спасет, т.к. действия компании нарушают презумпцию невиновности.