почему 4х ядерный проц при компиляции загружен только на 25%?

на работе проект, довольтно большой. собирается в Visual Studio минут 40. удивительно, что комп 4-х ядерный, а загрузка CPU не превышает 25%. Ведь можно распределить вычисления - компилировать сразу несколько файлов (как я понимаю, именно так и происходит - одновременно запущено несколько процессов cl.exe), а загрузка CPU один фиг 25%. может быть это связано с тем, что, насколько мне известно, многоядерные процы не имеют полностью независимых ядер, например, система прерываний у них общая. даже если запустить 2 студии, в одной собирать, а в другой работать - всё равно не удаётся загрузить CPU более чем на 25 % и всё жутко тормозит. почему так происходит? какой толк от 4-x ядер?

 

дык ясно, компелится то в один поток. как вы содираетесь один поток, те один набор регистров, состояний итд шарить на 4 разных проца? поэтому счас все надо писать в многопоточной схеме. и переходить на среды/тулчайны поддерживающие простую реализацию многопоточности.

 

с чего бы это в один поток, если создано несколько процессов cl.exe?

 

cupuyc
1) не забывайте, что 4 независимым программам, выполняющимся абсолютно параллельно, надо получить доступ к 1 физическому жесткому диску. Система выстраивает их запросы на чтение-запись данных в один поток.
2) надо так же учесть архитектурные возможности и ограничения. x86 и Фоннеймановская архитектура не предполагает наличие более одного главного вычислителя, а умельцы из AMD и Intel'а что-то там прикрутили к ней.
3) надо еще учесть тот факт, что студия может синхронизировать свои различные процессы.
вывод) в 4х ядерных х86 и при решение этой задачи нет абсолютно никакого смысла.

 

maksim_

Плохой пример. Не общая.

Виндоус какой? Возможно дело в нем.
Если висит несколько CL, то будет тормозить. Так как в виндоусе вытесняющая многозадачность, то все 4 ядра присваиваются одной программе и уж она должна паралелить сборку.

Visual Studio какая версия?

 

6ая наверно

 

max7C4

Классическая фоннеймановская архитектура действительно базировалась на одном процессоре. Но это ограничение снято давным-давно, и вовсе не умельцами из АМД и Интела -- тогда (в конце 50-начале 60-х) этих контор ещё не существовало (во всяком случае, Интел; АМД постарше будет, но процессорами заниматься стала позже). Что же касается х86, то уже в 8086/8088 многопроцессорность была заложена, для чего, в частности, был предусмотрен сигнал шины LOCK и одноимённый префикс.

 

SII
но весь доступ к системным ресурсам осуществляется через 1 шину, которая делает из многих параллельно работающих вычислителей один, но чуть побыстрее (не вижу смысла при такой организации более чем в 2 ядрах, т.к. во многих, особенно не правильно укомплектованных системах, и одно ядро упирается в пропускную способность шины, а не в мощность процессора при обработке больших объемов данных)

 

max7C4
Кэш первого уравня разный. Не вдаваясь в подробности если разный ядра работают с разными данными, то вычисления не блокируются. У AMD и Intel реализовано по разному.
У NUMA архитектуры которую использует AMD несколько шин RAM в пропускную способность шины не так сильно упирается.

Да системы не сбалансированы и многие говорят что упирается в пропускную способность подсистемы памяти.
Но в нормальных условиях обычно упирается в вычислительные способности. Всегда можно сменить алгоритм который будет выполнять вычисления блоками которые будут умещаться в кэши.

Но вот в пропускную способность диска тоже может упираться, но для таких случаев есть RAID.

 

max7C4

Насчёт шины Вы, конечно, правы, но насчёт "упора" в её пропускную способность ошибаетесь. Конечно, есть задачи, которые именно в неё и упираются, но в большинстве случаев она не является реальной преградой. Сравните, например, по производительности двух- и четырёхъядерные процессоры Интел, у которых ядра работают на равной частоте и у которых одинаковая частота FSB (ну или частота шины памяти, если речь о процессорах Core i5/i7). Выяснится, что на многопоточных задачах четырёхъядерный процессор окажется существенно быстрее двухъядерного -- хотя, конечно, не в два раза. Ну а причин здесь две. Во-первых, не каждая инструкция требует одинакового времени для обработки. Например, простые инструкции типа пересылки или сложения могут выполняться по нескольку штук за такт каждым ядром (суперскалярная архитектура, впервые у Интел внедрённая на первых Пентиумах). Однако команда деления будет выполняться в общем случае несколько десятков тактов. Понятно, что, когда код насыщен подобными "тормознутыми" командами, процессорные ядра будут не столько обращаться к памяти за выборкой команд и данных, сколько "задумываться" над выполнением уже выбранных команд. Вторая же причина -- наличие кэша. Если код инструкции и необходимые данные находятся в кэше, то обращения к оперативной памяти не происходит, а значит, и пропускная способность шины роли не играет. Очевидно, что время от времени обращаться к реальной памяти всё же приходится, но в большинстве случаев всё необходимое лежит в кэше, и тогда ядра друг другу не мешают.

 

