Здравствуйте, VladD2,
GN>>А когда начнут интегрировать RAM в корпус CPU (что бы избавиться от проблем с печатными платами), то как будем добавлять память?
VD>А надо? Для каждого периода времени есть некие негласные принятые объемы памяти. Ввести три градации: VD>1. Лоэнд — сейчас где-то 128 метров. VD>2. Лоэнд+ — 256 на сегодня. VD>3. Мидлэнд — 512. VD>4. Хайэнд — 1 Гиг. VD>5. Мечта идиота 4 Гб.
VD>Если это будет статическая память (попросу кэш), то ее можно тактировать частотой ядра и получать офигительные решения. Каждый класс к тому же будет иметь разное число ядер, разную тактовую частоу и т.п.
VD>На будющее просто выростут объемы памяти и частоты. Классы же останутся.
В этом месте возникает существенная проблема (не техническая, а финансовая). PC завоевал рынок именно благодаря тому, что множество компаний выпускают под него комплектуху. Если же у производителей CPU начнутся попытки подмять под себя рынок RAM — начнётся попросту война. Intel уже пытался играть на этом рынке (Rambus) и в результате его послали куда подальше.
Ну и всех революционеров этот рынок тоже не терпит. Itanium таму очень хороший пример (вспомните, что обещалось, когда он появился).
VD>Это кстати позволит делать девайсы миниатюрнее.
Думаю для определённых (узких) классов задач решения будут постепенно возникать. Я бы и сам с радостью купил писюк, который весь (кроме монитора) находится в клавиатуре .
VD>Можно пойти и таким путем. делать матери сразу под много процессоров с доставляемыми процессорными блоками. Каждый блок доставляет не только процессор но и память.
Сложность (и стоимость) таких матерей будет очень высокая. И опять же вернёмся к проблеме передачи данных по проводникам печатной платы.
ИМХО это всё перспективы ещё не завтрешнего дня.
P.S. особенно понравился пункт 5 .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Думаю для определённых (узких) классов задач решения будут постепенно возникать. Я бы и сам с радостью купил писюк, который весь (кроме монитора) находится в клавиатуре .
Давно забытое старое? (синклер, микроша, вектор, поиск)
Да и сейчас есть тот же mac-mini
VladD2,
> ПК> И да, и нет. Если переписать, то, может, оно и нормально будет — сейчас, без эксперимента, сложно наверняка говорить Но вот причина, почему они не выпускают Office, перекомпилировав его с помощью MC++ или C++/CLI, заключается как раз в заметно уменьшающейся производительности, которую показывают собранные таким образом приложения Office.
> Это информация от группы Офиса, или умозаключения?
Это информация от группы VC++, сотрудничающей с группой Office в вопросах быстродействия MC++.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote:
>> C>Это, наверное, если все сервисы сразу запустить. Я долгое время без >> C>проблем работал на P166+32Mb+NT SP6... >> ... в notpad-е...
C>Нет, на Java в Kawa + FAR. Ничего, все нормально было.
Не расказывай сказки. SP6 вышел уже после выхода других версий ОС и он резко поднимает требования к ресурсам. NT4 + SP6 по потреблению ресурсов от W2k ничем не отличается. А работать в 32 метрах было не фонтан и вообще без сервиспаков.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>Если совсем примитивно картину нарисовать — это будет работать, если исходник состоит из нескольких файлов. То есть, всё равно нужен какой-то (последовательный) механизм который будет выделять эти "параллельные" части.
Современные программы состоят из кучи (обычно сотни, а то и тысячи) едениц компиляции (читай файлов). В грамотно спроектированных языках такие еденицы содержат довльно независимые еденицы программы, например, классы. Распараллелить их парсинг не проблема. Прочто создаем такое количество экземпляров парсеров сколько есть физический ядер процессора и в перед...
Возможно с этим будут проблемы в С++, но меня в последнее время его проблемы больше не волнуют.
GN> А вот как быть с той же таблицей символов? не пойму .
На стадии парсинга у грамотно спроектированных языков нет нужды обращаться к таблице символов. Более того такие таблицы можно формировать параллельно для каждой еденицы компиляции, а потом банально объеденять.
После того как будет сформирована единая таблица символов ее можно банально сдублировать для всех параллельных процессов.
Кстати, как таковой таблицы сиволов в современных компиляторах нет. Там все куда сложнее. Но при грамотном проектировании все это пареллелится.
GN> Тут нужно, что бы язык на уровне синтаксиса не давал создавать такие проблемы. То есть, для старых языков не годится.
Это да. Но на то они и старые чтобы или мутировать, или отмерать.
GN>Мои сомнения — не только мои догмы, но и догмы большого количества людей... Линкер-то и в С++ не особо нужен (ICC например идёт в этом направлении... и даже MSVC).
Еще раз повторю. Проблемы С++ меня не колышат. Если они есть, то пусть это волнует Саттеров и Страуструпов. Пусть принимают решения. Или они держатся за традиции и хоронят этот язык, или они его меняют выбрасывая маразм и добавляя нужные расширения. Собственно Саттер вроде как уже меняет, но вот Страуструп явно противодействует. Боюсь он победит. Ну, да и фиг бы с ними.
GN>А теперь представим, как все дружно пересаживаются на эти языки .
А что мне предствлять то? Превью C# 3.0 видел? Там почти все изменения связанны с поддержкой функционального стиля. Так что процесс уже пошел. Сначала в языки общего назначения войдут функциональные конструкции и библиотеки спроектированные в функциональном стиле, а потом появятся средства автоматического распараллеливания. Естественно процесс будет куда сложнее, но я же говорю только о тендненциях.
GN>Я таких областей не знаю, можно подробнее?
Например, в Аква (графическом движке Мак ОС Х) при переносе Мак ОС на PC эти команды задействованы очень сильно. Потом все кодеки видио их исользуют. Игры... Даже при простых вычислениях компиляторы вставляют эти инструкции. Пока еще робко, но это уже связано с совместимостью. В дотнете, например, таких проблем нет, так что там они будут использоваться все чаще и чаще.
GN> Если, например, говорить о параллельной обработке 4х float — так это маркетинг чистой воды. CPU и без того параллелит вычисления обычного последовательного кода. То есть, можно было довести до ума существующий механизм. SSE — по сути просто другой интерфейс к тем же самым вычислительным ресурсам. Где-то он удобнее и лучше, но это — результат того, что улучшали именно его, а не старый .
SSE — это как бы специализированные подпрограммы реализованные на аппоратном уровне.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Рекомендую попробовать проверить реальную зависимость быстродействия от checked/unchecked. Не стоит судить по количесту команд. repne scasd еще помнишь?
Скорость может упасть координально. Но дело не в этом. Если программа важная, но хрен с ней со скоростью. А если скорости и так зватает, то и думать не очем.
К тому же всегда можно услышав о проблеме неясного характера временно включить провекри переполнения. Если рпоблема в нем, то она будет быстро устранена.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR,
GN>>Думаю для определённых (узких) классов задач решения будут постепенно возникать. Я бы и сам с радостью купил писюк, который весь (кроме монитора) находится в клавиатуре .
FR>Давно забытое старое? (синклер, микроша, вектор, поиск)
Ну да . Дык если подумать — зачем нужен этот отдельный большой ящик...
FR>Да и сейчас есть тот же mac-mini
Mac может и хороший комп, но для себя не вижу никакого смысла в нём... разве что для понтов .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gear nuke, Вы писали:
GN>>Думаю для определённых (узких) классов задач решения будут постепенно возникать. Я бы и сам с радостью купил писюк, который весь (кроме монитора) находится в клавиатуре :)):up:.
FR>Давно забытое старое? :) (синклер, микроша, вектор, поиск) FR>Да и сейчас есть тот же mac-mini
Здравствуйте, VladD2, Вы писали:
VD>Современные программы состоят из кучи (обычно сотни, а то и тысячи) едениц компиляции (читай файлов). В грамотно спроектированных языках такие еденицы содержат довльно независимые еденицы программы, например, классы. Распараллелить их парсинг не проблема. Прочто создаем такое количество экземпляров парсеров сколько есть физический ядер процессора и в перед...
А если еще вспомнить об алгоритмах вроде GLR, которые параллелятся по своей природе ... Да и для простых LL(1) тоже кой чего в этом плане придумать можно. Например лексер работать в другом потоке с забеганием вперед в то время, когда парсер занят отработкой сложных правил. Или оптимизатор может часть подготовительной работы выполнять еще при парсинге.
GN>> Тут нужно, что бы язык на уровне синтаксиса не давал создавать такие проблемы. То есть, для старых языков не годится.
VD>Это да. Но на то они и старые чтобы или мутировать, или отмерать.
Функциональные языки, кстати, и здесь рулят
VD>SSE — это как бы специализированные подпрограммы реализованные на аппоратном уровне.
Конечно же нет. SSE выполняет специальных блок процессора, по сути векторный сопроцессор, аналог маковского AltiVec. Подробнее http://en.wikipedia.org/wiki/SIMD
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Возможно с этим будут проблемы в С++, но меня в последнее время его проблемы больше не волнуют.
А кого будут интересовать, что волнует Вас? Как показала жизнь, развитие индустрии идёт куда доллар покажет пальцем.
Кто сейчас делает наиболее качественные (с точки зрения производимого кода) компиляторы? Intel, MS и gnu.org. Первые 2 уже очень сильно обрадовались от появления Cell , а последние... у них даже препроцессор до сих пор отдельно от компилятора! .
VD>На стадии парсинга у грамотно спроектированных языков нет нужды обращаться к таблице символов. Более того такие таблицы можно формировать параллельно для каждой еденицы компиляции, а потом банально объеденять.
Действительно, от языка эта возможность больше всего зависит. Но выявление некоторых тупых ошибок, вроде 2х разный единиц трансляции с одинаковым содержимым будет уже только на стадии объединения происходить.
VD>После того как будет сформирована единая таблица символов ее можно банально сдублировать для всех параллельных процессов.
Скорее, даже не надо дублировать, доступ к ней на этом этапе достаточно read-only.
GN>>А теперь представим, как все дружно пересаживаются на эти языки .
VD>А что мне предствлять то?
А я о других людях говорю. Некоторых студентов на QuickBasic учат номера строчек писать .
VD>Например, в Аква (графическом движке Мак ОС Х) при переносе Мак ОС на PC эти команды задействованы очень сильно. Потом все кодеки видио их исользуют. Игры...
Использовать-то используют, но реального выигрыша не дают.
На примере AMD Athlon:
mulps ; (4 умножения) - 5 тактов, не параллелится
fmul; 4 такта, параллельно выполняется до 3х инструкций.
Это даже без учёта точности (у SSE хуже).
Единственно — для компилятора проще (с fpu единицы хорошо работают).
VD>SSE — это как бы специализированные подпрограммы реализованные на аппаратном уровне.
К таким "подпрограммам" можно отнести так же множество других команд. Например, call и ret .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я откуда знаю, почему ? Не возвращает fgets длину — и все. Могла бы, в принципе, но не возвращает. А на ней весь консольный ввод построен.
Гм. Боюсь тебя разочаровать, но никакого консольного ввода в окрестностях не наблюдается. Не пользуется им никто. ВинГУИ рулит. Увы. PD>Да и в WinAPI то же. К примеру, edit. Естественно, у него можно и длину спросить, и строку.
Именно! Более того, нельзя у него строку без длины получить:
int GetWindowText(
HWND hWnd,
LPTSTR lpString,
int nMaxCount
);
Return Values
The length, in characters, of the copied string, not including the terminating null character
PD>Есть, в общем, длина. Только от этого не легче — чтобы из этой ASCIIZ строки получить string, придется его конструктор вызывать, string(char*), а он эту строку к себе скопирует (и правильно, конечно, сделает) и длину пристроит.
Ну, здесь я ниче не понимаю. Я вижу, что из едита строка приезжает с длиной.
PD>Есть, не спорю. Только давай договоримся — из этого миллиона оставим только те, которые принимают на входе некий поток символов, а потом некий признак конца (не обязательно 0). Вот это и есть то, что я называю сырые данные.
Это ты здорово придумал. Если игнорировать окружающую действительность, то можно что угодно доказать. Давай договоримся лучше оставить те способы, которые применяются на практике.
PD>Во-первых, на МЛ были файлы — по крайней мере, в СМ-4. И длина у них была. а во-вторых подобный ернический тон, пожалуйста, оставь.
Как скажешь.
PD>Именно. Только от Win32 мы почему-то, как правило, получаем строки с отрезанной длиной.
Не мог бы ты показать мне те места в вин32, где мы получаем строку без длины? А то я может чего-то очень часто используемого не знаю.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Скорость может упасть координально.
Может. Но у меня есть глубокое подозрение, что современный процессор практически не заметит лишней инструкции, потому как:
1. Ему надо проверять только флаг, а не память. Ближе, чем этот флаг, для процессора ничего нету.
2. Переполнения достаточно редки; а это означает редкость сброса конвеера из-за ошибки предсказания.
Таким образом, даже выполнение проверки в цикле будет скорее всего тратить меньше времени, чем выборка следующего аргумента из памяти. Конечно, надо тестировать. Но хороший тест написать — это время надо, а у меня его мало VD> Но дело не в этом. Если программа важная, но хрен с ней со скоростью. А если скорости и так зватает, то и думать не очем.
С этим я тоже согласен. Особенно я готов сказать "хрен с ним" потере в 2%. VD>К тому же всегда можно услышав о проблеме неясного характера временно включить провекри переполнения. Если рпоблема в нем, то она будет быстро устранена.
+.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
GZ>Только вопрос в том, что для кого программирование работа, а для кого-то призвание. И первых значительно больше чем вторых. GZ>Так что если говорить о промышленных языках, то я бы сказал что они есть компромисс — помочь первым, и не мешать вторым.
Абсолютно с Вами согласен. Кому ж ещё рутиной заниматься, кроме первых.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Гм. Боюсь тебя разочаровать, но никакого консольного ввода в окрестностях не наблюдается. Не пользуется им никто. ВинГУИ рулит.
Боюсь тебя огорчить, но им пользуется нами всеми горячо любимый FAR. Это к примеру.
PD>>Да и в WinAPI то же. К примеру, edit. Естественно, у него можно и длину спросить, и строку. S>Именно! Более того, нельзя у него строку без длины получить: S>
S>int GetWindowText(
S> HWND hWnd,
S> LPTSTR lpString,
S> int nMaxCount
S>);
S>Return Values
S>The length, in characters, of the copied string, not including the terminating null character
S>
PD>>Есть, в общем, длина. Только от этого не легче — чтобы из этой ASCIIZ строки получить string, придется его конструктор вызывать, string(char*), а он эту строку к себе скопирует (и правильно, конечно, сделает) и длину пристроит. S>Ну, здесь я ниче не понимаю. Я вижу, что из едита строка приезжает с длиной.
Все верно, кто же спорит. Но возвращают строку отдельно, а длину отдельно. Вот если бы эта функция string STL вернула, другой разговор был бы. А так — придется этот, между прочим, char* буфер, передать string констуктору, который эту длину перевычислит.
Так что возвращает edit длину или нет — с точки зрения конструирования string не имеет значения.
PD>>Есть, не спорю. Только давай договоримся — из этого миллиона оставим только те, которые принимают на входе некий поток символов, а потом некий признак конца (не обязательно 0). Вот это и есть то, что я называю сырые данные. S>Это ты здорово придумал. Если игнорировать окружающую действительность, то можно что угодно доказать. Давай договоримся лучше оставить те способы, которые применяются на практике.
А какие способы для ввода в ЭВМ текстовой информации вообще существуют ?
PD>>Именно. Только от Win32 мы почему-то, как правило, получаем строки с отрезанной длиной. S>Не мог бы ты показать мне те места в вин32, где мы получаем строку без длины? А то я может чего-то очень часто используемого не знаю.
Еще раз — вспомни, из-за чего весь сыр-бор разгорелся. Дарней мне привел пример, где, по его мнению, string быстрее. Я ему объяснил, что string еще сконструировать надо из сырых данных, а это char*. Если ты мне можешь показать место в вин32, где возвращают уже сконструированные объекты классов string (или другие) — признаю свою неправоту.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>
S>>int GetWindowText(
S>> HWND hWnd,
S>> LPTSTR lpString,
S>> int nMaxCount
S>>);
S>>Return Values
S>>The length, in characters, of the copied string, not including the terminating null character
S>>
PD>>>Есть, в общем, длина. Только от этого не легче — чтобы из этой ASCIIZ строки получить string, придется его конструктор вызывать, string(char*), а он эту строку к себе скопирует (и правильно, конечно, сделает) и длину пристроит. S>>Ну, здесь я ниче не понимаю. Я вижу, что из едита строка приезжает с длиной.
PD>Все верно, кто же спорит. Но возвращают строку отдельно, а длину отдельно. Вот если бы эта функция string STL вернула, другой разговор был бы. А так — придется этот, между прочим, char* буфер, передать string констуктору, который эту длину перевычислит. PD>Так что возвращает edit длину или нет — с точки зрения конструирования string не имеет значения.
std::string имеет конструктор, принимающий два итератора. Передаёшь в него указатели на начало и конец строки и никакого перевычисления длины не происходит. А ещё есть конструктор, который передаётся указатель на начало и длина.
.
(синклер, микроша, вектор, поиск)
Но вот причина, почему они не выпускают Office, перекомпилировав его с помощью MC++ или C++/CLI, заключается как раз в заметно уменьшающейся производительности, которую показывают собранные таким образом приложения Office.
.
1.1.4 stable rev. 510
