Весь менеджмент в электронных компаниях, а особенно в компаниях по semiconductor IP и EDA tools вышел их из инженеров. В последних в том числе sales & marketing.
В этой же школе все равно должны чему-то учить. Почему это не обсуждается? Даже в младшие партнеры венчурного фонда не берут просто за то, что ребенок летал на самолете в шато во Франции.
Я тоже стемлюсь запустить быстрее, но делаю для этого законченную версию с подмножеством фич. А потом иду на другой круг спирали, и делаю версию с большим количеством фич. Стараюсь избегать заглушек и копипасты того что не планирую иметь в будущем.
Я собственно не против людей которые предпочитают отлаживать, а не писать. Я против постановки таких тандемов, где те, кто склонен к отладке и имеют ограниченный опыт, ставится определять архитектуру, а люди с опытом в определении архитектуры - ставятся чтобы это очищать, особенно если он не любит процесс отладки вообще и отлаживать сделанный наспех чужой код в частности.
Вы переосмыслитель-рационализатор, это отдельная роль. Я такое вчера сделал на работе, показал как некий процесс (синтез проекта на Synopsys Fusion Compiler) можно реорганизовать, чтобы он для решения проблемы разработчика (меня) занимал 15 минут, а не 4 дня на итерацию.
Да, у меня тоже спиральный подход, я даже думал это упомянуть, но решил не перегружать заметку. Но в моей спирали с сразу пишу небольшой код с ограниченной но законченной функциональностью, а потом пишу следующий вариант больше, на основе первого опыте. Это мне легче, чем сначала слепить кучу из вторсырья.
Проблема с перлом, что в нем есть неинтуитивные странности, вплоть до такого шухера что глобальные переменные $a и $b зарезервированы для сортировки. Ну и аргументы $1 $2 $3 нужно все время переназывать
Пардон, но в ASIC если это делать по всему чипу, то прибежит начальница и скажет "ты чего, совсем офигел? Мы тут всеми силами пытаемся избежать жидкостного охлаждения, а ты флип-флопами разбрасываешься как не в себе". У меня был ровно такой случай в Juniper Networks.
Проблема с микрокодом: Если расжевывать его на целую большую главу, как я видел в некотором учебнике, то студенты будут думать что они уже знают гибкий способ реализации процессора и могут меньше уделять вниманию вариантам конвейерной реализации. Кроме этого такая глава отнимала бы место в программе обучения (особенно если ее делать с лабами), а студенты и так плавают на интервью в компании из-за недостаточного количества лаб и упражнений по конвейерной обработке данных.
Одна и та же архитектура (система команд) может быть реализована разными микроархитектурами (аппаратным устройством процессора). Подход который я поддерживаю: взять одну архитектуру (сейчас удобно брать RISC-V) и показать как на ней строится однотактный процессор, много тактный, конвейерный с простым конвейером, суперскаляр, процессор с расширением векторными операциями итд. Конечно стоит упомянуть что в прошлом были разные школы мысли и обстоятельства (микрокод, аккумуляторные архитектуры когда доступ к памяти быстрее арифметики, стековые архитектуры), но детально в них углубляться не стоит для экономии времени.
Насчет dsp я с вами согласен. Там другие бенчмарки и приоритеты и современные dsp процессоры как раз можно показывать как пример влияния факторов вне процессоров общего назначения.
Я считаю, что уж если вводить историю, то стоит показыывать примеры того, что было реальными инновациями - CDC-6600 (out-of-order), Cray-1 (векторные регистры), IBM 801 (первый RISC) итд. Потому что в них есть эти инновации в достаточно чистой форме и можно объяснить, почему они появились. Учить же популярные но достаточно никакие вещи (как историю x86) - это значит отнимать время от других, более полезных предметов.
Если взять скажем PDP-11, то важно показать всю историю, а не только "смотрите как круто, что что сишная конструкция p++ = q++ делается одной инструкцией процессора". PDP-11 и многие другие процессоры конца 1960-х - 1970-х годов строились на допущении, что если строить процессор на основе микрокода и усложнять инструкции, то будут высокие бенчмарки при разумной для разработки и верификации сложности процессора. Но вот группа MIPS/Хеннесси в Стенфорде в 1978-1980 показала, что большинство сложных инструкций редко используются, а если конвейеризовать простые, то можно достигнуть более высоких бенчмарк при сравнимом по сложности процессоре. Вот это урок, который можно рассказать. А если оставить только первую часть истории "смотрите как круто с p++ = q++", то это будет вредный урок.
Ликбез о чем идет речь: софвер Синопсиса используют инженеры для проектирования микросхем. В комментариях мой слайд про процесс: код на языке SystemVerilog превращается в граф из логических элементов и элементов состояния (D-триггеров), потом программы размещения и трассировки раскладывают и соединяют этот граф по площадке микросхемы.
Сравните это с тем что происходит при разработке софтвера:
Я не "суров", а просто документировал опыт прошедшего года как он есть: студенты скидывали тестовое задание на ИИ, ИИ лажал вот таким, таким и таким образом. Вывод: студентов нужно учить так, чтобы они могли и без ИИ. Вы с этим не согласны?
Я могу похвастатся что она стала блоггершей после общения со мною, когда увидела мои блоги. "После" не означает "вследствие" но тем не менее :-) Раньше она ничего в линкине не писала. Вообще она интересная женщина, устраивала митинги в новогоднюю ночь, писала экспрессивные емейлы с обсуждением микроархитектурных проблем в 3 часа ночи итд.
Я не пытаюсь определить что возможно и что невозможно. Я лишь рапортую что было и утверждаю что студенты должны это уметь делать без ИИ, иначе не смогут даже понять когда ИИ лажает.
Весь менеджмент в электронных компаниях, а особенно в компаниях по semiconductor IP и EDA tools вышел их из инженеров. В последних в том числе sales & marketing.
В этой же школе все равно должны чему-то учить. Почему это не обсуждается? Даже в младшие партнеры венчурного фонда не берут просто за то, что ребенок летал на самолете в шато во Франции.
Я тоже стемлюсь запустить быстрее, но делаю для этого законченную версию с подмножеством фич. А потом иду на другой круг спирали, и делаю версию с большим количеством фич. Стараюсь избегать заглушек и копипасты того что не планирую иметь в будущем.
Я собственно не против людей которые предпочитают отлаживать, а не писать. Я против постановки таких тандемов, где те, кто склонен к отладке и имеют ограниченный опыт, ставится определять архитектуру, а люди с опытом в определении архитектуры - ставятся чтобы это очищать, особенно если он не любит процесс отладки вообще и отлаживать сделанный наспех чужой код в частности.
Вы переосмыслитель-рационализатор, это отдельная роль. Я такое вчера сделал на работе, показал как некий процесс (синтез проекта на Synopsys Fusion Compiler) можно реорганизовать, чтобы он для решения проблемы разработчика (меня) занимал 15 минут, а не 4 дня на итерацию.
Дважды поправил, спасибо.
Да, у меня тоже спиральный подход, я даже думал это упомянуть, но решил не перегружать заметку. Но в моей спирали с сразу пишу небольшой код с ограниченной но законченной функциональностью, а потом пишу следующий вариант больше, на основе первого опыте. Это мне легче, чем сначала слепить кучу из вторсырья.
У вас для Агата, а я видел на MSX. Возможно он был и на одной и на другой платформе, но я не уверен.
Что вы имеете в виду? С моей точки зрения перловская передача параметров выглядит криво:
sub f {
my ($a, $b, $c) = @_;
Проблема с перлом, что в нем есть неинтуитивные странности, вплоть до такого шухера что глобальные переменные $a и $b зарезервированы для сортировки. Ну и аргументы $1 $2 $3 нужно все время переназывать
Не совсем понял вашу мысль. Вы хотите сказать что в генерируемый ИИ код смотреть не надо?
Пардон, но в ASIC если это делать по всему чипу, то прибежит начальница и скажет "ты чего, совсем офигел? Мы тут всеми силами пытаемся избежать жидкостного охлаждения, а ты флип-флопами разбрасываешься как не в себе". У меня был ровно такой случай в Juniper Networks.
Си - наше все.
Мне прислали приглашение. Вот вебсайт https://unicorn.events/
https://luma.com/aoowunfh?tk=6r5jp6
Это нужно проиллюстрировать:
Проблема с микрокодом: Если расжевывать его на целую большую главу, как я видел в некотором учебнике, то студенты будут думать что они уже знают гибкий способ реализации процессора и могут меньше уделять вниманию вариантам конвейерной реализации. Кроме этого такая глава отнимала бы место в программе обучения (особенно если ее делать с лабами), а студенты и так плавают на интервью в компании из-за недостаточного количества лаб и упражнений по конвейерной обработке данных.
Одна и та же архитектура (система команд) может быть реализована разными микроархитектурами (аппаратным устройством процессора). Подход который я поддерживаю: взять одну архитектуру (сейчас удобно брать RISC-V) и показать как на ней строится однотактный процессор, много тактный, конвейерный с простым конвейером, суперскаляр, процессор с расширением векторными операциями итд. Конечно стоит упомянуть что в прошлом были разные школы мысли и обстоятельства (микрокод, аккумуляторные архитектуры когда доступ к памяти быстрее арифметики, стековые архитектуры), но детально в них углубляться не стоит для экономии времени.
Насчет dsp я с вами согласен. Там другие бенчмарки и приоритеты и современные dsp процессоры как раз можно показывать как пример влияния факторов вне процессоров общего назначения.
Я считаю, что уж если вводить историю, то стоит показыывать примеры того, что было реальными инновациями - CDC-6600 (out-of-order), Cray-1 (векторные регистры), IBM 801 (первый RISC) итд. Потому что в них есть эти инновации в достаточно чистой форме и можно объяснить, почему они появились. Учить же популярные но достаточно никакие вещи (как историю x86) - это значит отнимать время от других, более полезных предметов.
Если взять скажем PDP-11, то важно показать всю историю, а не только "смотрите как круто, что что сишная конструкция p++ = q++ делается одной инструкцией процессора". PDP-11 и многие другие процессоры конца 1960-х - 1970-х годов строились на допущении, что если строить процессор на основе микрокода и усложнять инструкции, то будут высокие бенчмарки при разумной для разработки и верификации сложности процессора. Но вот группа MIPS/Хеннесси в Стенфорде в 1978-1980 показала, что большинство сложных инструкций редко используются, а если конвейеризовать простые, то можно достигнуть более высоких бенчмарк при сравнимом по сложности процессоре. Вот это урок, который можно рассказать. А если оставить только первую часть истории "смотрите как круто с p++ = q++", то это будет вредный урок.
Ликбез о чем идет речь: софвер Синопсиса используют инженеры для проектирования микросхем. В комментариях мой слайд про процесс: код на языке SystemVerilog превращается в граф из логических элементов и элементов состояния (D-триггеров), потом программы размещения и трассировки раскладывают и соединяют этот граф по площадке микросхемы.
Сравните это с тем что происходит при разработке софтвера:
Место верилога и софтвера на чипе:
Я не "суров", а просто документировал опыт прошедшего года как он есть: студенты скидывали тестовое задание на ИИ, ИИ лажал вот таким, таким и таким образом. Вывод: студентов нужно учить так, чтобы они могли и без ИИ. Вы с этим не согласны?
Я могу похвастатся что она стала блоггершей после общения со мною, когда увидела мои блоги. "После" не означает "вследствие" но тем не менее :-) Раньше она ничего в линкине не писала. Вообще она интересная женщина, устраивала митинги в новогоднюю ночь, писала экспрессивные емейлы с обсуждением микроархитектурных проблем в 3 часа ночи итд.
Я не пытаюсь определить что возможно и что невозможно. Я лишь рапортую что было и утверждаю что студенты должны это уметь делать без ИИ, иначе не смогут даже понять когда ИИ лажает.