Pull to refresh
9
0

Пользователь

Send message
Я предполагал, что там какая-то ошибка в операторе печати, но надеялся, что кто-нибудь подскажет.
Дебаггером воспользоваться религия не позволяет? Интервалы циклов проверьте.
Но я же говорю, это моя первая программа на Си. Хотя программой, конечно, это сложно назвать ;-((
А откуда тогда жалобы на минусы к комментариям? Какие программы — такие и оценки.
Похоже, дело именно в вычислении синуса?
Не знаю в чем дело, у меня программа на C выполняется менее полутора секунд (Ryzen 3600). Возможно Вы и платформу не переключили на x64 — на x86 у меня чуть больше 5с.
Значения суммы одинаковые в обоих программах?
К тому же, в программе на C Вы используете стандартную функцию sin. Во-первых, эта функция принимает на вход число типа double, а данные в нее передаются в типе float — то есть, в программе на C часто выполняются преобразования float <-> double, которые довольно недешевые. Во-вторых, эта функция сама по себе может быть реализована как угодно, возможно тут лучше воспользоваться специализированной библиотекой.
И вообще, Ваш пример написан довольно сумбурно, например, сделать счетчики циклов double-переменными напрашивается само собой.
А Вы не надейтесь, проверьте выводы программ и убедитесь в том, что они все еще разные.
Ну Вы ведь сами на свой вопрос отвечаете.
1) Сравнение оптимизированной сборки на фортране с неоптимизированной на C. Вот Вы серьезно не в состоянии поискать в сети как включить оптимизацию в проекте в вижуалке? Или Вы думаете, что это сравнимо по сложности с изучением языка и является серьезным поводом для новичка забросить изучение C и учить фортран?
2) Запуск бенчмарков проводился одновременно с выполнением каких-то вычислений, которые съедали большую часть аппаратных ресурсов — разница от запуска к запуску 10%. О каких объективных результатах вообще может идти речь?
3) Вы изменили тест чуть менее чем полностью. Добавили бесполезное жонглирование синусами, под предлогом того, что C выкидывал вызов isPrime при оптимизации, хотя для этого достаточно просто дописать перед ним
bool volatile result = isPrime(i);

