Comments 27
Very long Instruction Pointer
Vector Instruction Pointer
Историю как отжимали исходники у Sun с помощью Apache Harmony я слышал раньше. А вот теперь узнал что стало с инженерами(
Как итог – я вышел на сцену, глубоко вздохнул, зажмурился и выдал текст, который должен был говорить Трэвис.
Но что-то его держало. Может быть трое детей, а может быть и опционы
(Запевая на манер песни "Вечная Молодость" Чижа)
Прикольно, что часть Apache harmony много лет после закрытия нашей питерской команды еще была в google android, пока они не переписали сами.
Так и случилось с Google что от любви до ненависти к Java был один шаг и десяток строчек кода. До судебного процесса с Oracle. GNU Classpath из GCJ был не конкурент Apache Harmony, безальтернативный выбор для них тогда.
Apache Harmony дал свободу, спасибо всем людям кто его разрабатывал!!! Достаточно давно я рылся в исходниках Harmony за JDBC/Sound API и успешно перенес эту часть на JavaME, чтобы запустить на MIPS роутере сервлет с доступом к PostgreSQL.
> Но большая часть команды перетекла в NVidia — таким образом Интел сделал королевский подарок своему прямому конкуренту.
А сколько времени вообще стоит набор такой команды и вывод её на "проектную мощность"?
Если пытаться переманивать - это страшно дорого. Зарплаты рекрутеров, время интервьюеров, бонусы и тд и тп. НВидии досталось практически бесплатно, потому что люди сами искали работу. Насчет вывода на проектную мощность - тут все очень сильно от типа работы зависит. У меня в свое время было эмпирическое правило: в VTune, которым я рулил последние годы своей карьеры в Интел адаптация занимала от полугода до года. VTune - это по сути обычная аппликуха, если не считать коллекторов и драйверов. В математические библиотеки (типа MKL) - от года до полутора. В компиляторы - от полутора до двух.
Если пытаться переманивать - это страшно дорого.
Подозреваю, что если собирать группу заново, с нуля, то от двух лет и далее? Это ведь надо сперва людей собрать, что делается не один день, а потом вывести на проектную мощность.
В компиляторы - от полутора до двух.
Круто... Если в таких условиях приходится группу увольнять, то выходит, что контора Интел маловата для таких масштабных проектов. То есть, чтобы содержать группу компиляторщиков, нужно иметь несколько контор...
Видимо, на этом llvm/gcc и взлетели — в теории, их разработчики при переходе в другую контору могут продолжать заниматься тем же проектом, просто чуть другой частью. То есть, получается, что группа не распадается при перетасовках/увольнениях.
Про такой эффект, вроде, Столлман не говорил.
Тут еще стоит добавить, что в NVidia команда БТ перешла почти целиком с менеджером и под условием команду не дробить. Т.е. оставалось вникнуть в детали нового проекта.
@vvvphoenix у вас в начале статьи гиперссылки Часть 5 и Часть 6 на одну страницу ведут
поправьте пожалуйста Часть 13 и Часть 14 ссылаются на одну и ту же страницу
решение не мое, а вышестоящего начальства
С*ка, ненавижу... Вот в одной российской компании, слишком известной, чтобы называть её здесь, я постоянно слышал эту фразу: «Всё уже решено, что я могу сделать...» Когда я услышал её от директора департамента, понял, что оттуда надо валить. Свалил в течение месяца. С тех пор рекрутёры оттуда приходят регулярно, но шлю их лесом.
Ну так то действительно есть решения, которые не зависят от твоего уровня. Если это частная контора, то как решат владельцы, ты ничего не сможешь сделать, если государственная, то чиновники и тоже ничего не сделаешь. Это как бы нормально.
Другое дело, что есть решения, которые ты сам волен принимать на своем уровне, то тогда да, это выглядит как перекладывание отвественности.
Есть такие решения, безусловно. Но в нормальной ситуации хорошо бы знать, кто эти решения принимает. Понятно, рядовому программисту даже эти знания ни к чему, но директору департамента?
Ну то есть не «всё уже решено», а «это приказ г-на Имярекова» или «это решение принято на заседании Совета 32 мартобря». Или даже «это требование регулятора, содержащееся в циркуляре 12345/ОЫРПВЕ-бис». Но не «...решено...»
ну сделают "ваш личный номер в списке на увольнение 3/10, номер вашего отдела на роспуск 9/10" и потом каждый месяц будете смотреть на свой рейтинг "мы набрали 10 новых команд" (и распустим 3 - т.е. вашу тоже)
но я с вами абсолютно согласен - я обеими руками за прозрачность.
Вы совсем не с тем спорите.
Важно, кто принял решение. Зная это, можно попытаться поговорить с тем, кто – если, конечно, это в твоих возможностях. Можно попытаться понять его мотивацию. Короче, можно хоть как-то пытаться осмыслить и изменить ситуацию. А если решение просто «принято» какими-то Неизвестными Отцами, то нет большой разницы между «уволить тебя, тебя и тебя» и «ваш рейтинг 3/10».
я к тому, что если есть люди - то конечно хочется с ними поговорить.
Но иногда это тупо процедура,
и как "вернуть людей" обратно на управление - непонятно :(
Важно, кто принял решение. Зная это, можно попытаться поговорить с тем, кто
Если бы эти люди хотели с вами поговорить, они бы это сделали.
Как мне кажется они наоборот, не хотели бы с вами разговаривать.
Так проще и безопаснее.
Спасибо, Валера, за сохранение памяти об этих и других событиях. Хоть что-то останется записанным.
Как участник тех событий: Unipro_Sun -> Intel_Harmony -> Intel_Sun -> Intel_VIP, подтверждаю - веселые были времена.
VIP был очень интересным проектом. Его ISA был взрыв мозга. Особенно отладка assembler программ :)
А performance analysis так вообще был на уровне magic. Часть людей осела в Arm.
Спасибо, Валерий, очень интересно.
Как автор потактового симулятора VIP добавлю фидбэка и комментариев.
Весь пассаж про VLIW нужно переписать. Система команд была VIP, а не VLIW и различия не косметические, а принципиальные. VLIW был Эльбрус, Итаниум, Трансмета, но в том-то и гениальность БАБ, что он не стал цепляться за старое (мог бы! кое-где ещё ходят слухи что он забрал что-то из МЦСТ, но нет!), а придумал совершенно новое. Во VLIW компилятор склеивает независимые инструкции в одну большую. Иногда они потом распадаются для независимого исполнения в аппаратуре. В VIP нет ничего подобного! Инструкции индивидуальны изначально, но вводится инструкция fork, которая порождает независимый поток. Все как с multithreading, только в ассемблере и со взаимодействием потоков через регистры, а не память. Это позволяет компилятору отображать граф вычислений как он есть в ассемблере, а аппаратура уже сама разбирается как его вычислять.
Все разработчики понимали множество спорных моментов, особенные трудности с бинарной трансляцией, не было никакой слепой веры (полный оптимизм излучал только БАБ). Но делали из этого свой вывод: значит нужно исследовать и искать решения. Ведь фундаментальная идея очень красивая (оригинальная версия data flow machine) и стоит того чтобы прилагать усилия.
То что новая система команд это мелочи, ну RISC V никого же не смущает сегодня, есть ниша. Динамическая бинарная трансляция тогда казалась самой спорной частью. А сегодня весь Android с DBT, и норм, главное что оттранслированный код сохраняется на диске (и мы думали также).
Жаль, очень жаль проект...
Made at Intel. Окаянные дни – продолжение