> "это не я сел в лужу! Это другой аноним!" А еще анонимы могут подключаться к дискуссии если у них есть возражения. У лолок от этого развивается мания преследования, что вызывает много лулзов.
> вас, такого красивого, порол знатную чушь )
В тред врывается Д'Артаньян! Как шаблонно, фи.
> Открою вам страшную тайну (вернее, повторю свой прервый постинг) – байткод совсем
> необязателен. Зайдите в гугол и найдите всякие трансляторы питона в С++, Си и т.д.
И узнайте о том что они умеют сильно урезаный поддиалект? ;)
> Там зачастую никаким байткодом и близко не пользовались.
Обычно там делают ограничения и поддерживают только часть языка. Неудобно это - динамически типизированный язык в статически типизированный транслировать. Теоретически возможно, практически - надо реализовать проверки типов и прочее. Код густо разбавляется и чуда не происходит. Поэтому соревнуются с 1929 годом^W^W интерпретатором.
> А еще расскажите об отсутствие толка всяких промежуточных кодов
> гццшникам со шлагновщиками – а то они, болезные, не знают об этом.
> Ну да, куда им до анонимов опеннета! )
Зачем у них промежуточные коды - еще можно понять. Но это внутренние сущности. Они мало кого интересуют кроме авторов компилятра. Остальных интересует как работает программа. Тут то и будет облом. Хоть так эмить проверки типов, хоть эдак. Они будут. Это главное. В лучшем случае оптимизатор может попроовать что-то удалить, с понятным успехом. Лучший способ помочь оптимизатору - не подваливать ему лишней работы.
> поместить в один массив несколько различных типов данных,
У современных процессоров операции регистр-регистр быстрые, за 1 такт даже несколько операций может произойти. А обращение к массиву - шанс нарваться на доступ в RAM и отдохнуть. У быстрых процессоров это до сотен тактов. Есть кэш, но будет ли это cache hit... если ты все будешь в массивы пхать - не будет! Если программа и рабочий набор уместилась в кэш, скорость работы может подскочить в РАЗЫ. На современных процах по этой причине unroll loop'ов может себя и не оправдать. Экономия на jmp в конце цикла может убиться усилением cache miss из-за разжирения кода. Быстрый код должен быть маленьким и работать с компактными наборами данных, иначе он будет выносить кэш и станет медленным.
> что для этого нужно и какие у такого подхода могут быть минусы), но никаких
> бредовых идей типа
Идея напихать все в массивы, не адресуемые напрямую с такой же скоростью как регистры да еще и норовящие осесть в медленной RAM, агрессивно затирая кэш - гениально, чё.
> не требуется )
Ну это ты просто не видел как программа разгоняется разиков в 5 "на ровном месте", если ты в кэш смог уместиться. Вот и предлагаешь способы улучшения thrashing кэша.
> Очень точная формулировка! )
> Хотя, чего я ожидал от анонимов.
Не знаю как там анонимы, а лично ты показал что не понимаешь архитектуру процессоров. Процессорные ядра сильно обгоняют RAM у всего что сложнее микроконтроллера (и даже у некоторых мк). А ты предлагашь способы засорения кэша. Будет очень производительно, даже не сомневайся.
> У другого, генерированием машинных кодов для "динамических типов" должен заниматься ИИ,
Это был бы самый быстрый и эффективный способ. Я ж не ты, заведомо провальную канитель с массивами не посоветую.
{...спам...}
> элемента, а значит нужен ИИ, способный осознать! Иначе низя! О как!).
Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия.
> анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard.
Да хоть горшком называй проверки изменений типов, на результат не влияет.
> О как, оказывается это я упорно несу бред, понтуясь набором "вумных слов" )
Не только. Ты еще слился на полном непонимании стомости операций у современных CPU, что такое кэш и все такое.
> Проигнорировать часть предложения даже для вас слишком уж жирно. Тоньше нужно быть, тоньше.
Зачем быть тонким с кадром, который не понимает основ кэширования но машет интеловским маном? Ты более тонко не заметишь с таким то умищем.
> А если бы я захотел попонтоваться, то упомянул бы, что 4 томика
> "от интеля" у меня на книжной полке стоят. Так что мимо. )
Используешь как груз для засолки? Иначе не понятно как ты ухитрился пройти мимо процессорных кэшей, регистровых операций и быть настолько не в курсе стоимости процессорных операций, что предлагаешь заведомо провальные решения.
> Громче и чаще, авось кто поверит. Заодно и от лажи отвлечет =)
Ты так задорно зажигаешь что аудитория уже задолжала анонимам за билеты в цирк.
> Неа, читайте внимательнее! Я же не аноним, чтобы с умным видом нести чепуху.
Если ты так настаиваешь... ок, теперь ты не аноним ;).
> Умудриться приплести Тюринга к типам – и при этом проигнорировать ключевое
> слово "сторож"/guard – это сильно.
А подумать головой о том что "сторож" было включен в более общее понятие "проверки типов" - это для таких как ты слишком сложно? Понимаешь ли, когда операция регистр-регистр делается за такт, по сравнению с этим вообще любое лишнее трепыхание - дорогое. Как его ни обзови, даже если ты уложишься в еще 1 такт - таки падение скорости в 2 раза.
> А я ведь специально "подставился",
Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю что ты настолько талантливый актер.
> Понт окончился очередной грязевой ванной )
Так вылезай из лужи, чудак. И не грози южному централу, попивая сок у себя в квартале.
> Ну да, а еще наверняка есть "половинная беременность" – это когда с
> большими оговорками …
А мир вообще не черно белый, бывают всякие гибридные подходы. Jit один из них.
>> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию.
> А мусью в курсе, зачем компиляют в байткод и какие это дает возможности?
Да, однако в конечном итоге нас интересует качество машинного кода на энной платформе. Тяжелые оптимизации - ресурсоемкие, jit не может позволить себе стать полноценной билдфермой. С соответствующими последствиями для качества кода. Если хочется тяжелые оптимизации, AOT уместнее. Его реалтайм не жмет, потребление ресурсов менее критично т.к. еще не делится с работающей программой, а там где этого надо хорошо и много - может быть сделано другим компьютером, мощным и крутым, то что для смартфонного проца 10 минут, для мощного билдсервера - секунд 20. Но он и воздух греет в других объемах. Jit так не может.
> А о разных "уровнях" оптимизации?
> Хотя, откуда.
Да куда нам, анонимам, чай пить.
> У одного анонима это вообще "замена ключевых слов", у (конечно же)
> другого от оного "толка нет", просто "избавляет от неэффективного парсинга строк".
У дефолтного питона оно как-то так вроде и реализовано - питон интерпретирует этот байткод, медленно и печально.
> гцц или шланга компиляторы писать поучат! )
Эти то промежуточными кодами пользуются поумнее дефолтного питона. Но это вообще их внутренние сущности, остальных они мало интересуют.
> Еще один шедевр. YMMD! =)
> Оказывается динамичность виновата, о как!
Она такому состоянию дел дополнительно способствует. Добиться того чтобы конструкции языка транслировались в нечто простое, легкое и предсказуемое - не так то просто. И да, в сишечке я могу и посмотреть во что моя конструкция реально разложилась в виде машинного кода и я смогу довольно хорошо просчитать что будет и может быть. А что, сможешь так же круто заинструментировать jit? Ты кстати ничего не сказал про overcommit или latency, если уж мы про время.
> Значит glibc (и еще куча имплементаций cтандартной библиотеки) в общем и malloc/free
> в частности вполне подходит для использования в "реальном времени" ? Нормально.
В си можно работать и без libc, и без выделения памяти malloc'ом. Как тебе такой оборот? На си с полоборота пишут загрузчики и ядра, которые работают когда файловой системы, управления памятью и прочих malloc еще и в проекте нет. Зарубиться с таким инструментарием в вопросе предсказуемости операций - ну попробуй.
> Пишите еще! Жду с нетерпением дальнейших "посрамлений" )
Ну если ты так настаиваешь...
