пару вопросов о покупки ddr

вот именно благодаря разветвленности и запутанности он и не грузит все исполнительные блоки.

это как?

и чо? если работа идет в основном с памятью, а не с регистрами - проц бОльшую часть времени будет гулять пока данные из кеша подтянутся.

откуда у тебя такие данные? Я как-то смотрел лет 10..15 назад, уже тогда, на первопне, всё было не так, как в твоих диванных фантазиях.

Мы вроде как о вполне конкретном алгоритме говорили, а не о высосанной из пальца синтетике, не?

это не синтетика, а вполне конкретный код, который вполне конкретный компилятор gcc, уже лет 10 как раскидывает на два потока, которые выполняются сразу, в U и V трубах процессора iPentium. Да, в двух ALU. Даже такой простой код как этот.

Примитивнейший тест на скорость поиска по каталогам однако. Если у вас ФС не требует дефрагментации - почему же вычисление размера файлов в /usr до и после «ненужной» дефрагментации будет отличаться в разы?

ВНЕЗАПНО: потому-что моя ФС не оптимизированна для ненужных мне операций.

И чо? Что, кроме браузера с иксами, там стоит?

много чего. Компиляторы, интерпретаторы, прочие средства разработки. Как и любой сишник, я знаю 50 других ЯП, что-бы их обсирать. Очевидно, обсирать без пруфов не получится (:

Ну там ещё плееры для видео и аудио. Ну и ещё transmission&aMule. Ещё чего-то по мелочи. Думаю, не меньше, чем у тебя.

Болезный, проведите тест seek на 5% поляны и на 100% поляны - с удивлением для себя обнаружите, что разница - отнюдь не 20-кратная.

а какая? Просто под рукой нет сейчас HDD.

вы пишете о своих опытах, и при этом сами не знаете о каком именно процессоре вы говорите? Или вы - о диванных опытах?

я там ещё ссылку вам кинул. И подпись под постом по ссылке — ваша. И цитаты из того поста. Я думал — процессор, который описан человеком с ником похожим на ваш — тоже ваш.

это как?

Для вас будет открытием, но максимальная нагрузка идет как раз- от неразветвленных вычислений. Да-да, именно тогда грузятся все ALU. Переходы - не всегда успешно предсказываются, выборки из памяти (кеша) - тормозят выполнение кода пока они не окончатся... Внезапно?

откуда у тебя такие данные? Я как-то смотрел лет 10..15 назад, уже тогда, на первопне, всё было не так, как в твоих диванных фантазиях.

Чо, на первопне данные из кеша или памяти попадали в числодробилки быстрее, чем из регистров? :) О латентности кеша/памяти - не, не слыхали?

это не синтетика, а вполне конкретный код, который вполне конкретный компилятор gcc, уже лет 10 как раскидывает на два потока, которые выполняются сразу, в U и V трубах процессора iPentium. Да, в двух ALU. Даже такой простой код как этот.

Это - высосанный из пальца пример, не встречающийся в реальной жизни. Т.е. - синтетика.

И да, именно этот код будет выполняться последовательно. Потому как связанные операции параллелиться не могут. Вы же, в конце концов, не можете прочитать книгу, которую автор еще не написал? Почему же вы тогда считаете, что процесор может оперировать с еще не высчитанным значением?

ВНЕЗАПНО: потому-что моя ФС не оптимизированна для ненужных мне операций.

Обращение к файлам из разных каталогов (которое требует чтения тех самых каталогов) - ненужные операции? Феноменально :)

а какая? Просто под рукой нет сейчас HDD.

Максимум 2-3-кратная. И в десятки раз больше позиционирования на секторв пределах трека/на соседнем треке.

я там ещё ссылку вам кинул.

Т.е. вы удаленно, с дивана, телепатически измерили потребление и нагрев моего процессора, даже не зная при этом его модели? Годно, чо.

Да, я вас уже ткнул носом в тесты реального энергопотребления интелов и амд...

И да, именно этот код будет выполняться последовательно.

надоело. У вас gcc сломался? Или там, откуда вы пишете (на диване), gcc отродясь не было?

Тогда вопросов больше нет.

У вас gcc сломался?

Это у вас, похоже, сломался. Потому как оно разложится в 3 команды ALU - dec, sub и еще один dec (mov - выполняет AGU), причем - sub ну никак не сможет выполниться до первого dec. Ибо его результат напрямую зависит от результата вычисления первого dec. Ну это, ессно, если gcc не свернет его все в кукиш, подчистив какахи программиста и оставив присвивание вместо бессмысленного огорода операторов.

Так что учите матчасть, и думайте, что же на самом деле будет делать ваш индусский код.