Или снова об оптимизации скриптовых языков. В предыдущей заметке я это всё как-то сумбурно описал. Вкратце: для условного веб-сервиса минута инициализации много «дешевле», чем секунда обработки запроса. Поэтому, проведя собственно инициализацию, имеет смысл оптимизировать с ее учетом дальнейшую работу. И для скриптовых языков это вполне возможно, в отличие от компилируемых. А вот как это мне представляется в плане практики:
Вот эта презентация тебе может быть интересна https://speakerdeck.com/alex/why-ruby-isnt-slow .
ОтветитьУдалитьНасколько я понял, там накладываются дополнительные ограничения. Кроме того, у меня возникло ощущение, что с системой типов в Ruby автор несколько путается (там на самом деле числа, булевы и nil представляются не как объекты)...
УдалитьХотя, мб, я его просто недопонял. Презентация — не лучший формат для донесения сколь-либо сложных концепций.
Ну, и вдобавок, я скептически смотрю на всё, что исходит от Питона. Сугубо эстетическая несовместимость у меня с ним.
УдалитьНасколько я понимаю, специфичное представление чисел, строк и пр. — это оптимизация, а семантически они всё равно объекты. Т.е. интерпретатор загодя не знает, что у него будет — «объект вообще» или какой-то примитивный тип, и вынужден готовиться к худшему.
ОтветитьУдалитьЭто плохо с точки зрения производительности.
Презентация как раз о том, как можно эту неопределённость устранить по мере исполнения и делать меньше операций.
Ограничения, я так понял, в самом RPython-е, а не в коде, который им парсят (по крайней мере, когда большая Ruby будет реализована). Ну и никто не мешает подобный фреймворк наваять на Ruby, просто на Python-е он уже написан =)
А как, не внося ограничений, устранить неопределенность? В общем, у меня есть большие подозрения, что после реализации всех фич языка оптимальность куда-то незаметно растворится. Хотя ХЗ, может, там есть какая-то глубокая мысль, которую я пропустил...
Удалить