Здравствуйте. Записи (records) выглядит хорошим нововведением, делающим заголовки для меня (не-джависта) намного более читаемыми.
Но есть вопрос (он не-джависта): а зачем к каждому полю объекта в Джаве генерить геттер-сеттер и обращаться через них? Случай, когда геттеры-сеттеры удобны, чтобы менять нижележащую логику понятен (был string address -> после рефакторинга стало TAddress address). Но ведь удобство это "редкие случаи рефакторинга", а неудобства, это "бойлер-плейт код при создании каждого класса". Более того: чем лучше ты знаешь свою предметную область - тем лучше ты можешь пресказать достаточно ли тут просто переменной (которую, например, можно сделать public и прямо читать-писать) или вероятность рефакторинга относительно высокая и лучше обращаться косвенно, через геттеры-сеттеры.
Если нет маленьких детей, то почти при любой. При наличии маленьких детей (читай постоянно разбросанных по полу игрушек) - наверное действително мало профита.
И да 10-15 минут - мне кажется, что мы с вами по-разному считаем время. Я считаю время от "пошёл за пылесосом", до поставил пылесос на место, полностью убрался (в жару иногда включая быстрый душ), вернулся к делам.
>> Иногда очень хорошие, иногда плохие. Но, это авторские курсы, там разные люди и огромный выбор, конкуренция. Это не то, что бы надежный гарант качества, но хоть какой-то.
А как конкуренция работает на рынке, где покупатель не может оценить реальное качество покупаемого, а только качество обложки или маркетинга? На мой взгляд такие условия - как раз идеальные условия для того, чтобы конкуренция превращалась в конкуренцию маркетинговых подоходов, а наполнение - идёт по остаточному принципу.
Мне кажется, что ключевой момент (для вас на данный момент) из статьи - что научиться можно только самому.
Поэтому возьмите себе для примера любой pet-project (придумайте, присоеденитесь на github, подсмотрите на хабре....) и идите по нему, самостоятельно решая в процессе возникающие задачи. А курс - воспринимайте как помощь (ну и если можно будет половину вопросов переадресовывать преподу - это хорошо, главное, чтобы 50% не превратилось в 100%)
>> Процессор не работает в категориях миллисекунд, он работает в категории тактов и инструкций процессора. Процитируйте где я написал, что процессор работает в категориях миллисекунд (или опять "ссылки нет, но интерпретация логичная"). И да в ситуации с HT/без HT "число инструкций за 1 квант времени" - изменяется очень сильно. Если вы об этом не знаете, или не понимаете, что измерять надо в сравнимых величинах - спросили бы, я бы вам объяснил (Intel давал цифру +30% производительности per Core при включении HT).
>> Вы еще пытаетесь переложить ситуацию со 100% загрузкой процессора, на задачи, когда один поток уснул и работает другой поток. При 100% загрузке нет никакого преимущества и RT задачах тоже. Когда один поток уснул, то он снимется с процессора и произойдёт переключение контекста. Что при включении HT, что без включения HT.
Есть эффекты второго порядка (почему число переключений контекста может быть ниже или выше на любую разумную метрику). Но для начала неплохо бы разобраться с основным эффектом: почему в gorss-подсчёте число переключений контекста (на поток исполнения процессора) не снижается.
>> ссылок нет, вполне логичная интерпретация. @nullc0de жаль, только Intel о "логичности этой интерпретации" не знает.
А не знает об этом Intel потому, что она неправильная (тем более, в ситуации, сервера, когда потоков больше, чем доступных процессорных ядер - у нас же ведь больше, иначе вы бы статью не писали, а просто Hyper Threading отключили бы).
Если у вас 1 аппаратный поток исполниния, на 1 процессорное ядро и каждый thread работает по 100мс, то на этом процессорном ядре 10 раз в секунду будет сниматься thread и планироваться следующий.
Если у вас 2 аппаратных потока исполнения, на 1 процессорное ядро (Hyper Threading) - и каждый процесс работает по 100мс, то на каждом из двух аппаратных потоках 10 раз в секунду будет сниматсья логический thread и планироваться новый.
Те же самые результаты (одинаковое время работы логических thread до снятия с процессора) вы получите, если у вас будет 10 аппаратных потоков, 20 аппаратных потоков, если каждый thread в среднем будет работать 50мс, 20мс......
Среднее время работы логического thread до снятия с процессора не зависит от наличия heper threading (разумеется в предположении, что логических thread у нас больше, чем потоков исполнения предоставленных железом).
Поэтому да инженерная чаксть у вас вполне крутая, но по теоретической - поправьте пожалуйста и не вводите людей в заблуждение.
>> Чтобы уменьшить накладные расходы переключения задач в ОС, разработчики процессоров придумали простое и элегантное решение, переложили часть функций на процессор. Так были придуманы Intel Hyper-Threading (Intel HT) и AMD Simultaneous Multithreading (AMD SMT).
В первый раз вижу такую странную интерпретацию причины появление Hyper Threading. Возможно у вас будет ссылка?
Wiki, например, пишет, что целью было "увеличить параллелизм". А разъясняющие статьи - объясняют, что процессорное ядро имеет общий бэкэнд (ALU и наборы регистров) для двух логических потоков исполнения. И если основной поток "простаивает", например на длительных операциях (с точки зрения Out Of Order исполнения: не осталось полностью готовых (микро-)операций в основном потоке исполнения) - начинают исполняются операции второго потока исполения.
>> Исторические данные, которые мы имеем... оказывается тысячей лет на которой мы выжили.
Это прям классическая ошибка выжившего. Если бы в очередную тысячу лет человечество, как цивилизация, не выжила - некому было бы рассматривать "наши исторические данные".
>> Один мой знакомый откликнулся на вакансию, где написано что-то типа «при отклике на вакансию напишите в поле отклика слово "фиолетовый"», он не написал, и был довольно грубо отшит рекрутером с претензией о том, что он забил на просьбу в вакансии, а значит, не подходит. Не знаю. какие эмоции от такой просьбы и такой реакции у вас, у меня они вызывают желание узнать название компании, чтобы в будущем не вести с ними диалог.
Начало (напишите в поле фиолетоый) - похоже на фильтр от ботов. И я думаю, что нас с неизбежностью ждёт все большое подобных "фаст-чекеров". Продолжение - был довольно грубо отшит. Ну грубость это грубость - не имейте дел с мудаками вполне рациональное правило.
А получить локальный репозиторий внешних пакетов (выкачать всё, упомянутое в crates.io, желательно ещё и взаимно совместимых версий (по формальным признакам версий пакетов, транзитивно вниз по дереву зависимостей)) как-то можно?
Может быть cargo (или какая-то другая внешняя утилита) уже делает такие оффлайн-репозитории всех пакетов?
Коллеги здравствуйте. Хочу попробовать Rust (на работе). Но проблема в том, что у нас закрытая сеть, машины разработчиков под Ubuntu. Из внешней сети пробовать работать не вариант - совсем игрушечные проекты делать не хочется, pet-project на данный момент нет.
Так вот подскажите как настроить в такой ситуации работу с Rust (ну или хотя бы в какую сторону гуглить для начала)? Может быть делают *deb пакеты каких-то стабильных выпусков (а что со сторонними библиотеками тогда и как их обновлять)? Или ещё какой механизм?
Поставил я себе ubuntu 20.04 + Gnome. Так вот оконный менеджен несомненно красивый. Но знаете что? Язык меняется кнопкой "Win+Space". И выставить смену языка через Alt+Shift или Ctrl+Shift нельзя (ах да можно поставить gnome-tweaks и через него уже выставить).
Вот это ситуация, когда нет менеджера. О скучных мелочах думать некому (хотя оконный интерфейс реально красивый, наверное красивее чем в Win - но это уже субьективно).
Программист драйверов для ядра linux должен иметь в виду, что переменная jiffies (счётчик прерываний от таймера с момента старта системы) может переполнится (это цитата то-ли из LDD то или из комментария к linux_headers). гарантируется размер не менее, чем uint64.
Что может произойти - из типового, что приходит в голову на каком-нибудь активном пуллинге с таймаутом (вычитывании готовности данных из устройства внутри драйвера) мы попадём на переполнение jiffies и "зависнем".
Дальше проблемы (не)снятия драйвера зависят от криворукости программиста в остальных местах.
>> т.к. для сеньора задания из серии «пойди туда, не знаю куда, принеси то, не знаю что» являются вполне себе типовыми.
Мне кажется, что вы сильно всё усложняете. В моей практике в 90% (если не 95%-99%) уточнящий вопрос "а что реально надо-то?" расставляет всё по своим местам (в смысле ты получаешь +/- ссылку релевантную ссылку на условия решаемой задачи за минуту). И излишнее усложнение общения (в том числе тонна необязательных уточняющих вопросов) - на первый взгляд характеризует вас отрицательно.
Простите, но если всё вмещается в условный L2 кэш (порядка 10 тактов доступа) - то это тоже без дополнительных приседаний не то, чтобы сильн оспасает отца русской демократии, от дата-столов.
Не дообки ради, но порядку для: чтобы понять большинство ли нужно пообщаться с 50% + 1 (в лучшем случае).
ПС
Разумеется если мы говорим о прямых, а не косвенных выводах.
Здравствуйте.
Записи (records) выглядит хорошим нововведением, делающим заголовки для меня (не-джависта) намного более читаемыми.
Но есть вопрос (он не-джависта): а зачем к каждому полю объекта в Джаве генерить геттер-сеттер и обращаться через них?
Случай, когда геттеры-сеттеры удобны, чтобы менять нижележащую логику понятен (был string address -> после рефакторинга стало TAddress address).
Но ведь удобство это "редкие случаи рефакторинга", а неудобства, это "бойлер-плейт код при создании каждого класса".
Более того: чем лучше ты знаешь свою предметную область - тем лучше ты можешь пресказать достаточно ли тут просто переменной (которую, например, можно сделать public и прямо читать-писать) или вероятность рефакторинга относительно высокая и лучше обращаться косвенно, через геттеры-сеттеры.
Если нет маленьких детей, то почти при любой.
При наличии маленьких детей (читай постоянно разбросанных по полу игрушек) - наверное действително мало профита.
И да 10-15 минут - мне кажется, что мы с вами по-разному считаем время.
Я считаю время от "пошёл за пылесосом", до поставил пылесос на место, полностью убрался (в жару иногда включая быстрый душ), вернулся к делам.
С месяц назад на Хабре была очень классная статья про то "как выучить английский".
//habr.com/ru/post/556696/
Почти со всем согласен.
>> Иногда очень хорошие, иногда плохие. Но, это авторские курсы, там разные люди и огромный выбор, конкуренция. Это не то, что бы надежный гарант качества, но хоть какой-то.
А как конкуренция работает на рынке, где покупатель не может оценить реальное качество покупаемого, а только качество обложки или маркетинга?
На мой взгляд такие условия - как раз идеальные условия для того, чтобы конкуренция превращалась в конкуренцию маркетинговых подоходов, а наполнение - идёт по остаточному принципу.
Мне кажется, что ключевой момент (для вас на данный момент) из статьи - что научиться можно только самому.
Поэтому возьмите себе для примера любой pet-project (придумайте, присоеденитесь на github, подсмотрите на хабре....) и идите по нему, самостоятельно решая в процессе возникающие задачи.
А курс - воспринимайте как помощь (ну и если можно будет половину вопросов переадресовывать преподу - это хорошо, главное, чтобы 50% не превратилось в 100%)
Да имел в виду второй случай, но не лишне было бы уточнить.
А как вы берёте указатель на стек?
Просто определяете, что это указатель на стек и не считаете ссылки?
Подождите только сейчас возник вопрос: а как вы планируете внутри Umka заводить указатели на переданные вам C-структуры?
Или всё это надо заворачивать в копирование данных "из C-структур в umka-структуры и обратно"?
>> Процессор не работает в категориях миллисекунд, он работает в категории тактов и инструкций процессора.
Процитируйте где я написал, что процессор работает в категориях миллисекунд (или опять "ссылки нет, но интерпретация логичная").
И да в ситуации с HT/без HT "число инструкций за 1 квант времени" - изменяется очень сильно. Если вы об этом не знаете, или не понимаете, что измерять надо в сравнимых величинах - спросили бы, я бы вам объяснил (Intel давал цифру +30% производительности per Core при включении HT).
>> Вы еще пытаетесь переложить ситуацию со 100% загрузкой процессора, на задачи, когда один поток уснул и работает другой поток. При 100% загрузке нет никакого преимущества и RT задачах тоже.
Когда один поток уснул, то он снимется с процессора и произойдёт переключение контекста. Что при включении HT, что без включения HT.
Есть эффекты второго порядка (почему число переключений контекста может быть ниже или выше на любую разумную метрику).
Но для начала неплохо бы разобраться с основным эффектом: почему в gorss-подсчёте число переключений контекста (на поток исполнения процессора) не снижается.
>> ссылок нет, вполне логичная интерпретация.
@nullc0de жаль, только Intel о "логичности этой интерпретации" не знает.
А не знает об этом Intel потому, что она неправильная (тем более, в ситуации, сервера, когда потоков больше, чем доступных процессорных ядер - у нас же ведь больше, иначе вы бы статью не писали, а просто Hyper Threading отключили бы).
Если у вас 1 аппаратный поток исполниния, на 1 процессорное ядро и каждый thread работает по 100мс, то на этом процессорном ядре 10 раз в секунду будет сниматься thread и планироваться следующий.
Если у вас 2 аппаратных потока исполнения, на 1 процессорное ядро (Hyper Threading) - и каждый процесс работает по 100мс, то на каждом из двух аппаратных потоках 10 раз в секунду будет сниматсья логический thread и планироваться новый.
Те же самые результаты (одинаковое время работы логических thread до снятия с процессора) вы получите, если у вас будет 10 аппаратных потоков, 20 аппаратных потоков, если каждый thread в среднем будет работать 50мс, 20мс......
Среднее время работы логического thread до снятия с процессора не зависит от наличия heper threading (разумеется в предположении, что логических thread у нас больше, чем потоков исполнения предоставленных железом).
Поэтому да инженерная чаксть у вас вполне крутая, но по теоретической - поправьте пожалуйста и не вводите людей в заблуждение.
ЕМНИП 100% + 30% получается, если есть кэш-миссы прямо в память.
>> Чтобы уменьшить накладные расходы переключения задач в ОС, разработчики процессоров придумали простое и элегантное решение, переложили часть функций на процессор. Так были придуманы Intel Hyper-Threading (Intel HT) и AMD Simultaneous Multithreading (AMD SMT).
В первый раз вижу такую странную интерпретацию причины появление Hyper Threading.
Возможно у вас будет ссылка?
Wiki, например, пишет, что целью было "увеличить параллелизм".
А разъясняющие статьи - объясняют, что процессорное ядро имеет общий бэкэнд (ALU и наборы регистров) для двух логических потоков исполнения.
И если основной поток "простаивает", например на длительных операциях (с точки зрения Out Of Order исполнения: не осталось полностью готовых (микро-)операций в основном потоке исполнения) - начинают исполняются операции второго потока исполения.
>> Исторические данные, которые мы имеем... оказывается тысячей лет на которой мы выжили.
Это прям классическая ошибка выжившего. Если бы в очередную тысячу лет человечество, как цивилизация, не выжила - некому было бы рассматривать "наши исторические данные".
>> Один мой знакомый откликнулся на вакансию, где написано что-то типа «при отклике на вакансию напишите в поле отклика слово "фиолетовый"», он не написал, и был довольно грубо отшит рекрутером с претензией о том, что он забил на просьбу в вакансии, а значит, не подходит. Не знаю. какие эмоции от такой просьбы и такой реакции у вас, у меня они вызывают желание узнать название компании, чтобы в будущем не вести с ними диалог.
Начало (напишите в поле фиолетоый) - похоже на фильтр от ботов. И я думаю, что нас с неизбежностью ждёт все большое подобных "фаст-чекеров".
Продолжение - был довольно грубо отшит. Ну грубость это грубость - не имейте дел с мудаками вполне рациональное правило.
Спасибо.
А получить локальный репозиторий внешних пакетов (выкачать всё, упомянутое в crates.io, желательно ещё и взаимно совместимых версий (по формальным признакам версий пакетов, транзитивно вниз по дереву зависимостей)) как-то можно?
Может быть cargo (или какая-то другая внешняя утилита) уже делает такие оффлайн-репозитории всех пакетов?
Коллеги здравствуйте. Хочу попробовать Rust (на работе). Но проблема в том, что у нас закрытая сеть, машины разработчиков под Ubuntu. Из внешней сети пробовать работать не вариант - совсем игрушечные проекты делать не хочется, pet-project на данный момент нет.
Так вот подскажите как настроить в такой ситуации работу с Rust (ну или хотя бы в какую сторону гуглить для начала)?
Может быть делают *deb пакеты каких-то стабильных выпусков (а что со сторонними библиотеками тогда и как их обновлять)? Или ещё какой механизм?
Маленький косвенный пример про менеджеров.
Поставил я себе ubuntu 20.04 + Gnome.
Так вот оконный менеджен несомненно красивый. Но знаете что? Язык меняется кнопкой "Win+Space". И выставить смену языка через Alt+Shift или Ctrl+Shift нельзя (ах да можно поставить gnome-tweaks и через него уже выставить).
Вот это ситуация, когда нет менеджера.
О скучных мелочах думать некому (хотя оконный интерфейс реально красивый, наверное красивее чем в Win - но это уже субьективно).
Программист драйверов для ядра linux должен иметь в виду, что переменная jiffies (счётчик прерываний от таймера с момента старта системы) может переполнится (это цитата то-ли из LDD то или из комментария к linux_headers).
гарантируется размер не менее, чем uint64.
Что может произойти - из типового, что приходит в голову на каком-нибудь активном пуллинге с таймаутом (вычитывании готовности данных из устройства внутри драйвера) мы попадём на переполнение jiffies и "зависнем".
Дальше проблемы (не)снятия драйвера зависят от криворукости программиста в остальных местах.
>> т.к. для сеньора задания из серии «пойди туда, не знаю куда, принеси то, не знаю что» являются вполне себе типовыми.
Мне кажется, что вы сильно всё усложняете.
В моей практике в 90% (если не 95%-99%) уточнящий вопрос "а что реально надо-то?" расставляет всё по своим местам (в смысле ты получаешь +/- ссылку релевантную ссылку на условия решаемой задачи за минуту).
И излишнее усложнение общения (в том числе тонна необязательных уточняющих вопросов) - на первый взгляд характеризует вас отрицательно.
Простите, но если всё вмещается в условный L2 кэш (порядка 10 тактов доступа) - то это тоже без дополнительных приседаний не то, чтобы сильн оспасает отца русской демократии, от дата-столов.