Проблема с перлом, что в нем есть неинтуитивные странности, вплоть до такого шухера что глобальные переменные $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 часа ночи итд.
Я не пытаюсь определить что возможно и что невозможно. Я лишь рапортую что было и утверждаю что студенты должны это уметь делать без ИИ, иначе не смогут даже понять когда ИИ лажает.
Шарада была моей прямой начальницей. Она мне в свое время задала этот же вопрос на интервью и дала на дом задание написать его на верилоге, что я сделал за три дня с тетбенчем.
Что он делал 4-6 лет в вузе? На что потратили $200K+ его родители, что студент базовые задачи по его основной специальности гуглит, как школьник-десятиклассник? Почему тренинга по ним не было в вузе?
Что вы имеете в виду? С моей точки зрения перловская передача параметров выглядит криво:
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 часа ночи итд.
Я не пытаюсь определить что возможно и что невозможно. Я лишь рапортую что было и утверждаю что студенты должны это уметь делать без ИИ, иначе не смогут даже понять когда ИИ лажает.
У меня на работе мы собеседуем у доски, кандидаты пишут маркером код и рисуют микроархитектурные диаграммы без доступа к электронным устройствам.
*** В 1946 году продюсер Даррил Занук был уверен, что у телевидения нет будущего. ***
А что, у телевидения есть будущее?
Это мероприятие оказало в 1997 году большое влияние на умы. Даже Synopsys стал переводить лучших инженеров с VHDL-продуктов на Verilog-продукты.
Шарада была моей прямой начальницей. Она мне в свое время задала этот же вопрос на интервью и дала на дом задание написать его на верилоге, что я сделал за три дня с тетбенчем.
Что он делал 4-6 лет в вузе? На что потратили $200K+ его родители, что студент базовые задачи по его основной специальности гуглит, как школьник-десятиклассник? Почему тренинга по ним не было в вузе?