Я не могу представить это по другой причине. На первом курсе человек не может ничего. Но практика у нас было в аутсорс компании крупной местной (название уже не помню), по программе обучения. На курсе 3 вроде бы.
1. Судя по успехам ИТМО в области квантовых вычислений, что-то там таки есть
2. Нет. При трудоустройстве ты четко озвучиваешь, когда и сколько можешь работать. Программа к 4-5 курсу позволяет работать достаточно нормально.
3. Ниодного факта коррупции не было ни при мне, ни на уровне слухов среди студентов. Ни одного за все 5 лет учебы. Вся группа честно училась и честно сдавал каждый зачет. Собственно, с учетом бальной системы обучения на первом курсе это сложно чисто технически было бы
4. Для ИТМО не актуально по большей части. С одной стороны, потому что преподы нормальные есть. С другой, потому что преподают в основном вещи универсальные, а не модные технологии, от которых для меня в универе никакого толку не было бы все равно. Хочешь модные технологии — универ рекламировал тонны курсов дополнительных с сертификацией
5. Присутствует и прямо включено в программу обучения.
Возьмем ObjC, канонический ООП язык. Отправителя автоматически не получить, броадкаст сообщений нет. Даже посылка сообщений максимально зарезана в пользу статического анализа, что выглядит уже как методы обычные.
А что до С++, передавайте отправителя аргументом.
Уровень графики зависит от самой графики — шейдеров и арта. Написан движок на С или C# уже имеет малое значение, потому что современные проекты упираются в GPU в подавляющем большинстве случаев. Взять тот же Unity на mono. Когда же тебе важна CPU производительность, то выбор практически всегда С++. Банально, настолько сложные архитектурно проекты сложно писать на С и С++ не случайно является де-факто стандартом в геймдеве.
Я при поступлении каким-то образом был прекрасно осведомлен, что олимпиадники это один этот факультет. Он на этом специализируется, поэтому не удивителен результат. Наверное потому что почитал хотя бы немного про то, куда собрался поступать. Строить свое мнение об университете по одной статье, тем более обо всех факультетах — по0моему такому уникальному человеку нечего делать там.
Что до программы обучения. Я закончил ИТиП кафедру ИС. Могу сказать, что практически вся группа к 4-5 курса работала по специальности. Из параллельных групп тоже много подобных людей было. Думаю, это таки показатель, что университет свою работу делает. Мне интересно, что же вы подразумеваете под «постсоветским» ВУЗом? Видимо что-то плохое, но не совсем понятно, что именно.
Странное умозаключение. Посмотрел примеры Perspex и его paml — практически копия xaml. Ну да ладно, WPF в любом случае никуда не денется с позиции основного инструмента UI приложений на Windows. По крайней мере, пока MS стоят за ним и поставляют в комплекте. Они как раз вновь подтвердили, что WPF — это тот самый и единственный выбор на Windows платформе.
Все время, что им пользовался, вроде правильно отрисовывал, по крайней мере в 12-13 студиях. Мне точно нужен, но мне и студии хватает. Потребности в сторонней IDE для этого нет и вряд ли будет. Тем более для WPF, который до сих пор только Windows. В любом случае на Windows потеснить студию вряд ли получится ни в ближайшем, ни далеком будущем. А вот на linux/mac в свете движения .Net туда будет очень здорово видеть что-то полноценное.
У меня вот что-то ваш софт тормозит жутко. В качестве сервака обычная машина Core i5-4570, 16ГБ оперативы, 3 диска RAID5 в качестве хранилища. Помню ваше требование, что document и community сервера под виндой на одной машине не ставятся (хотя руками конфиги я как-то пробовал править и кое-как оно запускалось), поэтому запустил их в ubuntu виртуальной машине через docker, где помимо этого работает еще gitlab. Сразу скажу, что последний там летает и ниразу не доставлял проблем даже, когда виртуалке были отданы 2 ядра и 4ГБ памяти.
В данный момент, чтобы хоть как-то это работало, виртуалке выделены все 4 ядра и 8 ГБ оперативы. Софт выжирает все эти 4 ядра запросто на 100% и около 4 ГБ оперативы просто на пустом инстансе, когда я один жмакаю по интерфейсу. Да еще и своп жирный в требованиях прописан. Особенно жутко медленно работает контрольная панель — она запросто вываливается в timeout при попытке проверки версий, при холодном старте требует минутных ожиданий, пока там что-то продумается, прокешируется видимо. После чего более менее начинает ворочаться. Периодически все равно помирает. Сам community и document сервер работает лучше, но тоже периодически начинают о чем-то думать. При холодном старте опять же что-то там видимо кешируется, что сопровождается секундными задержками открытия страниц.
В общем, после таких чудес под большим вопрос находится приобретение платной версии продукта. Даже с учетом виртуальной машины и RAID5 такого быть не должно. Сразу скажу, что последний работает с включенным кешированием и массив выдает в бенчмарках цифры даже выше, чем один диск сам по себе, судя по обзорам.
Не знаю насчет бесполезности. nvidia карты получают заметный прирост в играх, которые это поддерживают. Тут зависит от дров. АМД действительно однопоточные и от контекстов там толку никакого, только хуже становится.
Ну отложенные контексты DX11 с прицелом на многоядерность и сделаны, тут уж никак. И они вроде работают, но оверхед все равно остается от дров и рантайма, плюс эту многопоточность сделала нормально только нвидия, а на амд вообще даже теряется производительность при ее включении в играх. Зато вот с DX12 амд отыгралась по полной, по крайней мере в синтетике имеющейся.
Я так понимаю DX12 будет существовать параллельно с DX11 пока что. Не зря же все новые фичи оба получили. Насчет на «вы», этим людям лучше использовать готовые движки, благо сейчас выбор богат как никогда.
DX12 как раз прибавляет, ибо совершенной иной API, нежели прошлые DX, нацеленные именно на производительность. Да и прошлые прибавляли — уменьшение стоимости DIP и оптимизация рантайма дежурные улучшения каждой мажорной версии, не считая железных фич, которые упрощают и ускоряют то, что раньше делали через ж или вообще не делали. Насчет качества картинки, практически все ААА игры сегодня это DX11 или DX10 минимум и никак иначе в будущем не будет — консоли задают планку, а это DX11-DX12. И речь тут не только о качестве картинки, DX вообще мало коррелирует с ней — это всего лишь API. 9 версия устарела, ее API устарел еще со времен 10 версии, на нем неудобно реализовывать многие современные техники и, я уверен, многие даже невозможно в силу того, что каждая DX таки приносит с собой новые фичи из железа. И каждый разработчик уже отметился благодарностью, что современные консоли это DX11 уровень по фичам, а xbox one вообще базируется на DX11 и в будущем получит DX12. Надеюсь не надо объяснять, почему это так важно.
Прикол Go в том, что картинка с двумя очередями и одним автоматом легко превращается в картинку с двумя очередями и двумя автоматами. И все сводится к одной системной переменной GOMAXPROCS. Если использовать горутины, то даже при GOMAXPROCS=1 мы получаем конкурентный код. Наш код, по сути, однопоточен и непараллелен, но он конкурентный. Как только GOMAXPROCS становится равно числу ядер и это число больше 1, то наш код становится еще и параллельным. В силу примитивов языка это делается именно так просто, если конечно конкурентный код правильно написан. И кажется именно об этом говорит Пайк. У него на этому тему отдельная лекция есть.
Замечательно конечно, но я не вижу тут большого практического преимущества у Д. Просто потому что в реальной задаче я не буду этим заниматься — этим будет заниматься база данных скорее всего, а с учетом позиционирования Go именно так и будет. А если будет иначе, то не будет 100500 вариантов сортировки. Go отчего и поднялся, потому что он нашел свою нишу, в которую его силами гугл и заталкивает. В этой нише ему это все не особенно нужно — подготовкой массивов данных в сервисах обычно занимаются другие части системы. А D, будучи языком общего назначения, возможно как раз и нужно, чтобы покрывать намного больший круг задач. Но даже в этом случае данный конкретный пример не показывает мне практических преимуществ, чисто теоретическая мерка цифрами.
По ссылке пример боевого кода с пользовательским типом, зачем мне абстрактные бессмысленные примеры. Все выглядит вполне нормально и обыденно. Реализуем для нашего типа интерфейс сортировки и вперед. Мериться строчками в данном случае неблагодарное дело, которое не имеет никакого значения к реальным преимущества языков. Код Go элементарен и не настолько сильно больше. Я вспоминаю C#, где не сильно меньше надо делать — для каждого пользовательского типа нужно реализовать интерфейс сравнения, чтобы он сортировался. Обыденный паттерн нынче.
Ох не знаю про раст. Каждый раз при виде кода мне становится страшно. Выглядит и читается это все намного сложнее С++ и по описанию его возможностей похоже намутить непонятных в будущем никому конструкций на нем будет еще проще, чем на плюсах
А как в ARC работает? Точно так же — когда счетчик до нуля доходит, тогда и освобождается объект. Но в примере то он не доходит до нуля и все из-за пула. Мне не понятно уже, с чем вы не согласны. ARC работает так же, как работает программист, когда использует старую модель. Ровно ноль отличий. Раньше советовали же осторожно работать с autorelease переменными — они копятся и не освобождаются, память может кончиться. Есть только два решения — не использовать пул или обернуть код в еще один пул, который бы освобождался на каждой итерации. Все это справедливо и сейчас, пулы никуда не делись. По идее, их можно было бы вообще убрать, не будь у нас старого кода, который от них зависит.
То есть, если бы вместо autorelease вызывался бы release — autorelease pool бы не использовался и утечки бы не было бы.
Вы видимо хотели что-то другое сказать. В примере autorelease вызывается ровно один раз — внутри конструктора. Вызов на этом месте release привел бы к нехорошим последствиям.
Вообще, единственный случай, который я знаю, когда именно ARC вставляет autorelease вызовы, это при работе с указателями на указатель. В ином случае все происходит детерминировано и так, как вы описали — дошел счетчик до нуля и тут же освободилось все.
ARC тут никак не поможет. Он скорее всего в теле цикла все вставляет правильно — ref count + 1 при объявлении переменной, ref count -1 в конце цикла. Но пул то свою ссылку держит и никуда не отдаст, пока его не освободишь, а значит объект будет жив. Если ты переменной присваиваешь иное значение (nil, чтобы намеренно освободить объект), то ARC тоже вставляет release — не освобождает, а понижает счетчик ссылок. И до ARC все работало точно так же. Ничего абсолютно не поменялось в механизмах работы с памятью. Единственное реальное новшество это weak переменные разве что.
Я бы сказал, что как раз боевой. В больших циклах, где много работы с памятью, этот пример очень важен для понимания. Иначе можно стать заложником out of memory. До ARC эта проблема была очевиднее, поэтому взял за правило оборачивать особо критичные места в свой autorelease pool.
Еще более насущные примеры, когда приложение реализовано через бесконечно цикл, которые работает на всем протяжении жизни приложения, что редко, но все таки бывает.
1. Судя по успехам ИТМО в области квантовых вычислений, что-то там таки есть
2. Нет. При трудоустройстве ты четко озвучиваешь, когда и сколько можешь работать. Программа к 4-5 курсу позволяет работать достаточно нормально.
3. Ниодного факта коррупции не было ни при мне, ни на уровне слухов среди студентов. Ни одного за все 5 лет учебы. Вся группа честно училась и честно сдавал каждый зачет. Собственно, с учетом бальной системы обучения на первом курсе это сложно чисто технически было бы
4. Для ИТМО не актуально по большей части. С одной стороны, потому что преподы нормальные есть. С другой, потому что преподают в основном вещи универсальные, а не модные технологии, от которых для меня в универе никакого толку не было бы все равно. Хочешь модные технологии — универ рекламировал тонны курсов дополнительных с сертификацией
5. Присутствует и прямо включено в программу обучения.
А что до С++, передавайте отправителя аргументом.
Что до программы обучения. Я закончил ИТиП кафедру ИС. Могу сказать, что практически вся группа к 4-5 курса работала по специальности. Из параллельных групп тоже много подобных людей было. Думаю, это таки показатель, что университет свою работу делает. Мне интересно, что же вы подразумеваете под «постсоветским» ВУЗом? Видимо что-то плохое, но не совсем понятно, что именно.
Странное умозаключение. Посмотрел примеры Perspex и его paml — практически копия xaml. Ну да ладно, WPF в любом случае никуда не денется с позиции основного инструмента UI приложений на Windows. По крайней мере, пока MS стоят за ним и поставляют в комплекте. Они как раз вновь подтвердили, что WPF — это тот самый и единственный выбор на Windows платформе.
В данный момент, чтобы хоть как-то это работало, виртуалке выделены все 4 ядра и 8 ГБ оперативы. Софт выжирает все эти 4 ядра запросто на 100% и около 4 ГБ оперативы просто на пустом инстансе, когда я один жмакаю по интерфейсу. Да еще и своп жирный в требованиях прописан. Особенно жутко медленно работает контрольная панель — она запросто вываливается в timeout при попытке проверки версий, при холодном старте требует минутных ожиданий, пока там что-то продумается, прокешируется видимо. После чего более менее начинает ворочаться. Периодически все равно помирает. Сам community и document сервер работает лучше, но тоже периодически начинают о чем-то думать. При холодном старте опять же что-то там видимо кешируется, что сопровождается секундными задержками открытия страниц.
В общем, после таких чудес под большим вопрос находится приобретение платной версии продукта. Даже с учетом виртуальной машины и RAID5 такого быть не должно. Сразу скажу, что последний работает с включенным кешированием и массив выдает в бенчмарках цифры даже выше, чем один диск сам по себе, судя по обзорам.
Я так понимаю DX12 будет существовать параллельно с DX11 пока что. Не зря же все новые фичи оба получили. Насчет на «вы», этим людям лучше использовать готовые движки, благо сейчас выбор богат как никогда.
А если уж прям так хочется сделать короче, не знаю зачем вообще, то первая ссылка в гугле даст достаточно решений stackoverflow.com/questions/28999735/what-is-the-shortest-way-to-simply-sort-an-array-of-structs-by-arbitrary-field В том числе практически идентичное тому, что представили вы.
Открыть документацию golang.org/pkg/sort и скопипастить пару строчек для реализации интерфейса сортировки
Вы видимо хотели что-то другое сказать. В примере autorelease вызывается ровно один раз — внутри конструктора. Вызов на этом месте release привел бы к нехорошим последствиям.
Вообще, единственный случай, который я знаю, когда именно ARC вставляет autorelease вызовы, это при работе с указателями на указатель. В ином случае все происходит детерминировано и так, как вы описали — дошел счетчик до нуля и тут же освободилось все.
Еще более насущные примеры, когда приложение реализовано через бесконечно цикл, которые работает на всем протяжении жизни приложения, что редко, но все таки бывает.