Исправление den73, (текущая версия) :
Мне кажется, ни то, ни то не выйдет. Единственное, что в динамике есть свои преимущества для скорости, т.к. List<X>.Add существует в единственном экземпляре - дружественно к кешу, кода меньше. И так, пока не дойдёт до примитивов типа +, которые определены не для всех типов. Но в среднем по больнице вроде как статическая типизация заметно быстрее.
Верификация кода - вместо типов нужно будет тогда что-то другое. Вот SBCL умеет извлекать информацию из веток в if или etypecase, из констант и протягивать её дальше. Можно даже делать таким образом whole program optimization, но это уже не динамика.
Опять же, что понимать под типами. Я вот для эксперимента ввёл в SBCL тип immutable. И тогда у меня немутабельная хеш таблица стала типа «хеш-таблица и immutable». SBCL кое-что может продумать на эту тему и как-то использовать эту инфу. Но дальше там начинаются сложности. Например, FreezeObject(myHashTable) - этого SBCL не понимает, поскольку один и тот же объект является mutable до FreezeObject и immutable после. SBCL не понимает, что тип объекта может измениться во времени на противоположный (и это ошибка проектирования в его системе вывода типов, поскольку в лиспе cons string может превратиться в cons integer).
И плюс к тому, вывод типов сам по себе естественным образом легко приводит к экспоненциальной сложности. Чтобы этого избежать, в SBCL наставлена куча «тележек» (kludge). Выглядит это довольно жутко - что-нибудь тронешь и улетишь в экспоненциальное замедление времени компиляции, к примеру.
В итоге ты оказываешься в ситуации, когда у тебя потенциально всё круто, но на практике есть две угрозы: то, что оптимизатор не увидит закономерность в коде, поскольку его защищают от экспоненциальной сложности и дают по рукам (например, в SBCL есть магическое правило 4 итераций при оптимизации, установленное эмпирически), и то, что можно в неё всё-таки влететь, если защита где-то не сработает. То, что при этом происходит, весьма запутанно, хрупко и неуправляемо. Поэтому я считаю, что такой подход не жизненен.
Т.е. ИМХО ты хочешь странного и большего, чем может дать реальность.
Исходная версия den73, :
Мне кажется, ни то, ни то не выйдет. Единственное, что в динамике есть свои преимущества для скорости, т.к. List<X>.Add существует в единственном экземпляре - дружественно к кешу, кода меньше. И так, пока не дойдёт до примитивов типа +, которые определены не для всех типов. Но в среднем по больнице вроде как статическая типизация заметно быстрее.
Верификация кода - вместо типов нужно будет тогда что-то другое. Вот SBCL умеет извлекать информацию из веток в if или etypecase, из констант и протягивать её дальше. Можно даже делать таким образом whole program optimization.
Опять же, что понимать под типами. Я вот для эксперимента ввёл в SBCL тип immutable. И тогда у меня немутабельная хеш таблица стала типа «хеш-таблица и immutable». SBCL кое-что может продумать на эту тему и как-то использовать эту инфу. Но дальше там начинаются сложности. Например, FreezeObject(myHashTable) - этого SBCL не понимает, поскольку один и тот же объект является mutable до FreezeObject и immutable после. SBCL не понимает, что тип объекта может измениться во времени на противоположный (и это ошибка проектирования в его системе вывода типов, поскольку в лиспе cons string может превратиться в cons integer).
И плюс к тому, вывод типов сам по себе естественным образом легко приводит к экспоненциальной сложности. Чтобы этого избежать, в SBCL наставлена куча «тележек» (kludge). Выглядит это довольно жутко - что-нибудь тронешь и улетишь в экспоненциальное замедление времени компиляции, к примеру.
В итоге ты оказываешься в ситуации, когда у тебя потенциально всё круто, но на практике есть две угрозы: то, что оптимизатор не увидит закономерность в коде, поскольку его защищают от экспоненциальной сложности и дают по рукам (например, в SBCL есть магическое правило 4 итераций при оптимизации, установленное эмпирически), и то, что можно в неё всё-таки влететь, если защита где-то не сработает. То, что при этом происходит, весьма запутанно, хрупко и неуправляемо. Поэтому я считаю, что такой подход не жизненен.
Т.е. ИМХО ты хочешь странного и большего, чем может дать реальность.