что, опять же, не является какой-то секретной информацией, достаточно использовать интернет-поисковик. Такие действия как-бы намекают, что изначальный результат сравнения Вам не понравился, и Вы решили чуть подправить реализации, что бы он был поприятнее.
4) Ваши программы неэквивалентны. Причем не то что бы Вы чего-то недоглядели — нет, Вы добавили в комментарий неодинаковых выводы программ, и это Вас абсолютно не смутило.
Суммируя, Вы сравниваете две неэквивалентные программы с разными настройками оптимизации, написанные по в процессе подправленном ТЗ, и запускаемые в среде с дефицитом вычислительных ресурсов. И после этого в «ироничном тоне» делаете выводы о производительности языков в целом, которые, оказывается, не просто Ваши субъективные догадки, а прямо таки «факты, которые кому-то не нравятся». Думаю, Ваш комментарий минусят потому, что он — тотальная профанация.
Ого, да фортран просто исключительный язык. Умудрился найти на одно простое число больше, чем C!!!
Просто без включения оптимизатора результаты не очень объективны, так как обычно он включен.
А теперь включите оптимизацию в C++ компиляторе :)
Вот мы и дожили до тех времен, когда для работы простого тетриса нужны 420 ксеонов…
Теперь стало понятно, сколько будет стоить разработка 32-ядерного процессора.
Стало понятно сколько денег выделили. Сколько оно стоит — мы до сих пор не знаем…
Ух, сколько красивых фраз. «Суровый реализм» героически борется с «закостенелыми стереотипами»… Подождите-ка, а откуда Вы знаете кто из них кто? Вы ведь эти понятия определили как Вам захотелось, не правда ли?
Вот Вы обвиняете людей — в незнании, хотя незнание им свойственно гораздо больше чем знание. Обвиняете статистику — в неполноте, хотя полную собрать в принципе невозможно. Поражаетесь когда люди рассуждают о том, о чем не имеют понятия, хотя это именно то, что они делают на протяжении всей своей истории. А потом просто говорите, что правильно так и никак иначе. Вот почему Вы правы, а другие нет? Потому что миленькая история из Вашего личного опыта?
Вы не поймите меня неправильно, я считаю, что женщины способны заниматься IT также как и мужчины. Но я так только считаю — я не могу сказать наверняка, так это или нет — как раз по той причине, что люди действительно не полностью разобрались в том, как устроен мозг. И Вы тоже не можете, но все равно почему-то уверены в своей правоте. Очень странно для 32 лет в IT — меня профессия научила сомневаться во всем за намного меньший срок.
P. S. Раз уж заговорили о стереотипах — весьма занятно что Вы в свои годы (10 лет военной выслуги + 32 года в IT = как минимум 60, верно?) располагаете девушкой-магистром. Поделитесь секретами соблазнения или признаетесь в том, что это троллинг? :)
Что очень актуально, пока вы работаете с 8-бит внешней шиной, менее актуально с 16 и совершенно неактуально с 32+.
Ну не знаю, мы точно не упремся в подгрузку кода с RAM на какой-нибудь простыне из арифметических инструкций на 0.1-0.2 такта каждая?
Нет, к кешам стэк не имеет никакого отношения.
Спутал с call/ret — в Intel'ах есть кеш точек возврата, который с ними взаимодействует.
То так, если что, все математические операции эмулируются сложением, инверсией и сдвигом. Запретить RISC'ам MUL и FPU?
Срочно запретить, если нет аппаратных умножителей чисел с плавающей точкой. Если есть — так же срочно разрешить.
Вы последовательно подгоняете идеологическую (не доказательную) базу под «если в RISC есть хоть какие-то оптимизации, то это CISC».
Тут смотря какие оптимизации. Если что-то вроде «ой а тут надо сделать набор инструкций уменьшенного размера» или «ну нарушим разок load/store принцип, и что с того» — то да, подгоняю.
Давайте по пунктам:
Фиксированная длина машинных инструкций (например, 32 бита) и простой формат команды.
Ну то есть с момента появления Thumb ARM RISC'ом не является.
Специализированные команды для операций с памятью — чтения или записи. Операции вида Read-Modify-Write отсутствуют.
В целом ARM соблюдает это правило, но он ведь еще и atomic операции поддерживает, так?
Большое количество регистров общего назначения (32 и более)
Тут да, хотя по этому правилу многие архитектуры подойдут.
По четвертому ничего сказать не могу, пятое не очень понял — оно предполагает, что, к примеру, TLB должна быть реализована полностью софтварно? Вот это правило уже кандидат на объявление устаревшим.

