Честно говоря, впервые слышу.
Но причём здесь очередной HDL? Он может быть более высокоуровневый, упрощать жизнь разработчику и пр., но это не отменяет того, что я написал выше.
в FPGA максимальная возможная рабочая частота зависит от архитектуры. Иногда требуемая архитектура может просто не развестись. Это такая же пакость как сама рекурсия, которая упирается в глубину стека, которая конечна и непредсказуема.
В итоге если пытаться реализовывать функциональное программирование в FPGA, то кажущееся ускорение от одновременного вычисления результатов функций будет нивелироваться общим понижением тактовой частоты.
FPGA хороши для комбинаторной логики и небольших FSM (шифраторы/дешифраторы/кодировщики/конвертеры, в общем та область, где FPGA и ASIC и используются). Если логика по сути подразумевает развесистый конечный автомат (читай императивный алгоритм со сменой состояний), то не имеет никакого значения в прокрустово ложе каких пуристских абстракций вы будете пытаться это уместить — в итоге это отъест так много скорости (засчёт конвейеризации) и ресурсов (на хранение состояния, а точнее на реализацию разных возможных ветвей исполнения), что быстрее это работать не будет, если вообще будет реализуемо.
В итоге сначала начали реализовывать программно обычные процессорные ядра прямо в FPGA, а сейчас вовсю тренд на гибриды на одном кристалле ARM и FPGA.
По сути HDL, на которых ведётся разработка для ПЛИС — это как C с точки зрения Ada, но не как LISP или Haskell. На самом деле тут приходится думать о низком уровне и заниматься оптимизацией больше, чем при программировании на Си для компьютера.
Вы же прекрасно поняли о чём я. Даже когда я сам пишу программы (не для FPGA), я делаю отладку на той же машине, на которой пишу код и собираю его. Только это Pentium 3. Поэтому я знаю, что если оно не тормозит у меня, то не будет тормозить ни у кого, даже на тех тонких клиентах с Atom Nxxx, для которых мне частенько приходится делать программы с GUI, и на которых поделки на Qt QML, которые делал мой бывший коллега, выдают FPS около 1 кадра в секунду (нет аппаратного ускорения графики).
Это нельзя сравнивать. Во-первых в моём распоряжении вся FPGA целиком. Во-вторых, я делаю отладку на реальном железе. В-третьих то, что я делаю, как правило, либо работает, либо нет, потому что при разработке для FPGA ты рассчитываешь алгоритм с точностью до каждого такта (если только не используешь софтпроцессор и пишешь для него на Си) — там нельзя говорить о производительности в компьютерном смысле.
В компьютерах производительность — эффективное использование процессорного времени и памяти. В FPGA производительность — эффективное использование чётко предопределённого количества логических ячеек.
А на практике это всё заточено под один браузерный движок, который, кажется, подошёл к сингулярности — где лучшие программисты мира, работающие в богатейшей компании, не успевают закрывать дыры и баги. Он переусложнён и из него выжимают последние соки.
Меня это очень беспокоит. Даже на хабре, когда я говорю, что разрабатывать десктопное ПО на JS — не комильфо, что у HTML+CSS+JS вообще куча недостатков, а для разработки под десктоп — ещё больше, что нужно разрабатывать GUI-библиотеки нового поколения для разных языков (или одну с биндингами), меня минусуют и поднимают на смех и упорно впихивают Node.JS
Может быть, моя гипотеза ложная. Только объясни тогда, отчего народ свихнулся? Обычный редактор с подсветкой синтаксиса сейчас нормально делать на Electron (их уже два — Atom и VS Code). Там даже кастомных GUI контролов нет, на кой чёрт там HTML+CSS+JS? Это можно было даже на Tk сделать! Только тему красивую нарисовать и всё.
И ведь тормозит нещадно.
А потом программист «случайно» не замечает, что его творение не виснет только на Core i7 Extreme.
Я бы вообще запретил вести разработку на чём-либо мощнее самой распространённой конфигурации железа на данный момент минус 5 лет. Потому что продуктивность работы пользователя программы ещё более важна, чем продуктивность программиста.
Возможно, тогда современный веб был бы действительно удобным, а не специальной олимпиадой «кто быстрее сожрёт батарею ноута говённым джаваскриптом с 3 фреймворками и HD видео на фоне»
Возможно, тогда бы С++ неприлично долго компилирующиеся и неадекватно переусложнённые языки начали бы терять свою популярность.
Возможно, тогда мы бы не возвращались стремительно во времена DOS, когда люди работали одновременно только с одной программой (тогда — потому что не было многозадачности, сейчас — потому что тормозит — некоторые программисты же верят в закон Мура и в то, что у пользователей денег куры не клюют на покупку мощного железа)
У меня процессор A8-6600K и джетбрейновские IDE (конкретно PyCharm) виснут так сильно, что я просто не могу ими пользоваться — эти тормоза перекрывают все удобства. По сравнению с этим лагодромом даже IDLE удобнее.
Я вот недавно купил вторую книгу по Go. Один из авторов — Брайан Керниган.
И в этой книге есть схема языков, которые повлияли на Go:
ALGOL60->C-Go,
ALGOL60->Pascal->Newsqueak->Alef->Go,
Pascal->Modula-2->Oberon-Oberon-2->Go
Так что идеи Вирта живут и здравствуют. Вместе с идеями Кернигана.
Но причём здесь очередной HDL? Он может быть более высокоуровневый, упрощать жизнь разработчику и пр., но это не отменяет того, что я написал выше.
в FPGA максимальная возможная рабочая частота зависит от архитектуры. Иногда требуемая архитектура может просто не развестись. Это такая же пакость как сама рекурсия, которая упирается в глубину стека, которая конечна и непредсказуема.
В итоге если пытаться реализовывать функциональное программирование в FPGA, то кажущееся ускорение от одновременного вычисления результатов функций будет нивелироваться общим понижением тактовой частоты.
FPGA хороши для комбинаторной логики и небольших FSM (шифраторы/дешифраторы/кодировщики/конвертеры, в общем та область, где FPGA и ASIC и используются). Если логика по сути подразумевает развесистый конечный автомат (читай императивный алгоритм со сменой состояний), то не имеет никакого значения в прокрустово ложе каких пуристских абстракций вы будете пытаться это уместить — в итоге это отъест так много скорости (засчёт конвейеризации) и ресурсов (на хранение состояния, а точнее на реализацию разных возможных ветвей исполнения), что быстрее это работать не будет, если вообще будет реализуемо.
В итоге сначала начали реализовывать программно обычные процессорные ядра прямо в FPGA, а сейчас вовсю тренд на гибриды на одном кристалле ARM и FPGA.
По сути HDL, на которых ведётся разработка для ПЛИС — это как C с точки зрения Ada, но не как LISP или Haskell. На самом деле тут приходится думать о низком уровне и заниматься оптимизацией больше, чем при программировании на Си для компьютера.
Вы убедились, что частота процессора не менялась на протяжении всех тестов?
В компьютерах производительность — эффективное использование процессорного времени и памяти. В FPGA производительность — эффективное использование чётко предопределённого количества логических ячеек.
И ведь тормозит нещадно.
Я бы вообще запретил вести разработку на чём-либо мощнее самой распространённой конфигурации железа на данный момент минус 5 лет. Потому что продуктивность работы пользователя программы ещё более важна, чем продуктивность программиста.
Возможно, тогда современный веб был бы действительно удобным, а не специальной олимпиадой «кто быстрее сожрёт батарею ноута говённым джаваскриптом с 3 фреймворками и HD видео на фоне»
Возможно, тогда бы
С++неприлично долго компилирующиеся и неадекватно переусложнённые языки начали бы терять свою популярность.Возможно, тогда мы бы не возвращались стремительно во времена DOS, когда люди работали одновременно только с одной программой (тогда — потому что не было многозадачности, сейчас — потому что тормозит — некоторые программисты же верят в закон Мура и в то, что у пользователей денег куры не клюют на покупку мощного железа)
И в этой книге есть схема языков, которые повлияли на Go:
ALGOL60->C-Go,
ALGOL60->Pascal->Newsqueak->Alef->Go,
Pascal->Modula-2->Oberon-Oberon-2->Go
Так что идеи Вирта живут и здравствуют. Вместе с идеями Кернигана.
И у человеческого зрения тоже есть выдержка.
после такого только аккаунт удалять.