Я бы не был так уверен. У атома суровые проблемы с производительностью при редактировании больших файлов, а файлы больше 2МБ он вообще не открывает. Этот же редактор легко переварил файл в 100МБ без лагов. Так что если они и форкнули атом, то оптимизировали они его нехило.
С другой стороны, если бы компилятор не проверял this на null при вызове, то пришлось бы городить ещё большие костыли в каждом из методов, либо довольствоваться менее понятными исключениями, когда NullReferenceException выбрасывался бы изнутри вызываемого метода, а не в месте его вызова. Так что, имхо, компилятор всё делает правильно.
Несколько месяцев назад успешно собеседовался на питон-разработчика в пару разных команд. Почитав статей и форумов о найме Яндекса, представлял собеседование как какой-то ад, на котором меня сначала завалят вопросами про давно забытые мной алгоритмы, за пару лет в простенькой серверной web-разработке пригодившиеся ровно 0 раз, потом размажут суровыми вопросами про особенности питона и никсов, и напоследок оставят на пару часов писать код какого-нибудь LL-парсера в унылом одиночестве. Факт того, что до Яндекса у меня было где-то собеседования три в мелких конторах Дальнего Востока, уверенности в своих силах не придавал.
Внезапно, действительность оказалась гораздо менее печальной — вопросы по питону были довольно стандартные и известные тем, кто хоть немного интересуется языком и его внутренностями. Вопросы по Linux для меня, как ASP.NET разработчика, оказались не настолько стандартными, но при наличии реального опыта работы с никсами ответить на них было бы не слишком сложно.
Код во время очного собеседования я вообще не писал, только во время скайп-интервью с одной из заинтересовавшихся команд надо было немного покодить в реальном времени в онлайн-паде на любом угодном мне языке (писал вообще на C#). Возможно, тут помогло наличие в резюме ссылки на гитхаб с парой мелких собственных проектов.
А на очном собеседовании несколько часов я занимался проектированием небольшой распределенной системы (уже забыл, что она делала) — как расположить сервера в разных ДЦ, как оптимально распределить между ними нагрузку, как обеспечить отказоустойчивость при этом потратив наименьшее количество денег, как бы я разбил данные и вообще что, как и почему бы использовал для БД. В общем, ни о чем ближе к реальности на собеседовании я и не мечтал. Само собой, были и вопросы по алгоритмам/структурам данных/простенькой математике, но тоже, в основном, привязанные к общей нити обсуждения.
В результате из офиса я вышел на позитиве — хоть интервью и было довольно изматывающим, я получил море удовольствия от простого обсуждения интересных вопросов с интервьюерами. Так что не все так страшно, как может показаться из некоторых статей. Команд много, и собеседования все тоже проводят по-разному. Знания, которые потребуются, тоже различны.
P.S. Во время интервью меня попросили описать, что делает один из моих проектов на гитхабе. Мелочь, но было приятно, что опенсорсный профиль не оказался в резюме мертвым грузом.
На данный момент операторам сайта 4chan.org отводится «установленное законом время» для того, чтобы принять меры и заблокировать или удалить проблемный контент.
Так вот они это и так делают, без просьб наших органов.
Возможно, это не будет так сильно заметно если реально писать на языке, да и прямой работы с лайфтаймами в коде Армина вроде не так уж и много, но пока подобный код вызывает приступы сомнения в новом убийце C++.
В задаче CaseInComparison ошибка — забыли ToUpper() для b в коде string.Compare(a.ToUpper(), b).
И маленькая хотелка — нет ровно никакого смысла делать перегрузку страницы по нажатию «решение» в онлайн версии, можно просто скрывать/показывать элемент. Сейчас постоянные перегрузки раздражают.
Edit: как-то пропустил, что онлайн версия сгенерена автоматом. Имхо, очень просто написать свою, более удобную для подобного контента.
мы можем вставлять элементы за константное время в любое место! По слухам удаляются элементы из списка тоже за O(1).
При наличии указателя на это место, т.е. в начало и, возможно, в конец, если список двусвязный. В противном случае требуется проход по всем элементам листа до нужного, что при рандомном расположении элементов в памяти может вылиться в серьезную проблему производительности. И часто получается так, что замечательная структура, предназначенная для быстрой вставки и удаления элементов, проигрывает глупому вектору.
Что имеется ввиду под профессиональным кино и видео пайплайном? Обработка? Окей, там разумно иметь 444 lossless.
Профессиональное сжатие? Увольте, большинство профессионалов во-первых, не умеют сжимать видео, а во-вторых, делают это в 420 8-бит, если мы говорим об обыкновенном видео на BD и прочих потребительских дисках/сервисах, а не узкоспециализированных областях.
В любом случае, проф. индустрия может работать с 444 изначально. При наличии же только 420 исходника как в статье, делать из него 444 имеет смысл только если (а) производится даунсайз картинки и (б) в хроме действительно есть что-то важное (много красного цвета и тонких деталей). В основном оно того не стоит.
В отличии от более клёвого сабсемплинга хромы, 10бит почти всегда понижают размер (иногда очень значительно в аниме) и никогда не вредят качеству. Так что ваш смех тут очень не к месту.
Это значит лишь то, что от декодера до madvr у вас идет полноценное 10-битное видео. А уже madvr его дитерит в 8бит и выводит вам на монитор. Так что комментатор в этом плане прав.
Впрочем, это нисколько не уменьшает пользы 10-битного видео, тема которого уже даже тут обсасывалась много раз.
Если вам нужен предсказуемый размер — вы кодируете в битрейт. Если вам нужно предсказуемое качество — в CRF. Какую предсказуемость вы хотите получить?
По опыту предыдущего топика я понял, что комментировать ваши мысли бесполезно. Но окей, покажите, пожалуйста, документацию, которая объясняет что preset — это не компромисс между скоростью и качеством, а что-то другое.
Потом покажите мне такую документацию, которая говорит, что деблок пытается соединить линии (как очень быстрый eedi3, да), а не просто немного замазывает границы макроблоков.
Как по мне, так вы пришли с XviD, выставили постоянный квантайзер и пытаетесь подобрать такие параметры, при которых у вас получится минимальный размер. Это в корне неверно, это не то, как используют x264. Это другой мир, попытайтесь разобраться в его правилах прежде чем нести откровенный нонсенс.
Кстати, вы случайно никак не связаны с человеком с ником «Жрец Нефтиды»?
В данном случае кодируем в 10 бит, поэтому high10, если в 8 — high.
Битность определяется на этапе компиляции и скодировать в 8 и 10 одним бинарником не выйдет. Так что и смысла выставлять профиль в принципе нет (если только не надо 4:2:2 или 4:4:4).
--input-res 1920x1080 --fps 23.976
Кроме извращенных случаев когда вы передаёте иксу RAW-видео, указывать эти параметры не нужно. FPS ещё может быть разумно если у вас таймкоды корявые в исходном контейнере (тогда ещё стоит --force-cfr может?), но указание разрешения — явно лишняя работа. Особенно если вы ещё раз указываете FPS при упаковке в mkv.
Кстати, --tune animation подходит только для очень чистых источников типа «три линии два градиента». В большом количестве случаев имеет смысл подкрутить aq вручную.
И мне интересно — какой смысл кодировать 10битное видео в 480p? На железках вы его всё равно не посмотрите, на телефоне смысла от 10 бит особого нет (и батарею жрет больше), а для компьютера с BD можно и 720 и выше делать.
Внезапно, действительность оказалась гораздо менее печальной — вопросы по питону были довольно стандартные и известные тем, кто хоть немного интересуется языком и его внутренностями. Вопросы по Linux для меня, как ASP.NET разработчика, оказались не настолько стандартными, но при наличии реального опыта работы с никсами ответить на них было бы не слишком сложно.
Код во время очного собеседования я вообще не писал, только во время скайп-интервью с одной из заинтересовавшихся команд надо было немного покодить в реальном времени в онлайн-паде на любом угодном мне языке (писал вообще на C#). Возможно, тут помогло наличие в резюме ссылки на гитхаб с парой мелких собственных проектов.
А на очном собеседовании несколько часов я занимался проектированием небольшой распределенной системы (уже забыл, что она делала) — как расположить сервера в разных ДЦ, как оптимально распределить между ними нагрузку, как обеспечить отказоустойчивость при этом потратив наименьшее количество денег, как бы я разбил данные и вообще что, как и почему бы использовал для БД. В общем, ни о чем ближе к реальности на собеседовании я и не мечтал. Само собой, были и вопросы по алгоритмам/структурам данных/простенькой математике, но тоже, в основном, привязанные к общей нити обсуждения.
В результате из офиса я вышел на позитиве — хоть интервью и было довольно изматывающим, я получил море удовольствия от простого обсуждения интересных вопросов с интервьюерами. Так что не все так страшно, как может показаться из некоторых статей. Команд много, и собеседования все тоже проводят по-разному. Знания, которые потребуются, тоже различны.
P.S. Во время интервью меня попросили описать, что делает один из моих проектов на гитхабе. Мелочь, но было приятно, что опенсорсный профиль не оказался в резюме мертвым грузом.
Вот тут говорят что будут использовать оба способа, так что не факт dirty-checking что уйдет окончательно.
Так вот они это и так делают, без просьб наших органов.
let y = if x == 5i { 10i } else { 15i }.Возможно, это не будет так сильно заметно если реально писать на языке, да и прямой работы с лайфтаймами в коде Армина вроде не так уж и много, но пока подобный код вызывает приступы сомнения в новом убийце C++.
string.Compare(a.ToUpper(), b).И маленькая хотелка — нет ровно никакого смысла делать перегрузку страницы по нажатию «решение» в онлайн версии, можно просто скрывать/показывать элемент. Сейчас постоянные перегрузки раздражают.
Edit: как-то пропустил, что онлайн версия сгенерена автоматом. Имхо, очень просто написать свою, более удобную для подобного контента.
При наличии указателя на это место, т.е. в начало и, возможно, в конец, если список двусвязный. В противном случае требуется проход по всем элементам листа до нужного, что при рандомном расположении элементов в памяти может вылиться в серьезную проблему производительности. И часто получается так, что замечательная структура, предназначенная для быстрой вставки и удаления элементов, проигрывает глупому вектору.
Тут несколько довольно очевидных решений.
Если
if(x)не считается сравнением, то тогда сработает простой нисходящий цикл.Если считается, то сработает тот же цикл с switch.
Наличие реальных операций сравнения в генерируемом коде зависит от компилятора.
Чуть более «веселое» решение доступно в языках, где деление на ноль вызывает исключение.
Рекурсия при желании заменяется на бесконечный цикл, работающий аналогичным образом.
Тут больше радует факт переезда исходников TypeScript с CodePlex на GitHub.
Профессиональное сжатие? Увольте, большинство профессионалов во-первых, не умеют сжимать видео, а во-вторых, делают это в 420 8-бит, если мы говорим об обыкновенном видео на BD и прочих потребительских дисках/сервисах, а не узкоспециализированных областях.
В любом случае, проф. индустрия может работать с 444 изначально. При наличии же только 420 исходника как в статье, делать из него 444 имеет смысл только если (а) производится даунсайз картинки и (б) в хроме действительно есть что-то важное (много красного цвета и тонких деталей). В основном оно того не стоит.
В отличии от более клёвого сабсемплинга хромы, 10бит почти всегда понижают размер (иногда очень значительно в аниме) и никогда не вредят качеству. Так что ваш смех тут очень не к месту.
Впрочем, это нисколько не уменьшает пользы 10-битного видео, тема которого уже даже тут обсасывалась много раз.
По опыту предыдущего топика я понял, что комментировать ваши мысли бесполезно. Но окей, покажите, пожалуйста, документацию, которая объясняет что preset — это не компромисс между скоростью и качеством, а что-то другое.
Потом покажите мне такую документацию, которая говорит, что деблок пытается соединить линии (как очень быстрый eedi3, да), а не просто немного замазывает границы макроблоков.
Как по мне, так вы пришли с XviD, выставили постоянный квантайзер и пытаетесь подобрать такие параметры, при которых у вас получится минимальный размер. Это в корне неверно, это не то, как используют x264. Это другой мир, попытайтесь разобраться в его правилах прежде чем нести откровенный нонсенс.
Кстати, вы случайно никак не связаны с человеком с ником «Жрец Нефтиды»?
Битность определяется на этапе компиляции и скодировать в 8 и 10 одним бинарником не выйдет. Так что и смысла выставлять профиль в принципе нет (если только не надо 4:2:2 или 4:4:4).
Кроме извращенных случаев когда вы передаёте иксу RAW-видео, указывать эти параметры не нужно. FPS ещё может быть разумно если у вас таймкоды корявые в исходном контейнере (тогда ещё стоит --force-cfr может?), но указание разрешения — явно лишняя работа. Особенно если вы ещё раз указываете FPS при упаковке в mkv.
Кстати, --tune animation подходит только для очень чистых источников типа «три линии два градиента». В большом количестве случаев имеет смысл подкрутить aq вручную.
И мне интересно — какой смысл кодировать 10битное видео в 480p? На железках вы его всё равно не посмотрите, на телефоне смысла от 10 бит особого нет (и батарею жрет больше), а для компьютера с BD можно и 720 и выше делать.