Соглашусь с этим замечанием. Но это непринципально.
Рассмотрим замкнутый сосуд, в котором установилось равновесие пар-жидкость. И в один прекрасный момент введем непроницаемую перегородку по зеркалу жидкости. Что изменится?
А если сосуд будет открыт со стороны пара, то часть "быстрых" молекул будет улетать на бесконечность. Что автоматически снимет это условие.
Представим себе другой опыт.
Мы берем и швыряем камни в небо. Если у камня достаточная скорость, то он не возвращается. Можно себе вообразить, что где-то там, за облаками, сидит чувак, возможно с рогами и шторкой, и занимается селекцией наших камней по скорости. Быстрые - пропускает, медленные возвращает. Правда, иногда тоже швыряется быстрыми камнями, но гораздо реже, чем мы.
Пару слов о Демоне Максвелла. В принципе, таковым является любая граница раздела жидкость-пар. Потенциальный барьер с одной стороны которого быстрые молекулы, а с другой - медленные. Вероятнее всего любой барьер (ака область простанства-времени, где происходит разделение частиц/квантов по энергии) обладает свойством Демона Максвелла.
Видов сапогов всего два. Неудивительно, что вероятность вытащить левый или правый сапог колеблется около 0.5. С тем же успехом вместо сапог могли быть монетки.
Понимаете, в чем дело. Идея Форта — не стек. Основное в Форте — расширяемость. Вы создаете сами инструменты для расширения системы под решаемую задачу. Причем можете создавать их на любом уровне, от машинного кода до самого верхнего уровня, причем на всех одновременно. Это и мощь и слабость. Чтобы писать на Форте, надо вывернуть мышление наизнанку. Это пугает «традиционалистов».
А на вечный вопрос «зачем?» ответ — хочу! :)
Можно. Но… не нужно. Нет такого функционала, ради которого стоит заводить еще одно слово. Да еще с ничего не говорящим именем. {{ в конце слов, определенных через WM: в первую очередь украшательство. Можно вообще обойтись без них. Например сделать такой интерфейс: WM_LBUTTONDOWN do_smth ;WM
В предыдущей версии скобки были одинарные, но сразу выяснилось что их легко потерять или перепутать с круглыми.
Кроме того, код после DOES> в WM: существует в системе в единственном экземпляре, а не копируется в каждое слово, определенное через WM:. То-есть экономии никакой нет. Но я прям чувствую, что отдельно стоящие скобки так и будет тянуть или потерять, или прилепить.
Всем спасибо! Недоумение и потребность разобраться в задаче побудила меня к написанию сей заметки. Автор первой статьи сетовал на переполнения и сложность вычислений для сколько-нибудь больших n. Автор второй вообще пугает общественность Фурье-преобразованиями. (Вот хоть убейте, но чтобы перемножить десяток-два не более чем трехзначных десятичных чисел как-то совсем не хочется использовать Фурье туда-сюда.) Оказалось что задача-то довольно элементарна и не слишком трудоемка даже для относительно больших n. Что я и проиллюстрировал. Формализация требует отдельного времени для проверки некоторых идей. Созреет, может быть отпишусь.
Хмм… То-есть вот совсем неизвестно что за элементы в массиве? А как можно сравнивать элементы неизвестной природы? Каким образом задается их отношение больше-меньше-равно-несравнимо?
Если снять требование к памяти, можно использовать какой-нибудь вариант сортировки подсчетом. Время выполнения может быть равным двум проходам по массиву, а в некоторых случаях и меньше.
Итого: Интел — 1050, AMD — 450 в среднем. У Интела результат стабильный и процентов на 5 лучше чем у варианта xlatb 128 bit. У AMD результат очень сильно скачет. От 250 до 600.
Надеюсь вечером будет время, попробую.
У меня сильное подозрение что у АМД какие-то неправильные, нелинейные попугаи. По-хорошему, измерять надо бы реальное время, а с этим свои сложности.
Кстати, с разворачиванием циклов получается не все так однозначно. АМД явно как-то оптимизирует их выполнение
У меня сложилось впечатление, что мы друг друга недопонимаем.
Хочу уточнить, что Вы имеете ввиду под понятием lookup? Правильно ли я догадался.
Особенно один случай, как у моего товарища С-шный компилятор сгенерировал более эффективный код, чем он сам написал после всех оптимизаций и долгого изучения мануалов по ассемблеру: на одну инструкцию короче и примерно на 20% быстрее.
Насколько я понимаю, компилятор не улавливает нюансов пожелания программиста. Да и большинству просто не приходит в голову, что нужно изобретать велосипед для какого-то частного случая. «Ведь компилятор прекрасно сгенерирует более эффективный код.» А если мне нужно отдельное решение для вывода исключительно шестнадцатеричных чисел? Интересно, что даст компилятор.
А у вас в вариантах с циклами возможны промахи предсказания ветвлений, а в остальных — сложности конвейеризации. Так что всё тоже не так однозначно.
Эээ… Собственно я хотел показать как раз неэффективность первых решений на старых технологиях, против новых способов решения той же задачи на SSE. Даже, так сказать, показать развитие шахматной идеи от старых добрых восьмибитных версий до современных SIMD заморочек.
Таблица большая, но если операция делается один раз, то оптимизировать её не имеет смысла, значит, вы будете гонять её очень много раз, логично?
По табличному варианту немного подумал. Можно обрабатывать по байту (2 знака) за раз. Потребуется табличка размером 256 16-ти битных слов. Обрабатывать по два байта тоже можно, но табличка нужна будет уже 65536 четырехбайтных слов, что громоздко. Заполнять ее вручную я рехнусь, а писать код для этого — лень.
Навскидку, 512 байтная таблица даст выигрыш максимум раза в 3, по сравнению с xlatb. Табличный код, безусловно, компактен и быстр, параллельное исполнение на разных ядрах тоже возможно. А вот внутренний параллелизм, концепция SIMD в нем слаба, в отличие от SSE.
С переводом в десятичную систему с появлением сопроцессора стало все совсем просто. 18 знаков парой команд плюс код для распаковки упакованного двоично-десятичного числа.
Lookup-ы должны быть быстрее. Если не считать время на создание таблицы, особенно большой. И время на промахи кэша, что очень дорого. Да и тратить более 128К байт памяти на такую задачу, на мой взгляд, несколько расточительно.
Все варианты еще придумать нужно. :)
Соглашусь с этим замечанием. Но это непринципально.
Рассмотрим замкнутый сосуд, в котором установилось равновесие пар-жидкость. И в один прекрасный момент введем непроницаемую перегородку по зеркалу жидкости. Что изменится?
А если сосуд будет открыт со стороны пара, то часть "быстрых" молекул будет улетать на бесконечность. Что автоматически снимет это условие.
Представим себе другой опыт.
Мы берем и швыряем камни в небо. Если у камня достаточная скорость, то он не возвращается. Можно себе вообразить, что где-то там, за облаками, сидит чувак, возможно с рогами и шторкой, и занимается селекцией наших камней по скорости. Быстрые - пропускает, медленные возвращает. Правда, иногда тоже швыряется быстрыми камнями, но гораздо реже, чем мы.
Пару слов о Демоне Максвелла. В принципе, таковым является любая граница раздела жидкость-пар. Потенциальный барьер с одной стороны которого быстрые молекулы, а с другой - медленные. Вероятнее всего любой барьер (ака область простанства-времени, где происходит разделение частиц/квантов по энергии) обладает свойством Демона Максвелла.
Генератор Ван де Граафа, подключенный к вакуумному диоду. Вот вам и "механический" источник рентгена. Почти сто лет уже этому способу.
Видов сапогов всего два. Неудивительно, что вероятность вытащить левый или правый сапог колеблется около 0.5. С тем же успехом вместо сапог могли быть монетки.
И что самое интересное, в молекуле воды атомы водорода образуют именно такой угол.
Lesisak bubibibsdfgg
А на вечный вопрос «зачем?» ответ — хочу! :)
В предыдущей версии скобки были одинарные, но сразу выяснилось что их легко потерять или перепутать с круглыми.
Кроме того, код после DOES> в WM: существует в системе в единственном экземпляре, а не копируется в каждое слово, определенное через WM:. То-есть экономии никакой нет. Но я прям чувствую, что отдельно стоящие скобки так и будет тянуть или потерять, или прилепить.
Итого: Интел — 1050, AMD — 450 в среднем. У Интела результат стабильный и процентов на 5 лучше чем у варианта xlatb 128 bit. У AMD результат очень сильно скачет. От 250 до 600.
У меня сильное подозрение что у АМД какие-то неправильные, нелинейные попугаи. По-хорошему, измерять надо бы реальное время, а с этим свои сложности.
Кстати, с разворачиванием циклов получается не все так однозначно. АМД явно как-то оптимизирует их выполнение
Хочу уточнить, что Вы имеете ввиду под понятием lookup? Правильно ли я догадался.
Насколько я понимаю, компилятор не улавливает нюансов пожелания программиста. Да и большинству просто не приходит в голову, что нужно изобретать велосипед для какого-то частного случая. «Ведь компилятор прекрасно сгенерирует более эффективный код.» А если мне нужно отдельное решение для вывода исключительно шестнадцатеричных чисел? Интересно, что даст компилятор.
Эээ… Собственно я хотел показать как раз неэффективность первых решений на старых технологиях, против новых способов решения той же задачи на SSE. Даже, так сказать, показать развитие шахматной идеи от старых добрых восьмибитных версий до современных SIMD заморочек.
По табличному варианту немного подумал. Можно обрабатывать по байту (2 знака) за раз. Потребуется табличка размером 256 16-ти битных слов. Обрабатывать по два байта тоже можно, но табличка нужна будет уже 65536 четырехбайтных слов, что громоздко. Заполнять ее вручную я рехнусь, а писать код для этого — лень.
Навскидку, 512 байтная таблица даст выигрыш максимум раза в 3, по сравнению с xlatb. Табличный код, безусловно, компактен и быстр, параллельное исполнение на разных ядрах тоже возможно. А вот внутренний параллелизм, концепция SIMD в нем слаба, в отличие от SSE.
Все варианты еще придумать нужно. :)