Здравствуйте, BulatZiganshin, Вы писали:
M>>>>А mutable локальные переменные как апдейтить? C>>>А какие проблемы с mutable-переменными, если есть настоящие замыкания?
M>>Эффективность кода.
BZ>это проблема компилятора, который должен уметь их инлайнить
А вот и не угадал.
Если нам компилятор/язык гарантирует, что данный метод будет заинлайнен — то это те-же макросы, вид сбоку.
Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!
Здравствуйте, mkizub, Вы писали:
M>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!
Ну да, зачем нам JIT, если есть более мощные макросы?
Re[44]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, BulatZiganshin, Вы писали:
M>>Впрочем, речь не о том, что их нельзя поменять из замыкания, а о том — как ты это собираешься делать? Физически — как? Указатель на них сохранить в замыкании? И потом работать с локальной переменной по ссылке, а не в регистре/стеке?
BZ>это в терминах C мыслишь в GC-ed языках всё создаётся в куче — и локальные переменные, и замыкания, которые на них ссылаются. остальное — оптимизации, выполняемые по мере сил и способностей компилятора
А к куче не через ссылки доступаются, да? Оптимизатор ничего не сможет наоптимизировать, он ссылки в хип на операции со стеком не заменит.
Здравствуйте, Курилка, Вы писали:
M>>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!
К>Ну да, зачем нам JIT, если есть более мощные макросы?
Наверное, ты что-то умное хотел сказать. Про то, что компиляторы (а не только JIT) умеют инлайнить инлайн методы я в курсе. Что-то ещё хочешь добавить?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>типы в ООП динамические.
M>Да не в ООП!!! В принципе полиморфизма это. Может ты не видишь разницы, но больше мне добавить нечего.
я как раз вижу templates — это по твоему не полиморфизм?
Люди, я люблю вас! Будьте бдительны!!!
Re[32]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, BulatZiganshin, Вы писали:
M>>>>>А mutable локальные переменные как апдейтить? C>>>>А какие проблемы с mutable-переменными, если есть настоящие замыкания?
M>>>Эффективность кода.
BZ>>это проблема компилятора, который должен уметь их инлайнить
M>А вот и не угадал. M>Если нам компилятор/язык гарантирует, что данный метод будет заинлайнен — то это те-же макросы, вид сбоку. M>Спрашивается, нафига козе баян? Если в N уже есть макросы, более мощные чем инлайн-функции — нафига делать через инлайн, а не макросы?!
а зачем в С константы, если это по сути дела те же макросы — ты не догадываешься?
реимущесчтва в том, что это интегрированная часть языка, которую можно понять, не держа в голове дополнительный уровень трансляции. в том, что при отладке можно спокойно заходить внутрь клозур, в том что они могут реализовываться либо инлайнингом, либо ссылками в зависимости от настроек компилятора и своих размеров
Люди, я люблю вас! Будьте бдительны!!!
Re[46]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я как раз вижу templates — это по твоему не полиморфизм?
Из википедии (так себе источник, но для справки можно попользовать):
Полиморфизм (в языках программирования) — взаимозаменяемость объектов с одинаковым интерфейсом.
Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования.
Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а зачем в С константы, если это по сути дела те же макросы — ты не догадываешься?
Ты опять не угадал. Мы же не о С-щных макросах говорим. В С++ const и inline ввели как type safe замену С-шных макросов.
А мы говорим об "умных" макросах. Которые сами по себе type safe.
BZ>реимущесчтва в том, что это интегрированная часть языка, которую можно понять, не держа в голове дополнительный уровень трансляции. в том, что при отладке можно спокойно заходить внутрь клозур, в том что они могут реализовываться либо инлайнингом, либо ссылками в зависимости от настроек компилятора и своих размеров
Я же не против closures или inline. Иначе бы я не делал closures в своём компиляторе.
Речь зашла о том, что foreach в N можно сделать в виде closures, и инлайнинге метода foreach.
Можно, но есть такая вещь как сложность. Это фундаментальная проблема программирования, вокруг попыток упростить разработку программ вообще всё программирование вертится. Это в нём главное, иначе мы бы до сих пор в машинных кодах программировали бы.
Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
), а ты говоришь об инлайнинге. Конечно, если N будет жить — то доделают и инлайнинг, и всё остальное. Но это ещё не скоро. А пока они взяли то, что у них сделано хорошо (макросы) и на них сделали foreach. И правильно сделали. А вот когда (и если) доделают инлайнинг — тогда кто-нибудь ради прикола напишет метод inline foreach(...) и будет приколисту щастье.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>а зачем в С константы, если это по сути дела те же макросы — ты не догадываешься?
M>Ты опять не угадал. Мы же не о С-щных макросах говорим. В С++ const и inline ввели как type safe замену С-шных макросов. M>А мы говорим об "умных" макросах. Которые сами по себе type safe.
ну ты ведь понял, что не всё, что можно реализовывать макросами — нужно обязательно реализовывать макросами? в случае с константами проблема была в type safety, поддержке отладки
BZ>>реимущесчтва в том, что это интегрированная часть языка, которую можно понять, не держа в голове дополнительный уровень трансляции. в том, что при отладке можно спокойно заходить внутрь клозур, в том что они могут реализовываться либо инлайнингом, либо ссылками в зависимости от настроек компилятора и своих размеров
M>Я же не против closures или inline. Иначе бы я не делал closures в своём компиляторе. M>Речь зашла о том, что foreach в N можно сделать в виде closures, и инлайнинге метода foreach. M>Можно, но есть такая вещь как сложность. Это фундаментальная проблема программирования, вокруг попыток упростить разработку программ вообще всё программирование вертится. Это в нём главное, иначе мы бы до сих пор в машинных кодах программировали бы. M>Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
), а ты говоришь об инлайнинге. Конечно, если N будет жить — то доделают и инлайнинг, и всё остальное. Но это ещё не скоро. А пока они взяли то, что у них сделано хорошо (макросы) и на них сделали foreach. И правильно сделали. А вот когда (и если) доделают инлайнинг — тогда кто-нибудь ради прикола напишет метод inline foreach(...) и будет приколисту щастье.
да, макросы имеют превосходное соотношение цена/результат, пока не требуется большая надёжность
Люди, я люблю вас! Будьте бдительны!!!
Re[47]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>я как раз вижу templates — это по твоему не полиморфизм?
M>Из википедии (так себе источник, но для справки можно попользовать):
M>
M>Полиморфизм (в языках программирования) — взаимозаменяемость объектов с одинаковым интерфейсом.
M>Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования.
M>Никакий "различной реализации" для шаблонов я не вижу. Параметризация (что и служит для инстантиирования типа из шаблона) за полиморфизм, IMHO, не канает.
это потому, что и ты, и авторы этой фразы знаете о полиморфизме только из книжек по ООП отгадай, как называется первая статья о type classes?
Люди, я люблю вас! Будьте бдительны!!!
Re[34]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>А к куче не через ссылки доступаются, да? Оптимизатор ничего не сможет наоптимизировать, он ссылки в хип на операции со стеком не заменит.
Еще как заменит... некоторые реализации жабы давно заменяют... и то что они делают далеко не придел.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Так вот. Силы разработчиков компилятора N ушли на макросы. У них пока руки не дошли обычный if оптимизировать (нормально скомпилировать, а не как http://rsdn.ru/forum/message/2618909.1.aspx
), а ты говоришь об инлайнинге.
Убирать такие ляпы фротенда дело виртуальной машины (и JIT .NET'а кстати убирает). Фронтенду и так есть чем заняться.
Болие того если этим будет заниматся фронтенд то эти оптимизации придется делать во всех фронендах. А если этим займется ВМ то эти оптимизации нужно сделать один раз.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
G>>Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.
M>JFYI, я для Samsung-а переписал main loop явовского интерпретатора (KVM) на ассемблере (MIPS). Ускорение вышло в 2 раза. В основном за счёт правильного джамп-а при диспатчинге опкода (все хэндлеры имели по 16 или 32 комманды, не помню),
Шитый код в отличии от байткода — это уже адрес, по которому надо делать переход (для прямого шитого кода) причем адрес строго фиксированного размера. Например, 32 бита, без вариантов. Его диспатчить правильно не надо — есть ровно один способ.
M>расположения верхушки стека в регистре и т.п.
В случае форта это делать можно и нужно, и можно сделать такое на чистом С — достаточно верхушку таскать параметром как часть контекста, и удостовериться, что компилятор использует fastcall с регистровой передачей параметров.
M>Потом подрихтовал на ассемблере вызов методов, оптимизировал байткод при загрузке класса, оптимизнул несколько библиотечных методов и синхронизацию — и вышло ещё ускорение в 1.8 раз.
Этого всего в случае форт-машины делать просто не нужно, за отсутствием методов и классов, и исключительно простой процедуре вызова.
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
M>>>Явовский код — это такой же стек, как и фортовский, плюс проверки на нулевой указатель, выход за границы массивов, проверки типов и прочее. Явовскому интерпретатору просто не от чего быть медленее, кроме проверок — а без них левый код на мобилку не загрузишь.
G>>Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.
M>О каком дополнительном уровне косвенности ты говоришь?
Я о том, что в фортовом шитом коде мне не надо дешифровать код операции — все коды фиксированной длины и представляют из себя адреса, по которым надо делать переход (для прямого кода JMP [PC++]) или слазить по адресу (для косвенного шитого кода JMP [PC++]]). В случае сишной переносимой встраиваемой реализации у меня байткод — это массив указателей на функции (которым верхушку стека я передам отдельным параметром, и она будет лежать в регистре). И все. По производительности такая переносимая реализация порвет тупенький KVM даже без "вставок на Клиппере для скорости".
M>>>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.
G>>Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.
M>Ща. Я больше трёх лет работал в Esmertec. Их продукт (Jbed) — это AOP компилятор явы. А библиотечные функции компилятся в нэйтивный код на хосте, и раборают (сюрприз!) быстрее С-шных (за счёт интеграции с GC и избегания алиасинга, в C надо лепить volatile указателям, а в явовском коде не надо, плюс unsafe хаки в компиляторе для библиотечного кода).
Компилятор тут не причем. Речь о ява машинах для телефонов. Конкретнее, о том что CLDC-шный KVM популярный в мобилах не делает джит, и никакой компилятор не поможет тебе не то что обогнать, но даже близко к С подойти.
M>Jazelle — мёртворождённая технология. В ней переключение между режимом java и arm/thumb слишком медленное. Следующая версия ARM-а уже будет иметь инструкции для аппаратной проверки нулевых указателей, границ массива и ещё нескольких шибко удобных вещей — код (нэйтивный) в который компилятется ява имеет размер меньше байткода, а скорость работы сам понимаешь — полная. Тут Jazelle вообще пипец настанет.
Возможно.
Re[38]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, BulatZiganshin, Вы писали:
G>>>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически).
BZ>это вопрос реализации. были интерпретаторы даже для С, с другой стороны есть lint-подобные системы для динамичсеких языков. правильное же определение — в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения.
Не совсем так. Не текстом программы. Я и в динамическом языке могу во многих случаях тип вывести из контекста употребления. Разница в том, как семантика языка трактует ошибку типа — может ли она у меня во время выполнения выскочить, или это невозможно в принципе. Вот в вашем бейсике например семантика не обязываем меня употреблять % для целых чисел, и эту переменную я могу подставить в конструктор массива DIM. Что будет, если параметром DIM окажется число с плавающей запятой? Обязан ли компилятор выводить тип этой переменной и давать мне по рукам? Нет, не обязан — это должно упасть в рантайме. Потому, семантика динамическая. Просто система типов языка настолька убога, что пользы от этой динамической семантики нет никакой.
BZ>кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки
Ну разумеется, нет. Это один из способов привнести в статические языки полиморфизм. Типизация остается статической — все ошибки типов гарантированно ловятся компилятором статически. Это если ты не пользуешься dynamic_cast и аналогами (даункасты в яве, QueryInterface в COM) — вот они как раз и есть "динамическая типизация" — могут и обломаться в рантайме запросто.
Re[53]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Спокойнее. Ты уже мог заметить, что решение ограниченное временем компиляции я считаю ущербным "по умолчанию". Так что мимо такой фразы я просто не смог пройти мимо
Так бы сразу и сказал, что макросы суксь.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Являются ли макросы свидетельством недостаточной выр
BZ>>кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки G>Ну разумеется, нет. Это один из способов привнести в статические языки полиморфизм.
в GC-ed языках всё создаётся в куче — и локальные переменные, и замыкания, которые на них ссылаются. остальное — оптимизации, выполняемые по мере сил и способностей компилятора
Про то, что компиляторы (а не только JIT) умеют инлайнить инлайн методы я в курсе. Что-то ещё хочешь добавить?
templates — это по твоему не полиморфизм? 
отгадай, как называется первая статья о type classes? 
Если нам не помогут, то мы тоже никого не пощадим.