SII
а мне казалось загрузка кода ведется блоками в кэш 2 уровня, а вот с данными как раз таки проблема, ибо они могу адресоваться совершенно рандомно (ну относительно, хотя может и рандомно).

 

max7C4

при достаточном количестве памяти, обращаться к диску, а это в основном инклуды общие для всех, будет только для первого обращения к ним. а дальше будет брать из кэша в памяти.
кроме того, львиная доля загрузки приходится на оптимизацию, а она имеет дело не с очень большими объемами данных. правда по функциям скачет..

не знаю как у ТС, но пускаю на 2х ядернике 2 компеля, грузит, конечно не на 100, но оба ядра. и не только cl, но и простой 8с при параллельной компиляции раскидывается по ядрам.
чето у него не то. причем, не в cl. може мало памяти и оно все постоянно читает с диска? или, боже упаси, свопит? или ось не видит больше одного ядра? или сверхбыстрый проц + медленная память? даж не знаю, видеть надо

 

qqwe

это зависит от исходного текста

+1, но факт в том, что общая производительность процессора (судя по описанию симптомов ТС) не поднимается выше 25%, исходя из этого можно предположить, что их тормозит устройство к которому идет обращение сразу всех 4 процессов, а система их запросы строит в шеренгу (хз, может у него все 4 cl в сеть постоянно ломятся, а соединения насколько мне известно не пересекаются для разных процессов)

 

max7C4

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

если бы они в сеть ломились, то и 25 небыло бы. а если затык на памяти, то игрушки уж точно больше 25 бы не грузили. гамы любят память больше компилеров. вообще, 25 больше всего похоже на 1но, полностью загруженное ядро. но ТС молчит и я думаю, что либо он проблему решил, либо у него ось слетела, а это был пресмертный симптом, либо мы имеем случай троллинга

 

студия последняя, с последними обновлениями (постоянно идёт update). вина - хр sp2 32x. объём оперативки - 3гб. из железа слабая только видеокарта, всё остальное специально ставилось по максимуму, чтобы мы, разработчики, не ждали сто лет, пока откомпилируется проект. бывает, по несколько раз за день сорцы берёшь и после каждого раза нужно пересобрать. каждый раз на это уходит час времени - затрахало уже. пока проект собирается ничего толком делать не можешь - всё ужасно тормозит. блин, во промя сборки даже браузер тормозит, а CPU загружен на 25%.

 

А если так? http://msdn.microsoft.com/ru-ru/library/bb385193.aspx
Пишут, что и в 2005 работает.

 

cupuyc

ТС между тем maksim_..
maksim_ == cupuyc ?

кстати, лажовая видюха или глючная частая причина тормозов, а то, что бровзер тормозит на 4рех ядрах вообще тревожный симптом. может железо какое кривое. или недостаточно совместимое, или дров кривой, или... а тут даже фоты нет, чтоб по ней лечить..

и сп2 + 32 бита + 3гига слабовато для кпу сервера. (а сп2 вообще тянет 4 ядра на практике? както экспериментировал, в реестре предел 4 выставил и ось заглючила)

вообще, если у вас так все серьезно, то может лучше компилерную ферму из более дешевых, старых машин, но много? у вас же там много модулей в проге?

еще у меня было такое, что в проце с авторегулировкой частоты (забыл как зовется), она иногда в ненужные моменты ставилась на нижний порог почемуто. потом почемуто прошло. конфликт был какойто, видать. или дров кривой

 

max7C4

Ну, у современных процов уже три уровня кэша, но суть от этого не меняется: большая часть используемых данных и кода всё равно окажутся в кэше, и нужды в обращении к памяти не будет. Конечно, можно создать извращённый код, который будет плохо ложиться на кэш, но патологии в расчёт принимать особого смысла нет. Случайная адресация данных тоже особой роли не играет, кроме патологических случаев: трудно представить себе вменяемо написанную программу, которая по-настоящему хаотически обращалась бы за данными. Обычно работа идёт с несколькими достаточно крупными кусками, которые поместятся в несколько блоков кэша, а не с кучей находящихся друг от друга отдельных байтов/слов.

 

бред, у меня компилируеться в 4 потока по 100% загрузки

 

блин, как так?