Вот так, в моем понимании, и получается, что ARM — не RISC. Что я упускаю?
А зачем вообще делать God Object?
Я могу сказать для чего делать переменную длину команд — для оптимизации размера кода программы. А проблему того, что со временем одни команды становятся менее используемыми, а другие наоборот — решать введением нескольких типов декодеров, между которыми можно переключаться.
И введение не то что FPU/SIMD, а даже стека и инструкции call/ret тоже делает CISC %)
Э нет. FPU/SIMD/стек — имеют поддержку на уровне исполнительных блоков (ну или дополнительных кешей в случае со стеком). И команды эти нужны для того, что бы задействовать эти самые аппаратные возможности. А вот введение команд типа SSE-шных dpps и crc32, которые просто транслируются в набор элементарных математических инструкций — это уже CISC-элементы.
Поэтому надо подогнать все под x86.
Почему подгонять под x86? Он-то очевидно CISC по самое не хочу.
И это различие — не догма, не божественное повеление, а условность, показавшаяся достаточно очевидной во время определения терминов.
А, ну я оперирую терминами как они есть, а Вы подстраиваете их под ARM. Ладно, пусть будет так.
Что проще: реализовать пару альтернативных простых таблиц трансляции, или несколько God Objects?
Тут расчет на то, что от того, что God Object'ов несколько, они будут не такие уж и God.
А вы можете точно сказать, где лежит граница между RISC-ядром с CISC-декодером и RISC-процессором с CISC-сабсетом, если кроме CISC-декодера у них все остальное — одинаковое?
В моем понимании терминологии RISC-процессор с CISC-дополнениями — это уже CISC. То есть был такой строгий и тривиальный RISC, добавили сложные команды, добавили поддержку укороченных команд — все, стал CISC. Но, возможно, это действительно неправильное понимание. Хотя подстраивать термины под хотелки ARM — тоже выглядит странно.
ARM (Advanced RISC Machine)
Можно называть утку медведем, но она все равно будет выглядеть как утка и крякать как утка.
они выжили и распространились
Только вот x86 распространился на персоналках и серверах, что повлекло за собой проблему обратной совместимости, а ARM — на single-program девайсах и мобилках с JVM. Но проблемы с легаси на x86 разумеется исключительно из-за CISC.
получил RISC-ядро (наверное, от идеальности CISC, да? нельзя быть слишком идеальным)
Уже тоже не разграничиваете RISC-ядро и RISC-процессор? Я нигде не говорил, что нужно исполнять CISC-команды в том виде в каком они есть.
Если вы продумываете march&ISA на два шага вперед — вы делаете RISC, если вы извлекаете профит сейчас — у вас получится CISC
А если CISC с разными декодерами и возможностью переключаться от одного к другому?
а вот это уже лежит на тонкой грани между wishful thinking и подменой…
А натягивание ARM-совы на RISC-глобус — это другое.
Это истории x86 и ARM (они кстати обе CISC, просто напоминаю).

Опять же, Вы привязываетесь к конкретным архитектурам, а я оцениваю CISC и RISC концептуально. Это не CISC, а x86 тащит легаси из неоптимально спроектированных команд, CISC сам по себе к этому не обязывает. И это в x86 нет упрощенных наборов команд с разными декодерами — в самой концепции CISC я не вижу на это никаких ограничений.

В общем, у Вас аргументация вида «когда-то придумали передавать данные по сети в виде цифрового сигнала, потом появился веб, и вот, спустя 30 лет, он как-то не очень подходит для современных задач — значит надо было передавать сигнал в аналоговом виде».
1. С умным видом унизить всех, кто рассуждает на заданную тему, ссылаясь на трудность познания бытия.
2. Без каких-либо рассуждений сделать ниоткуда не следующий и ничем не подкрепленный вывод на эту же тему.
Я так понимаю, Вы какой-то особенный, чьим суждениям наивность не свойственна?
Ну да, ну да, давайте спроектируем CISC в точности как x86-64, что бы унаследовать все его косяки. Ни в коем случае не утрамбовываем в один-два байта полезные инструкции, лучше запихнем туда операции над 8-16 битными операндами — вот будет счастье. Я понимаю, что в x86 чего только нет, но уж сферический процессор в вакууме можно же спроектировать хотя бы по современным меркам.
Вообще по этому поводу у меня была мысль ввести механизм эпох. По сути — что бы в специальном регистре можно было задавать разные режимы декодирования команд, и программы могли использовать такую упаковку, которая им по душе. Правда, не уверен, что зависимость декодирования от данных в регистрах может быть реализована без больших накладных расходов. Да и вообще, даже на x86 упереться во фронтенд могут не только лишь все, так что скорее всего оно того просто не стоит.
Не очень понял, о чем Вы. Что значит сокращенные подмножества? И почему выкинуть что-либо из CISC проблемнее чем из RISC?
Если использовать лишь тривиальные команды, очевидно количество команд, нужных для кодирование алгоритма, будет больше, чем при использовании нетривиальных. При этом мы также будем вынуждены кодировать все команды одинаковым количеством байт, вместо того, что бы использовать меньше байт на популярные команды и больше на экзотические. Поэтому я считаю, что условно идеально спроектированный CISC выиграет у условно идеально спроектированного RISC'а в размере программы.

Information

Rating
Does not participate
Registered
Activity