Re[7]: да? - Компьютерные священные войны

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот насчет такого

PD>// глобальные переменные
PD>float f1= 0.99;
PD>float f2= 0.99;

PD>ИМХО никакого склеивания не будет, а будут два четырехбайтника в секции .data со значением 0.99f.

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

Вот простой код (добавил printf, чтобы оптимизатор не выкидывал код):

const double a_0_1 = 0.1;
const double b_0_1 = 0.1;

int _tmain(int argc, _TCHAR* argv[])
{
    int i = (int)pow(a_0_1, 0.2);
    int j = (int)pow(b_0_1, 0.3);
    printf("%d, %d", i, j);

    return 0;
}

Вот тебе с оптимизацией:

    int i = (int)pow(a_0_1, 0.2);
00401006  fld         qword ptr [4020F8h] 
0040100C  fld         qword ptr [402118h] 
00401012  call        _CIpow (401840h) 
00401017  sub         esp,8 
    int j = (int)pow(b_0_1, 0.3);
0040101A  fstp        qword ptr [esp] 
0040101D  fld         qword ptr [4020F8h] 
00401023  fld         qword ptr [402110h] 
00401029  call        _CIpow (401840h) 
0040102E  sub         esp,8 
    printf("%d, %d", i, j);
00401031  fstp        qword ptr [esp] 
00401034  push        offset string "%g, %g" (402108h) 
00401039  call        dword ptr [__imp__printf (4020A0h)]

Интересующее выделил. Без оптимизации там разные адреса.

V>>Первоначально литерал в программировании — это символьное представление значения, которое преобразуется в само значение компилятором.

PD>Вот тебе два таких символьных представления , которые и будут преобразованы.

>>В "жаргонном" и более узком смысле литералом называют константы, требующие память для размещения (наверняка из-за влияния С).

PD>М-да... А не мог бы ты привести пример константы, не требующей памяти для размещения ? Я как-то плохо это себе представляю — константа есть, а памяти ей никак не надо

. Только не вздумай мне говорить, что можно ее прямо в коде разместить — на это тоже память нужна.

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

Кстати, если ты в приведенном примере попытаешься взять адреса этих констант, то там будут разные адреса, как и положено по спецификации С++, но пока ты адрес константы не брал, или же у тебя константа в виде литерала прямо по коду — склеивает аж бегом.

PD>>>Насчет склеивания числовых констант — не слышал. И уж вряд ли линкер (а не компилятор) будет их склеивать из разных статических либ.

V>>И будет и склеивает, в том и фишка link-time codegeneration.
V>>GCC тоже частично это уже умеет, правда пока только для С.

PD>Можно подробнее ? Со ссылками ? Я — не понимаю.

PD>// глобальные переменные
PD>float f1= 0.99;
PD>float f2= 0.99;

PD>Ты утверждаешь, что их склеят ? То есть в секции .data будет... впрочем, что будет ? Я вообще не пойму, что там может быть, если их склеить. Это же не указатели, и не на read-only память.

Павел, давай уже или внимательно что-то обсуждать или не обсуждать вообще. Зачем ты мне приводишь глобальные переменные, когда я говорил о константах?

Глобальные переменные, константы и литералы — это разные с т.з. компилятора объекты, хоть они могут иметь один и тот же тип. До тех пор пока ты у константы не попросил lvalue — это константа, как только попросил — она превращается в глобальную переменную константного типа. Ввиду того, что у литерала попросить lvalue сложновато, они всегда "чистые" константы, со всеми вытекающими, т.е. спокойно склеиваются при оптимизации.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>http://rsdn.ru/forum/education/3775853.1.aspx

PD>http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx

PD>Ну что, господа, вот и все.
PD>Может, конечно, Итаниум где-то еще и будет использоваться... Есть в конце концов еще всякие весии Unix... Но вряд ли MS плохо просчитала свое решение.
PD>Фактически можно про эту архитектуру забыть, по крайней мере тем, кто ориентируется на продукты от MS. Покупать машины на базе Итаниум эти люди и организации больше не будут.

Павел. Ей-богу, смешно.
Весь мир HPC построен на итаниумах — вся линейка HP Integrity, например. Вплоть до Superdome. Если бы HP сказали, что они отказываются от итаниумов в этой линейке — это было бы да.
А то, что отказывается MS говорит лишь одно — ни асилили. У них была очень ограниченная поддержка. Винды для NUMA систем не было — там был только вариант с HP-UX или OpenVMS и нарезка на партиции, на которых уже винду ставить.

PD>Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ?
Для персоналок? Это как бы не для персоналок...

Здравствуйте, Roman Odaisky, Вы писали:

RO>В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть.

ну нет в моем Core i7 3DNow. Выкинуть эту тормозную штуку?

RO>Соответственно, в 21 веке компилируют программы в машинный код i386.

Ох уж этот линукс... Все в нем не то да не так.

Здравствуйте, Torie, Вы писали:

T>Попробуем с другой стороны

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Torie, Вы писали:

DOO>>Смотря в каких задачах.
DOO>>Ну нельзя же так огульно заявлять сразу обо всем.

T>Попробуем с другой стороны

Для каких задач обычного юзера не хватало процессоров 10-летней давности?

А че это ты так сразу сузил область-то?
Речь вроде про итаниумы шла — на десктопах и нет и не было...

Здравствуйте, Sheridan, Вы писали:

CC>> С или С++ достаточно кошерный язык?
S>Дадада. Нада 2 кнопки: 0 и 1
Т.е. если пишут не в машинных кода — для тебя это будет "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу"?

S> Ах даааа... Каааак я мог забыть. Потоки же труднее программировать — студентов уже не посадишь за клавиатуру, придется более опытных сажать и более больше им платить. Ну просто уму непостижимо, да?
Бред. Даже комментировать не стану.

S>Ей богу, уж если и гнать "вооружения", то в сторону параллельных вычислений с кучей cpu на кристалле.
Так они сейчас в эту сторону и так развиваются. По скорости одного ядра уже упёрлись в границу, выше которой подымать частоты уже нерационально.
И пусть развиваются. И для проца в 80 ядер найдётся чем его нагрузить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Sheridan, Вы писали:

LS>> Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.
S>Гы, ясен хер. Сам поймешь почему так?
Потому как контент сейчас стал более тяжёлым, т.к. железо позволяет.
Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, squid, Вы писали:

S>Топовые компы старее Pentium 4? А эти "топовые компы" не протухли еще?

Че-то ты заблудился во времени, Пентиум-4 вышел ровно 10 лет назад, а не 3.
Я имею ввиду те процы, которые были до Core2, т.е. до x86/x64 линейки, и отличались высокой тактовой, в диапазоне 3.2-3.8ГГц. А кое-какие экземпляры разгоняются до более 4ГГц. Подозреваю, что им до протухания еще очень долго, учитывая застой в развитии быстродействия процессоров, которое практически неизменно последние 5 лет в пересчете на ядро.

Здравствуйте, Torie, Вы писали:

PD>>И ? Тормозило потому, что использовали тормозную систему (не то компилятор, не то интерпретатор, не то черт знает что).
T>JavaScript — самый обычный интерпретатор, даже не JIT. То есть тормознее просто некуда.
SWF, кстати, тоже. Насколько я помню, он декомпилируется вместе с именами идентификаторов и комментариями. А если вспомнить еще PHP то легко поставить диагноз: весь УЁБ 2.0 поражен вирусом запредельных тормозов, так сказать, by design. Сервера и клиенты 90% процессорного времени тратят не на полезную работу, а хрен знает на что. А ведь даже сегодня ВСЕ можно сделать нормально, просто взять и сделать.

Здравствуйте, CreatorCray, Вы писали:

S>>>>thebat, kmail — про них уже както забыли наверное?
CC>>>Ну вот дома у меня стоит thebat, а вот если мне надо с работы личной почтой попользоваться?
Q>>Чтобы воспользоваться с работы личной почтой достаточно простого, почти статического интерфейса без мегабайта тормозных скриптов.
CC>Это зависит от того, что тебе в почте надо сделать.
В данном контексте явно подразумевается "воспользоваться", т.е. посмотреть какое-то письмо, или по-быстрому что-то написать. Это не регулярная работа, и навороченный интерфейс тут не нужен. Там более такой. Тем более, что гораздо более функциональный интерфейс уже десятки лет доступен вышеназванным настольным программам, которые быстро работали уже тогда.

Налицо постоянная подмена понятий. Вы говорите что-то типа "системы десятилетней давности не потянули бы этого и этого", мы же говорим, что "системы десятилетней давности тянули гораздо более сложные вещи, прости тогда их делали нормальным инструментом, а не жабаскриптом и браузером".

Здравствуйте, Mamut, Вы писали:

M>Действительно. Просто взять и сделать. Причем, все. Осталось только определиться — на чем делать-то будем?

Уже есть Silverlight. Это конечно не идеал, но хороший шаг вперед. Надеюсь, он наконец убьет всё это аяксовебобезумие.

Q>Налицо постоянная подмена понятий. Вы говорите что-то типа "системы десятилетней давности не потянули бы этого и этого", мы же говорим, что "системы десятилетней давности тянули гораздо более сложные вещи, прости тогда их делали нормальным инструментом, а не жабаскриптом и браузером".

Для того, чтобы пользоваться этой функциональностью, надо было иметь одинаково настроенные системы на всех компах, за которыми ты работал (как минимум, одну на работе, одну дома). Я лично на оффлайн клиенты пересел только когда поимел ноутбук. До этого GMail, GMail и еще раз GMail

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, sndanil, вы писали:

s>> Full HD Video? Crysis (и еще целая куча игрушек)?
S>Так и запишем: для развлечений.

Есть ещё обработка фотографий, например. Некоторые интересные алгоритмы 10 лет назад практически нельзя было применять из-за ресурсоёмкости. Да даже работа с документами, банально поиск, индексация и обработка, всё это требовало и требует времени.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>На сегодня это означает 3 бинарника вместо одного.

НС>Или .NET/Java

На тех задачах, где вообще звучит SSE, про эти платформы упоминать малость неприлично.

Здравствуйте, quwy, Вы писали:

S>>"Раз кто-то пишет вообще на скриптах, то нафига нам сильно стараться? Все равно хуже не будет." А в итоге иногда как раз хуже и получается, но мозгов исправить уже нет -- атрофировались, а платит за апгрейд в итоге все равно юзер.

В VS2010 систему справки переделали полностью, там вместо старого просмотрщика документов теперь обычный IE, который забирает контент с винта через локальный веб-сервер. OMFG! o_O
На переделку явно вбухана куча труда, тормозит еще хуже чем раньше, функционал зарезали, нет даже индекса слов.

Зачем???? Со всех сторон — одни недостатки.
Видимо, кто-то из манагеров прочитал в новостях, что сегодня web-based — это очень модно.

Здравствуйте, Mamut, Вы писали:

V>>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

M>Угу, и сколько человеколет для этого нужно?

В числодробилках? Ровно столько, сколько стоит изобрести и отладить алгоритм. А реализация готового алгоритма на любом из языков (поддерживающих арифметические вычисления) — это такая незаметная и под микроскопом ерунда, что обсуждать тут нечего.

Или ты про реализацию фиберов спрашивал? Все уже давно работает.

Здравствуйте, Sheridan, Вы писали:

k>> Вот когда ты сумеешь принести домой этот кинотеатр — тогда вернёмся к этому разговору.
S>

Зачем?
Затем, что речь шла о домашнем видео.

S>Да почти любой hd-медиаплеер имеет на борту камень с частотой сильно меньше гигагерца.
"Почти любой hd-медиаплеер" имеет на борту аппаратный декодер, мы же говорим о компе с процом общего назначения.

Здравствуйте, Antikrot, Вы писали:

A>И это говорит человек, который требует от других знать как ОС работает внутри

Кстати, выбор в конфигураторе таки влияет, но sse тут не причём. Кроме того — а ты точно уверен, что оно не будет *медленнее*?

Для GCC последних версий — не будет. Кстати, этот зоопарк несовместимых по командам x86-х — реальный аргумент в пользу Шеридана в его агитации собирать все из исходников.

Здравствуйте, Mamut, Вы писали:

V>>Или ты про реализацию фиберов спрашивал? Все уже давно работает.

M>Не про реализацию фиберов. А про реализацию многопоточности + асинхронных сообщений + отслеживания ошибок в этих сообщениях + иерархии процессов, как в Эрланге (где все это уже есть — бери и пользуйся).

Ты уверен, что знаешь, о чем говоришь? Вот как раз на днях недавно было обсуждение процов и там готовый пример распараллеливания перемножения матриц. http://www.rsdn.ru/forum/education/3775892.1.aspx
Переведи на Эрланг. Сравни кол-во кода и быстродействие. Понимаешь, распараллеливание в Эрланге хорошо там, где мы много автоматов "разворачиваем" из логики потактового хождения по состояниям в обычный код, и упомянутые "сообщения" и "синхронизация" в этом контексте — обычные сигналы, которыми автоматы обмениваются друг с другом. Что же касается числодробилок, то распараллеливание там предметнозависимо, т.е. нагрузка на прикладную часть все равно выходит больше, чем на языковую. Поэтому пока языки не очень помогают, зато хорошо помогают библиотеки заготовок для распараллеливания частовстречающихся вычислительных сценариев.

M>Более того, какого уровня должен ыть программист на C/C++, чтобы все это реализовать на фиберах.

Такого же уровня, чтобы мог реализовать на обычных тредах.

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

Выделенное — грабли для наивных верующих в Эрланги и прочее "самораспараллеливание".

На самом деле там не все так просто, "тупое" и автоматическое распараллеливание лишь ухудшает общие показатели. Сейчас объясню. Вот у нас есть N ядер, и M начальных потоков вычислений, каждый из которых, не зная о существовании других, выразил желание распараллелиться на N имеющихся ядер для пущей эффективности своего вычисления. При равномерной политике балансировки в худшем сценарии все M*N образованных вычислительных потоков будут шедулиться одновременно, поэтому каждый изначальный логический поток вычисления завершится примерно вместе со всеми, т.е. в М раз дольше, чем требуется для его вычисления. А если их как-то упорядочить, распараллеливая поочередно, то, не меняя общее время вычисления, каждый из M вычислительных алгоритмов, кроме последнего, будет вычислен гораздо быстрее.

Так что, в моих экспериментах с числодробилками наибольшую эффективность (как и следовало ожидать) показывает пакетный подход. "Пакеты" образуют единую очередь; текущему вычисляемому пакету доступны все ядерные ресурсы, остальные тихо ждут и не мешают. В общем, повторюсь, предметная сложность пока перевешивает языковую.

Здравствуйте, vdimas, Вы писали:

PD>>Я что-то вообще перестал понимать, что мы тут обсуждаем. Сделать ПО, которое использует или не использует тот или иной набор инструкций, вроде как не такая уж большая проблема...
V>На сегодня это означает 3 бинарника вместо одного.
Нет.
http://www.intel.com/software/products/compilers/docs/flin/main_for/copts/common_options/option_ax_lcase.htm

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

A>> S>Ясен пень, они просто вынуждены уходить в сторону многоядерности.
A>> пень не ясен. у тебя уже есть масштабируемые алгоритмы для всего-всего?
S>Они обязательно уже должны быть? Вдобавок еще и у меня?
S>Дядь, а можно они будут не у меня, а их просто напишут более опытные программисты, а?

Зачем обязательно более опытные? Интсрумент (а язык программирования — это в первую очередь всего лишь инструмент) должен помогать программисту, а не мешать ему. Вот, ознакомься на досуге: http://grey-kristy.livejournal.com/87271.html

Здравствуйте, vdimas, Вы писали:

V>Это только тот код, который работает с абстракциями. А все реальные дрова, реализующие эти абстракции, кодеки и т.д. — многократно больше.

Батенька, не смеши. Дрова сами по себе, а это ядро системы. Оно реализует вксь kernel и executive.

The Windows 2000 executive is the upper layer of Ntoskrnl.exe. (The kernel is the lower layer.) The executive includes the following types of functions:

Functions that are exported and callable from user mode. These functions are called system services and are exported via Ntdll. Most of the services are accessible through the Win32 API or the APIs of another environment subsystem. A few services, however, aren't available through any documented subsystem function. (Examples include LPCs and various query functions such as NtQueryInformationxxx, specialized functions such as NtCreatePagingFile, and so on.)

Functions that can be called only from kernel mode that are exported and documented in the Windows 2000 DDK or Windows 2000 Installable File System (IFS) Kit. (For information on the Windows 2000 IFS Kit, go to www.microsoft.com/ddk/ifskit.)

Functions that are exported and callable from kernel mode but are not documented in the Windows 2000 DDK or IFS Kit (such as the functions called by the boot video driver, which start with Inbv).

Functions that are defined as global symbols but are not exported. These would include internal support functions called within Ntoskrnl, such as those that start with Iop (internal I/O manager support functions) or Mi (internal memory management support functions).

Functions that are internal to a module that are not defined as global symbols.

The executive contains the following major components, each of which is covered in detail in a subsequent chapter of this book:

The configuration manager (explained in Chapter 5) is responsible for implementing and managing the system registry.

The process and thread manager (explained in Chapter 6) creates and terminates processes and threads. The underlying support for processes and threads is implemented in the Windows 2000 kernel; the executive adds additional semantics and functions to these lower-level objects.

The security reference monitor (described in Chapter 8) enforces security policies on the local computer. It guards operating system resources, performing run-time object protection and auditing.

The I/O manager (explained in Chapter 9) implements device-independent I/O and is responsible for dispatching to the appropriate device drivers for further processing.

The Plug and Play (PnP) manager (explained in Chapter 9) determines which drivers are required to support a particular device and loads those drivers. It retrieves the hardware resource requirements for each device during enumeration. Based on the resource requirements of each device, the PnP manager assigns the appropriate hardware resources such as I/O ports, IRQs, DMA channels, and memory locations. It is also responsible for sending proper event notification for device changes (addition or removal of a device) on the system.

The power manager (explained in Chapter 9) coordinates power events and generates power management I/O notifications to device drivers. When the system is idle, the power manager can be configured to reduce power consumption by putting the CPU to sleep. Changes in power consumption by individual devices are handled by device drivers but are coordinated by the power manager.

The WDM Windows Management Instrumentation routines (explained in Chapter 5) enable device drivers to publish performance and configuration information and receive commands from the user-mode WMI service. Consumers of WMI information can be on the local machine or remote across the network.

The cache manager (explained in Chapter 11) improves the performance of file-based I/O by causing recently referenced disk data to reside in main memory for quick access (and by deferring disk writes by holding the updates in memory for a short time before sending them to the disk). As you'll see, it does this by using the memory manager's support for mapped files.

The virtual memory manager (explained in Chapter 7) implements virtual memory, a memory management scheme that provides a large, private address space for each process that can exceed available physical memory. The memory manager also provides the underlying support for the cache manager.

In addition, the executive contains four main groups of support functions that are used by the executive components just listed. About a third of these support functions are documented in the DDK because device drivers also use them. These are the four categories of support functions:

The object manager, which creates, manages, and deletes Windows 2000 executive objects and abstract data types that are used to represent operating system resources such as processes, threads, and the various synchronization objects. The object manager is explained in Chapter 3.

The LPC facility (explained in Chapter 3) passes messages between a client process and a server process on the same computer. LPC is a flexible, optimized version of remote procedure call (RPC), an industry-standard communication facility for client and server processes across a network.

A broad set of common run-time library functions, such as string processing, arithmetic operations, data type conversion, and security structure processing.

Executive support routines, such as system memory allocation (paged and nonpaged pool), interlocked memory access, as well as two special types of synchronization objects: resources and fast mutexes.

Kernel
The kernel consists of a set of functions in Ntoskrnl.exe that provide fundamental mechanisms (such as thread scheduling and synchronization services) used by the executive components, as well as low-level hardware architecture-dependent support (such as interrupt and exception dispatching), that are different on each processor architecture. The kernel code is written primarily in C, with assembly code reserved for those tasks that require access to specialized processor instructions and registers not easily accessible from C.

Like the various executive support functions mentioned in the preceding section, a number of functions in the kernel are documented in the DDK (search for functions beginning with Ke) because they are needed to implement device drivers.

И это далеко не все. И про win32k.sys я могу такое же найти.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Совершенно верно. Я просто пытаюсь объяснить, что если код, зависимый от употребления или неупотребления SSE, вынести в отдельную DLL да так, чтобы там ничего, кроме этого кода не было, да сделать несколько таких DLL (без SSE / SSE1 /SSE2...), то размер инсталляционного пакета изменится незначительно.

Всё давно уже придумано.
http://www.intel.com/software/products/compilers/docs/flin/main_for/copts/common_options/option_ax_lcase.htm

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, kig, Вы писали:

V>>>могла поддерживать теоретически бесконечную вложенность операционных систем на основе СВМ, ввиду того, что виртуализируемая машина работала практически с той же скоростью, что и невиртуализируемая

kig>>Теоретически — да. Но на практике, например, на ЕС-1046 с 8 мгб, третий уровень работал сносно, четвертый изрядно тормозил, а пятый — еле двигался.

(BTW — я считал с 0, т.е. 0 — это реальное железо, 1 — обычная VM. Генерация нового CP в VM/SP — это стандартный режим запуска вновь сгенеренного CP под VM — т.е. 2 уровень. А так, просто загружая CP под CP до 5 уровней вложенности на 46 доходили).

V>Вот мне интересно посмотреть на пятый уровень вложенности какого-нить VirtualPC.

Сам чистый VPC — вряд-ли. Он сам под собой ляжет.

Но в мире Intel/AMD в этом направлении тоже двигаются. Мотивация, правда, несколько другая.

Защита или, наоборот, взлом. На эту тему здесь уже kochetkov.vladimir бросал ссылку (здесь).

Ну и собственно по nested virtualization:
гугл
здесь Рудковска здесь пишет:

It's worth mentioning that the only other working example of nested hardware virtualization I'm aware of is the IBM z/VM hypervisor for the IBM z series mainframe. If anybody knows any other example, please send me a link.

здесь
здесь
здесь
здесь

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это как бы в свое время позиционировалось как идущее на смену x86... Во всяком случае, когда о нем начали говорить, x64 не было и в помине и Intel не собиралась его делать, так что переход на 64-битные процессоры означал переход на Итаниум.

А оно кому-то надо? x86 столь ужасна? помоему нет. по крайней мере для обычных персоналок а не для серваков

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?

Даже Intel Atom держит SSSE3. Как и все Core2 Duo.
А SSE3 держат даже Celeron D и Pentium DualCore.
Про SSE2 вообще молчу. Его не держат разве что уже крайне устаревшие процы (до P4 / PM).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

RO>>Вот представь себе, что ты собираешь ядро ОС. Компилируешь с -msse3? А с -msse2?
PD>При чем тут ядро ?

Вопрос звучал так: «x86 столь ужасна?» — да, она ужасна тем, что значительная часть ключевых программ для этой архитектуры собирается без использования современных наборов инструкций. В том числе и ядро ОС, зачастую.

Здравствуйте, vdimas, Вы писали:

V>А что делать с топовыми компами, выпущенными более 3-х лет назад? Это отличные рабочие лошадки, с чего бы их на помойку?

Топовые компы старее Pentium 4? А эти "топовые компы" не протухли еще?

Здравствуйте, Sheridan, Вы писали:

s>> а ты что ожидал в списке задач обычного юзера? научные расчеты?
S>Домашняя бухгалтерия, "умный дом" например. Управление автомобилем в конце концов. Ей богу, лучше бы автопилот автомобилям сделали вместо говноигр и мегаХД.

S>Но дело не в этом. Дело в расслабляющихся в лучах мощностей программистов, которые прикрывают свой расслабон чемто типа "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу".
С или С++ достаточно кошерный язык?
Есть задачи которым до сих пор исходя из самого алгоритма решения требуется дофига памяти и дофига операций (читай процессорного времени).
Просто ты с ними видимо не встречался.
Финансовая аналитика например.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, sndanil, Вы писали:

S>Здравствуйте, Torie, Вы писали:

T>>Попробуем с другой стороны

Для каких задач обычного юзера не хватало процессоров 10-летней давности?

S>Full HD Video? Crysis (и еще целая куча игрушек)?

Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

Приветствую, LuciferSaratov, вы писали:

LS> Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

Гы, ясен хер. Сам поймешь почему так?

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Я что-то вообще перестал понимать, что мы тут обсуждаем. Сделать ПО, которое использует или не использует тот или иной набор инструкций, вроде как не такая уж большая проблема...

Здравствуйте, Sheridan, Вы писали:

S>Я вообще не понимаю этой гонки мощностей. Компы уже давно, лет десять как превышают потребности этак порядка на два-три. Разве что для криворуких программистов, которые не умеют писать на нормальных, компилируемых языках, и которые отмаиваются "...тормозит?

Чертовски странная у тебя логика. 99% прог сделаны на C++ и C, а виноваты почему-то программисты "которые не умеют писать на компилируемых языках"

Здравствуйте, CreatorCray, Вы писали:

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

Нет, конечно.

CC>Говнокодеры были всегда и увы, будут.

Беда в том, что нынешние системы их на это провоцируют.

Здравствуйте, Mamut, Вы писали:

S>>Но дело не в этом. Дело в расслабляющихся в лучах мощностей программистов, которые прикрывают свой расслабон чемто типа "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу".

M>Ты вообще в курсе, что те же видеокодеки написаны на... как там у тебя...
M>

M>на нормальных, компилируемых языках

Тот же CoreAVC вообще ассемблерные вставки использует.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

T>>Раньше сама идея делать сложный функционал на скриптовом языке была бы немедленно закидана тухлыми помидорами.
CC>Патамушта аццки тормозило.

И ? Тормозило потому, что использовали тормозную систему (не то компилятор, не то интерпретатор, не то черт знает что). Она что, быстрее стала ? Ничего подобного, как было, так и осталось тормозом. А вот скорости железа подросли, в итоге используем тот же тормоз, но все же едем на тормозе. А не подросли бы они — было бы то же, но не на этом медленном скрипте, а на чем-то более быстром.
Голландская болезнь.

Здравствуйте, Sheridan, Вы писали:

S>те что написаны на ц++ и ц — вполне себе пашут. А как только начинаются всякие дотнеты с питонами — сразу тормоза. Парадокс?

Ну и много у тебя лично прог на всяких дотнетах? И зачем ты так мучаешься, если они тебя не устраивают?

Здравствуйте, CreatorCray, Вы писали:

DOO>>Девелопер также будет делать, что велено. Либо начальством, либо "невидимой рукой рынка". Не надо тут образ благородного рыцаря создавать.
CC>Драсте. Тебе что, в тасках указывается какими алгоритмами пользоваться, какие контейнеры использовать и т.п.?
Скажем так — если я ставлю задачу инженеру поставить винду на сервер, то я ожидаю, что он ее решит в лоб — взяв диск и поставив и не будет умничать с PXE, RAD и тому подобными продвинутыми, но в данной ситуации не нужными технологиями.
В софтописании (насколько я знаю эту индустрию) — тоже самое. Если от кого-то требуется быстрое решение пусть и не самым оптимальным методом, то это решение и ожидается. Тот, кто начинает умничать и тратить времени больше запланированного — на самом деле портит все планы. Если этот кто-то считает, что его затраченное сейчас время оправдает себя потом — то надо объяснять это начальству, чтобы подобная задержка учитывалась в планах и т.п.
Не надо забывать, что любая разработка — задача коллективная. Тут надо эффективно работать в команде.

Здравствуйте, hattab, Вы писали:

M>> Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.
M>> Ну, не скажи. Threading и поиск по почте как рулили, так и рулят.
H>Пользователи Opera зевают...
Пользователи Fidolook вообще ржут во весь голос.

Здравствуйте, DOOM, Вы писали:

DOO>Смотря о каком куске игры речь.
DOO>Да и писатель пейсателю рознь... Одно дело ребята из Valve с их Source engine, другое какие-нибудь м..ки из авторского коллектива первого хитмана.

эм, а что в первом "Хитмане" было плохо?. у меня ни одного нарекания даже не возникало..

Здравствуйте, Pavel Dvorkin, Вы писали:

V>>На сегодня это означает 3 бинарника вместо одного.

PD>При инсталляциии поставится та, что нужно. Примерно так же , как с локализацией, например.
PD>Или один бинарник и несколько вариантов DLL, в которую и вынесено все, что depends.

По click-once тащить надо сразу все. Вот и получается, что вместо обычной линковки к DLL начинаем приседать с плагинной архитектурой или ручками GetProcAddress(). А точек входа — под 50...

Здравствуйте, Antikrot, Вы писали:

A>ты не совсем понял. Ц++ тут чуть ли не худший вариант.

Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах. Зато если речь пойдет о числодробилках, то тот же Эрланг сливает не по детски.

Здравствуйте, DOOM, Вы писали:

CC>>>>Ты в курсе что кроме красивости картинки под капотом есть ещё море вычислений которых на первый взгляд не видно.
DOO>>>Мы о чем говорим? Есть задача — есть пути решения. Кто-то решает эффективно, кто-то решает через опу.
F>>с какой игрой в стиле "Хитмана" ты сравнивал?.
DOO>Точно не помню. То ли HL 1, то ли IGI... Давно это было.

HL1 по картинке и функционалу до "Хитмана" очень далеко.. IGI в плане картинки такой же или чуть лучше, но это всё таки 3D-шутер с более простым функционалом..

DOO>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.

что то по поводу памяти у меня очень большие подозрения.. ну и по качеству картинки тоже сомневаюсь..
какие нибудь ссылки/доказательства есть?.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, vdimas, Вы писали:

V>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?
V>>А что делать с топовыми компами, выпущенными более 3-х лет назад? Это отличные рабочие лошадки, с чего бы их на помойку?

ВВ>Чет ты загнул, в моем "топовый" компе, купленном как раз три года назад, стоит Core2Duo.
ВВ>В предыдущем "топовом" компе, купленным до этого в году 2004 — стоял P4 Prescott.
ВВ>В предыдущем "топовом" компе, купленном еще года за три до этого, стоял P4 Northwood.

ВВ>Что интересно — означенный набор инструкций есть во всех этих процессорах, причем P4 я бы не назвал сейчас "отличной рабочей лошадкой".
ВВ>Может, ты ноликом ошибся?

Наверно ты просто не в курсе, в чем разница м/у SSE и SSE2.

Мой вариант вот: http://www.rsdn.ru/forum/flame.comp/3779791.1.aspx

А вот выдержка:

AMD Athlon XP. Конкурировали в основном с процессорами Pentium 4 на ядре Northwood. В названиях моделей этих процессоров фигурировала не тактовая частота, а рейтинг, показывающий производительность процессоров Athlon XP относительно Pentium 4. «Равнорейтинговые» Athlon XP уступали процессорам Pentium 4 в приложениях, оптимизированных под архитектуру NetBurst, требовавших наличие поддержки инструкций SSE2 или высокой пропускной способности памяти, однако значительно опережали их в вычислениях с плавающей запятой и неоптимизированных приложениях.

Компилировали эти процы (которые на ядре Barton) заметно быстрее, чем 4-е пни. Кстати, 3-е пни тоже компилировали заметно быстрее 4-х на той же тактовой, и зачастую умудрялись обгонять даже на гораздо меньших тактовых. Четвертый пень хорошо показывал себя лишь там, где уместен сверхдлинный конвеер, т.е. практически нигде кроме мультимедиа. Поэтому в качестве машины разработчика или как сервер был не самым лучшим выбором вплоть до выпуска гипертрединга.

A>>ты не совсем понял. Ц++ тут чуть ли не худший вариант.

V>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

Угу, и сколько человеколет для этого нужно?

Здравствуйте, DOOM, Вы писали:

DOO>Мне, как потребителю, глубоко филетово до того, какие они там преобразования Фурье использовали и прочие малопонятные вещи — я вижу просто: есть картинка №1 — симпатичнее и менее требовательная, есть картинка №2 — менее симпатичная и тормозящая. Отсюда вывод: картинка №2 создавалась некачественно. При чем тут написанные ими требования? Я тоже много что написать могу...

Игра это далеко не только картинка.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, DOOM, Вы писали:

DOO>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
Ты ничего не путаешь?
С минимальными настройками может он и заведётся, но тормозить будет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>500 КБ секция кода — легко.
CC>По ссылке ты речь ведёшь о МБ

Да, но все ядро системы вместо с графикой и окнами — примерно 4 Мб. Так что 500 Кб — это более 10% ядра ОС.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, vdimas, Вы писали:

V>>Это только тот код, который работает с абстракциями. А все реальные дрова, реализующие эти абстракции, кодеки и т.д. — многократно больше.

PD>Батенька, не смеши. Дрова сами по себе, а это ядро системы. Оно реализует вксь kernel и executive.

Ну и? Там перечисление десятка основных ф-ий ядра. Какая из приведенных тобой задач должна была быть большой по объему, сравнимой хотя бы с одним видеокодеком?

PD>И это далеко не все. И про win32k.sys я могу такое же найти.

И что оно даст? Вот что дает то, что ты смог найти?

ShellDll32.dll сегмент .text = 2M
Это в твою пользу или мою?

Ты можешь просто в фаре, в просмотрщике процессов посмотреть загруженные DLL и EXE процессов и просуммировать их размеры (не считая повторяющиеся, разумеется).

И вообще, вместо приведения примеров бог весть чего, не имеющего отношения ни к чему, просто спросил бы, что у меня там? У меня там пара десятков аудио-фильтров, миксеры, пред/пост обработчики речи, кодеки (как аудио, так и видео), генераторы, детекторы речи, компрессоры/декомпрессоры и т.д.

А знаешь что делает компилятор с числодробильными циклами при ключах оптимизации "предпочтение быстродействия", а не размера? С циклами фиксированного размера (те же циклы фильтров)? Он их разворачивает в линейку с коэф. в диапазоне 10-20, т.е. вместо 320-ти повторений мы обычно получаем 16 повторений, в каждом из которых линейно 20 раз повторяющийся код, и промежуточные данные не на стеке, т.е. не в памяти, а в MMX/SSE-регистрах. Это у меня еще маленькая DLL, ибо я ее собираю из нескольких статических либ, где оптимизации с предпочтением по быстродействию далеко не у каждой, чтобы размер бинарника не раздувать.

Здравствуйте, alpha21264, Вы писали:

A>Не тормозит. РМ 1200 МГц. Вентилятор иногда жужжит, но отрисовка не тормозит.

A>И вообще, КДЕ показывает что большую часть времени он работает на частоте 300 МГц.

У тебя там поди Noscript с AdBlock'ом, которые львиную долю тормозов со страниц вырезают.
Ну и тормоза — дело субъективное, я все же думаю, что на мощном процессоре все это будет работать заметно приятнее. Я вот замечаю, что страницы на нетбуке рисуются тормознее, чем на десктопной машине.

Здравствуйте, Mamut, Вы писали:

Q>>Налицо постоянная подмена понятий. Вы говорите что-то типа "системы десятилетней давности не потянули бы этого и этого", мы же говорим, что "системы десятилетней давности тянули гораздо более сложные вещи, прости тогда их делали нормальным инструментом, а не жабаскриптом и браузером".

M>Для того, чтобы пользоваться этой функциональностью, надо было иметь одинаково настроенные системы на всех компах, за которыми ты работал (как минимум, одну на работе, одну дома). Я лично на оффлайн клиенты пересел только когда поимел ноутбук. До этого GMail, GMail и еще раз GMail

Вот и я о том же.
Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.

Здравствуйте, Eugeny__, Вы писали:

E__>Вот и я о том же.
E__>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.
+1

E__>У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.
-1

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Eugeny__, Вы писали:

E> Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка?

Открой для себя уже флешки и portable applications... А вообще, сейчас, все решается сильно проще -- маленькими и легкими нетбуками.

E> Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

Как-то я пытался зайти на гуглопочту Оперой... Гуглапочта сказала, что не любит мой браузер.

Что ты будешь делать, когда инета нет? Я, разумеется, читал выше о том, что ты уже давно не видел компов без инета, и даже в лесу с телефона можно его поиметь. Однако сотовые сети в дневное время это вообще что-то (юзал и МТС и Мегафон)... Пока прогрузится html-морда сдохнуть можно. Кроме того связь есть не везде. Отъехал от города на 30км, спустился в низинку к озеру и пипец.

E> У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.

Веб-интерфейсы это унылые попытки закосить под нормальный десктопный гуй. Оффлайн клиенты — это доступ к базе почты в любой момент, вне зависимости от наличия инета. Более того, есть гаратния что ты не окажешься вообще без почты в самый важный момент, а так бывает:

http://www.computerra.ru/vision/455478/

В этот раз, однако, сотрудники Google недооценили загрузку роутеров, перенаправлявших запросы, в результате чего в 12:30 они оказались перегружены и в результате стали отвергать запросы, что повлекло перенаправление их на свободные маршрутизаторы. Когда и те оказались перегружены, доступ пользователей к странице Gmail был отрезан, в то время как с доступом по IMAP/POP было всё в порядке поскольку эти сервера работают на собственных мощностях.

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

avalon 1.0rc2 rev 272

Здравствуйте, Antikrot, Вы писали:

A>>>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
V>>Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.
A>а ты собрался в ядре вещественные обсчитывать на FPU/SSE?

Ты уверен, что расширения SSE только вещественные числа считают?

A>расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .

Зачем тебе эта утилита для нубов? Не понимаешь мейкфайлов?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sheridan, Вы писали:

S>>Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.

V>Вообще-то, особенности защищенного режима x86-го не позволяют реализовать виртуализацию действительно эффективно. Для сравнения, разработанная около 40 лет назад СВМ для ЕС ЭВМ (полностью советская разработка),

Справедливости ради надо заметить, что СВМ являлась клоном оригинала VM/370 — VM/SP, который как раз и был анонсирован IBM почти 40 лет назад в 1972.
В СССР до 79 года просто не было аналога 370 — ряда-2 (1060 называли "ряд-1.5")

V>могла поддерживать теоретически бесконечную вложенность операционных систем на основе СВМ, ввиду того, что виртуализируемая машина работала практически с той же скоростью, что и невиртуализируемая

Теоретически — да. Но на практике, например, на ЕС-1046 с 8 мгб, третий уровень работал сносно, четвертый изрядно тормозил, а пятый — еле двигался.

V> из-за особенностей архитектуры драйверов и организации управления памятью.

Ну как таковых, в современном понимании, драйверов там не было. Канальные программы — вот и весь ввод/вывод. Правда в 370, наряду с аппаратной поддержкой трансляции адресов для ЦПУ, такая же поддержка была реализована и в каналах ввода/вывода (привет VT-d/IOMMU

).

V>Достаточно сказать, что СВМ умела отображать страницы памяти на несколько независимых процессов в нескольких виртуальных ОС на сколь угодную по счету вложенную виртуальную "матрешку", поэтому использование разделяемых загруженных бинарных образов было весьма эффективное с т.з. использования ОП.

V>В х86-x64 такое невозможно, поэтому да, остается гнать производительность и расширять адресное пространство.

Ну все же они продвигаются, адаптируя идеи IBM 40-летней давности.

Здравствуйте, Константин Б., Вы писали:

КБ>Это в каком таком обычном десктопе есть Nvidia ION и прочее?
А в каком-таком плеере? Обычно там те же ATI, nvidia, а то и Intel или VIA.

DOO>>Конечно, на ноутбуке с Вистой и медиаплеером трудно получить FullHD без тормозов — но у связки Linux + mplayer требования уже в разы ниже...
КБ>С чего бы это вдруг?

Я же пробовал — никаких "в разы" не наблюдалось.
Недопробовал?

На самом деле эффект, что называется, налицо. Можно даже без смены ОС — просто поставить какой-нибудь K-lite Codec Pack и выполнить многостраничную инструкцию по настройке — до этого действа на ноуте тормозило даже 720p, после — вполне приемлемо заработало 1080p.

А фанатизмом с линуксом + заточенное ядро + скомпилированный из исходников mplayer я занимался во времена распространения DivX и компании — реально получилось смотреть фильмы на моем компьютере, который и близко по системным требованиям не подходил..

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Может, конечно, Итаниум где-то еще и будет использоваться... Есть в конце концов еще всякие весии Unix... Но вряд ли MS плохо просчитала свое решение.

PD>Фактически можно про эту архитектуру забыть, по крайней мере тем, кто ориентируется на продукты от MS. Покупать машины на базе Итаниум эти люди и организации больше не будут.

Почему-то никто не задался вопросом, а в чём смысл в сфере применения Itanium ориентироваться на продукты от MS?

Дело в том, что насколько я понимаю, обычные десктопные и серверные продукты от MS в сфере HPC просто напросто никому особо не нужны.

Здравствуйте, Eugeny__, Вы писали:

E__>Да, на этот("рабочий") ящик много всего зарегано, но все это не особо важно. Всякие говносайты, которые требуют для чего-то регистрацию, не особо живые аккаунты на всяких sun, launchpad и пр., да тот же вконтакте, на который я захожу хорошо если раз в месяц. Только потеря этих аккаунтов меня не волнует. Ну и да, эти восстановления паролей придется делать взломщикам вручную, беда в том, что получат они с этого меньше, чем затратили.
E__>"Напоминалки" на более важные ресурсы(как, например, инет-банкинг) я регил на тот, второй ящик, пароль к которому другой, и на который я зайду только в случае ЧП и сделаю это аккуратно. Благо, все важные ресурсы можно пересчитать по пальцам.

После всех этих приседаний и оговорок как-то не учень убедительно звучит тезис об удобстве веб-почты

Здравствуйте, Sheridan, Вы писали:

A>> Почему?
A>> Это кто смотря кто как пишет эти программы.
A>> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A>> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.
S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
объясни разницу применительно к "в 21 веке компилируют в код i386"?
все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Antikrot, вы писали:

A>> чем это он трудоёмкий?
A>> добавить
A>>

A>> if (cpuid(1).edx & (1<<26)) {
A>>   idct_sse2(...);
A>> } else {
A>>   idct_i386(...);
A>> }
A>>

A>> сложно?

S>Сложнее, чем просто idct(...);

Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!

Здравствуйте, vdimas, Вы писали:

N>>Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.
V>Слушай, а чего ты вообще к PPro прицепился? Я вот его в глаза не видел и ни один из коллег, с кем знаком лично, тоже его не видел.

И что я на это должен ответить, кроме как "возьми с полки пирожок"? Ты не видел? Сочувствую. Я видел. У меня были системы на нём, я работал с ним, другие работали. Это была совершенно уникальная вещь. Как тебе нравится, например, 128-битная плавучка (против максимум 80 у других в ряду), расширяемая в SMP до 256? (Не ищи этого в официальной документации, там нет.)

V> Изменения в указанной последовательности Пентиум->Пентиум II практически идентичны изменениям Пентиум->Пентиум Про. Я же показывал смену поколений, т.е. если бы указал ППро, надо было бы не указывать П2.

Да, P2 — попсовый кастрат на базе PPro, зато быстрее. Полностью новшества PPro (кроме явно убитых) во внутренней структуре поступили только в P3, не в P2.

V> А это не справедливо, ибо популярность в те времена П2 и ППро абсолютно несравнима. Или ты типа нашел за что меня поймать? :)

Есть пословица: кто не хочет учить свою историю — будет учить чужую. Ты отвергаешь PPro только потому, что он "непопулярен", значит, ты рассказываешь ложную историю. В сочетании с крайне странным подходом к тому, что есть важное изменение, а что нет — выглядит как попытка навязывания искажённого образа.

V> Ну это несерьезно. Если интересуют подробности, то да, когда-то давно, до того как к нас в город пришел нормальный интернет, я выписывал "компьютерное обозрение" и очень внимательно следил за соревнованием процов примерно до 2000-2001-го года, потом надоело. :xz:

Я не слежу за микропоколениями, эта информация в случае чего легко находится (и я в упор не помню, чем там Sledgehammer был лучше Clawhammer). Но основные вехи надо помнить, если ты вообще взялся что-то говорить про историю.

V>>>Хоть одно не косметическое, влияющее на архитектуру ядра?
N>>Устранение северного моста и прямое управление памятью.
V>Мимо, шинный формирователь никуда не делся, просто теперь он в процессоре.

Не "мимо", а он теперь совсем другой.

V> Но не в ядре. Помнишь, я говорил о различиях микропроцессоров и микроконтроллеров. Так вот, микроконтроллер — это ядро микропроцессора + некоторая периферия прямо в проце. Для примера посмотри на AMD Alchemy, там ядро известной архитектуры, и куча периферии на кристалле. Есть много разновидностей Alchemy, отличающихся периферией, но ядро идентично для них всех. Поэтому извини, но мимо. Даже если вообще всю оперативку в процессор запихают, как на многих микроконтроллерах, это не будет относится к ядру, а будет классическим SoC.

Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?

N>>Внос видеоконтроллера в процессор (в моделях, где он есть).
V>Из той же оперы. Я же задал вопрос не про микросхему, как таковую, а про ядро, т.е. про сам процессор.

А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.

N>>Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.
V>Э нет, два несовместимых ядра в гибриде, или же одно ядро с доработанным дешифратором и удвоенной разрядностью АЛУ — это две большие разницы. И все равно из этого сумбура (выделил) я не понял, как amd-x64 ломает совместимость.
V> Обратная совместимость не сломана, а "прямой" быть не может в случае любого расширения набора команд, необязательно в сторону расширения битности.

Вот именно что прямой совместимости быть не может. Считай, что я неудачно (для тебя) выразился. Я говорю, что отсутствие прямой совместимости давало возможность выбрать расширение с тотальной сменой системы команд.
"Одно ядро с доработанным дешифратором" тут никак не получалось: дешифраторы режимов 32 и 64 практически несовместимы. А обшую регистровую базу и АЛУ получалось сделать независимо от того, какая целевая архитектура — в них всех есть регистры и АЛУ. Ну сказали бы, например, что EAX = low(R0), EBX = low(R1) и так далее, всё бы работало.

V>Плохо в расширениях команд x86-го все это годы в том, что расширения идут через ограниченное мн-во префиксов, удлиняя код команды. Отсюда бинарники, использующие новомодные инструкции выходят довольно большими. Вот за весь этот наследованный груз и критикуют систему команд. Даже тот же набор команд (мнемонический их набор), если закодировать с 0-ля, можно получить куда как более оптимальное использование байт кода.

Ну и я о том же. Текущее решение выглядит очень странно.

N>>Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.
V>Нет, они пошли правильно, доводя до абсолюта две идеи: сверхдлинный конвейер и сверхширокие команды. Сейчас длина конвейеров тоже довольно большая, просто первый блин комом, им надо было постепенно развивать отличный (самый удачный ИМХО, если позиционировать на технологии "своего времени") Пень-3.

То есть адекватно осовременный PPro :) А про P4 и я говорю — блин комом, они допустили несколько явных промашек. В основном, похоже, это переоценка значимости приложений мультимедиа и прочих, где подход P4 работал. Только я бы сказал не "сверхдлинный конвейер", а "удлинение конвейера за счёт убивания качества подготовки команд". Потоковые действия от этого не пострадают, всё остальное начинает тормозить из-за поздно выявленных конфликтов.

V> А сейчас технологически реально Интелл отстает, и значительно. Они держат лидерство исключительно за счет экстенсивных факторов: это кол-во ядер на кристалл + раньше всех переходят на более миниатюрный процесс.

Они гонят "ядро на кристалл" потому что понимают, что иначе всем настанет, например, тотальный NUMA. К которому никто не готов по-настоящему (весь SMP уровня приложения сейчас реализует в лучшем случае заточку на однородную память; максимум что есть для NUMA это шедулер для малонитевых процессов). AMD слишком резко перешёл на эту структуру.

А ещё они не могут себе позволить быть не-первыми по чётким измеряемым цифрам для наиболее тяжёлых задач — это уже маркетинг.

N>>>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.
V>>>Ну и почему? Разве не понятно?
N>>Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.
V>Из-за цены. Вторые пни пошли по реально низким ценам, Интеллу удалось взять реванш за K-5, которые практически полностью задавили первый пентиум. Твой любимый Пень-Про в массы не пошел, если помнишь. И я скажу почему — исключительно из-за цены, хотя этот проц, судя по публикуемым характеристикам, был не плох.

Я и не спорю, что он в массы не должен был идти: это был чисто серверный вариант, к тому же с заточкой под военщину США. Но новшество было в нём. Если сравнить, например, с автомобилестроением — новые решения и технологии сначала поступают в дорогие изделия и затем только перебираются в дешёвые.

Кстати, где-то с 99-го его мог купить любой:) цены упали. И я знаю тех, кто покупал именно его — потому что под их задачи работал в разы лучше P2 и не сильно хуже P3.

N>>Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

V>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

Не понял — чем тут три цикла лучше или хуже?

http://rsdn.ru/forum/education/3775853.1.aspx

http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx

Ну что, господа, вот и все.

Может, конечно, Итаниум где-то еще и будет использоваться... Есть в конце концов еще всякие весии Unix... Но вряд ли MS плохо просчитала свое решение.

Фактически можно про эту архитектуру забыть, по крайней мере тем, кто ориентируется на продукты от MS. Покупать машины на базе Итаниум эти люди и организации больше не будут.

Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ? Не знаю. Не верю.

Судя по всему, архитектура 8086 сумела за себя постоять. Это всерьез и очень надолго теперь. Может быть, даже на все обозримое будущее , если только не случится какой-то радикальной революции.

Здравствуйте, DOOM, Вы писали:

PD>>Ну что, господа, вот и все.
PD>>Может, конечно, Итаниум где-то еще и будет использоваться... Есть в конце концов еще всякие весии Unix... Но вряд ли MS плохо просчитала свое решение.
PD>>Фактически можно про эту архитектуру забыть, по крайней мере тем, кто ориентируется на продукты от MS. Покупать машины на базе Итаниум эти люди и организации больше не будут.

DOO>Павел. Ей-богу, смешно.
DOO>Весь мир HPC построен на итаниумах — вся линейка HP Integrity, например. Вплоть до Superdome. Если бы HP сказали, что они отказываются от итаниумов в этой линейке — это было бы да.

Ну я же ясно объяснил, в каком контексте. См. выше.

DOO>А то, что отказывается MS говорит лишь одно — ни асилили.

Вот в это совсем не верю. Осилили бы. если бы надо было.

PD>>Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ?
DOO>Для персоналок? Это как бы не для персоналок...

Это как бы в свое время позиционировалось как идущее на смену x86... Во всяком случае, когда о нем начали говорить, x64 не было и в помине и Intel не собиралась его делать, так что переход на 64-битные процессоры означал переход на Итаниум.

Здравствуйте, squid, Вы писали:

S>x86 столь ужасна?

В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть. Соответственно, в 21 веке компилируют программы в машинный код i386.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Фактически можно про эту архитектуру забыть, по крайней мере тем, кто ориентируется на продукты от MS. Покупать машины на базе Итаниум эти люди и организации больше не будут.

DOO>>Павел. Ей-богу, смешно.
DOO>>Весь мир HPC построен на итаниумах — вся линейка HP Integrity, например. Вплоть до Superdome. Если бы HP сказали, что они отказываются от итаниумов в этой линейке — это было бы да.
PD>Ну я же ясно объяснил, в каком контексте. См. выше.
Если есть потребность в HPC, то личные предпочтения по софту отойдут на второй план. К тому же, для бизнеса есть готовые решения в лице СУБД (не будем говорить каких, на начинается на O, а кончается на e), которые прекрасно себя чувствуют на таких машинах под управлением всякой экзотики.

DOO>>А то, что отказывается MS говорит лишь одно — ни асилили.
PD>Вот в это совсем не верю. Осилили бы. если бы надо было.
Нет. Сложно лезть на рынок с невысокой динамикой, где все предпочтения сформировались лет дцать назад.
В конце-концов, чтобы вышибать оттуда лидеров надо, например, научится поддерживать NUMA архитектуры, транспьютерные системы, использовать фичи типа MPI и т.п.

PD>>>Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ?
DOO>>Для персоналок? Это как бы не для персоналок...
PD>Это как бы в свое время позиционировалось как идущее на смену x86... Во всяком случае, когда о нем начали говорить, x64 не было и в помине и Intel не собиралась его делать, так что переход на 64-битные процессоры означал переход на Итаниум.
Ну хз. Смелое было заявление

Здравствуйте, Roman Odaisky, Вы писали:

RO>В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть.

Это на каких процессорах сейчас нет MMX и SSE ? 3DNow — может быть.

Здравствуйте, Roman Odaisky, Вы писали:

RO>В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть. Соответственно, в 21 веке компилируют программы в машинный код i386.
Это где так?
в том же ICC стандартные либы собраны под SSE2 минимум.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Это где так?
CC>в том же ICC стандартные либы собраны под SSE2 минимум.

И даже VC++ умеет их генерировать сам, а кроме того, содержит кучу intrinsic для их вызова вручную.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это на каких процессорах сейчас нет MMX и SSE ? 3DNow — может быть.

SSE2 нет на многих еще используемых, SS3 нет на большинстве используемых.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Это на каких процессорах сейчас нет MMX и SSE ? 3DNow — может быть.

V>SSE2 нет на многих еще используемых, SS3 нет на большинстве используемых.

Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?

Вот представь себе, что ты собираешь ядро ОС. Компилируешь с -msse3? А с -msse2?

Здравствуйте, Roman Odaisky, Вы писали:

PD>>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?

RO>Вот представь себе, что ты собираешь ядро ОС. Компилируешь с -msse3? А с -msse2?

При чем тут ядро ?

Здравствуйте, Шахтер, Вы писали:

Ш>Приличный C++ компилятор Майкрософт так и не смог написать.

А какие компиляторы считаются самыми "приличными"?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Вопрос звучал так: «x86 столь ужасна?» — да, она ужасна тем, что значительная часть ключевых программ для этой архитектуры собирается без использования современных наборов инструкций. В том числе и ядро ОС, зачастую.

Вопрос «x86 столь ужасна?» задал отнюдь не я, а squid, и я не это его сообщение не отвечал, ответил ты. Я не телепат, чтобы пытаться понять, о чем ты говоришь.

Что касается ядра... Я не знаю, используется ли там SSE, и не уверен , что это надо. Но никаких проблем я тут не вижу. Компилятор VC делать SSE коды умеет, ну а то, что ядро существует в дистрибутиве по крайней мере в двух вариантах (для одно и многопроцессорной машины) ты, наверное, в курсе. Ничего не мешало бы иметь в дистрибутиве варианты ядра с SSE2 и c SSE3, если бы это было нужно.

Приветствую, Roman Odaisky, вы писали:

RO> Вот представь себе, что ты собираешь ядро ОС. Компилируешь с -msse3? А с -msse2?
Этим занимается сборщик ядра. В конфигураторе просто выбираешь какой у тебя процессор и все. Нужные флаги компилятору добавятся. Ну и еще полезно снять флажок "Generic x86"

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?

А что делать с топовыми компами, выпущенными более 3-х лет назад? Это отличные рабочие лошадки, с чего бы их на помойку?

Здравствуйте, Sheridan, Вы писали:

S>Компы уже давно, лет десять как превышают потребности этак порядка на два-три.
Смотря в каких задачах.
Ну нельзя же так огульно заявлять сразу обо всем.

Приветствую, sndanil, вы писали:

s> Full HD Video? Crysis (и еще целая куча игрушек)?
Так и запишем: для развлечений.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

RO>> Вот представь себе, что ты собираешь ядро ОС. Компилируешь с -msse3? А с -msse2?
S>Этим занимается сборщик ядра. В конфигураторе просто выбираешь какой у тебя процессор и все. Нужные флаги компилятору добавятся. Ну и еще полезно снять флажок "Generic x86"
это только если компилятор в курсе где какие инструкции

Приветствую, Antikrot, вы писали:

A> это только если компилятор в курсе где какие инструкции

Ну gcc какбэ в курсе.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

s>> Full HD Video? Crysis (и еще целая куча игрушек)?
S>Так и запишем: для развлечений.

а ты что ожидал в списке задач обычного юзера? научные расчеты?

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, CreatorCray, вы писали:

CC>> Про SSE2 вообще молчу. Его не держат разве что уже крайне устаревшие процы (до P4 / PM).
S>Охо. А что ты скажешь на предмет того, что в том-же ПФР еще очень даже пашут компы этак Целерон-950?
Скажу что мне плевать. Узкие области это очень специальная тема.
Для некоторых моих задач сегодняшнего железа всё ещё маловато.

В mainstream же SSE2 можно считать абсолютным минимумом.

S>Я вообще не понимаю этой гонки мощностей. Компы уже давно, лет десять как превышают потребности этак порядка на два-три.
Чьи потребности? Я не откажусь от более мощного железа никогда.

S> Разве что для криворуких программистов, которые не умеют писать на нормальных, компилируемых языках, и которые отмаиваются "...тормозит?
C++ вполне кошерен?

И тем не менее железо всё еще слабовато для некоторого круга интересующих меня задач.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, sndanil, Вы писали:

T>>Попробуем с другой стороны

Для каких задач обычного юзера не хватало процессоров 10-летней давности?

S>Full HD Video? Crysis (и еще целая куча игрушек)?

Для игрушек никогда не хватит, на то они и игрушки. Для видео — тоже понятно. Давай что-нибудь из более деловой сферы.

Здравствуйте, squid, Вы писали:

S>И? Развлечения — одна из важнейших сторон жизни. Чо тебе не нравиццо? Я вот не представляю симпатичных приложение Adobe AIR / WPF на древних компах. 3D в интернете тоже не представляю. Компы 10-ти летней давности вообще мало чего умели что реально нужно сейчас. Без HD видео — жизни нет!

А я вполне представляю себе большинство сайтов на компьютерах 2000 года. Кстати, они тогда и были. И как тогда к ним было 100 обращений в сутки, так и сейчас.

Здравствуйте, LuciferSaratov, Вы писали:

LS>Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

Совершенно верно. Но, как ни странно, 10 лет назад не очень тормозил. И рендеринг и скрипт. Вполне работало.

Здравствуйте, Pavel Dvorkin, Вы писали:

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, DOOM, Вы писали:

V>>>А что делать с топовыми компами, выпущенными более 3-х лет назад? Это отличные рабочие лошадки, с чего бы их на помойку?

S>>Топовые компы старее Pentium 4? А эти "топовые компы" не протухли еще?
DOO>А сколько по-твоему длится жизнь среднестатистического компа на каком-нибудь предприятии?
А как часто ставится новый тяжёлый софт на эти компы? АРМ какой нибудь например.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А я вполне представляю себе большинство сайтов на компьютерах 2000 года. Кстати, они тогда и были. И как тогда к ним было 100 обращений в сутки, так и сейчас.

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

S>Но дело не в этом. Дело в расслабляющихся в лучах мощностей программистов, которые прикрывают свой расслабон чемто типа "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу".

Ты вообще в курсе, что те же видеокодеки написаны на... как там у тебя...

на нормальных, компилируемых языках

То же относится и к играм.

Здравствуйте, Mamut, Вы писали:

M>То же относится и к играм.
С натяжкой

Смотря о каком куске игры речь.

Да и писатель пейсателю рознь... Одно дело ребята из Valve с их Source engine, другое какие-нибудь м..ки из авторского коллектива первого хитмана.

M>>То же относится и к играм.
DOO>С натяжкой

DOO>Смотря о каком куске игры речь.

DOO>Да и писатель пейсателю рознь... Одно дело ребята из Valve с их Source engine, другое какие-нибудь м..ки из авторского коллектива первого хитмана.

Естественно. Говнокодеров полно, вне зависимости от языка программирования (этот факт Шеридан не понимает абсолютно). Но при этом тот же Source на компе 10-летней давности не пойдет, как ни пытайся

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Беда в том, что нынешние системы их на это провоцируют.
А открытое окно так и провоцирует в него выпрыгнуть.
Дело в субстанции в черепе конкретного кодера а не в "провоцировании".
Нормальных девелоперов почему то не провоцирует.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Torie, Вы писали:

CC>>Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.
T>Раньше сама идея делать сложный функционал на скриптовом языке была бы немедленно закидана тухлыми помидорами.
Патамушта аццки тормозило.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Дело в субстанции в черепе конкретного кодера а не в "провоцировании".
CC>Нормальных девелоперов почему то не провоцирует.
А что такое "нормальный девелопер"? Кодер будет делать так, как ему велено. Сказано реализовать за 3 дня, чтоб работало чисто по требованиям и не более того — он реализует, но не будет оттачивать алгоритмы и т.п. Скажут писать VBA — будет писать как миленький, куда денется-то?

Просто разработчику (на уровне руководства) куда приятнее переложить расходы на потребителя — заодно и производителей железа это только порадует...

Здравствуйте, CreatorCray, Вы писали:

CC>А открытое окно так и провоцирует в него выпрыгнуть.
CC>Дело в субстанции в черепе конкретного кодера а не в "провоцировании".
CC>Нормальных девелоперов почему то не провоцирует.

И нормальных тоже. Посмотри мою дискуссию с IT.

http://rsdn.ru/forum/education/2813653.1.aspx

Здравствуйте, squid, Вы писали:

S>Я имел в виду нормальные популярные сайты а не всякое малопосещаемое гавно.

Что-то мне сдается, что если бы на свете были только нормальные популярные сайты, а а не всякое малопосещаемое ..., то на свете сайтов было бы на пару порядков меньше...

Сайт какого-нибудь областного театра — это как ? Турфирмы ? Городского магазина ? Вуза ? И т.д. И т.п.

Здравствуйте, DOOM, Вы писали:

CC>>Дело в субстанции в черепе конкретного кодера а не в "провоцировании".
CC>>Нормальных девелоперов почему то не провоцирует.
DOO>А что такое "нормальный девелопер"? Кодер будет делать так, как ему велено. Сказано реализовать за 3 дня, чтоб работало чисто по требованиям и не более того — он реализует, но не будет оттачивать алгоритмы и т.п. Скажут писать VBA — будет писать как миленький, куда денется-то?
Есть кодер а есть девелопер. Разница в мозгах.
Девелопер понимает последствия своих решений и оценивает варианты решения задачи с разных критериев. Кодер — не парится всей этой чухнёй и лепит как ему будет проще.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

CC>>А открытое окно так и провоцирует в него выпрыгнуть.
CC>>Дело в субстанции в черепе конкретного кодера а не в "провоцировании".
CC>>Нормальных девелоперов почему то не провоцирует.

PD>И нормальных тоже. Посмотри мою дискуссию с IT.
Если девелоперу настолько всё пофигу, что он пользуется говнокодом, то это означает что он сам деградирует в говнокодера.
Так что нормальных девелоперов это всё таки не провоцирует. Неиспользование говнокода как раз один из критериев нормальности.
Как только появляется "да насрать что весь файл грузим в память, зато так проще" в production code — это уже не нормальный девелопер.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, LuciferSaratov, Вы писали:

LS>>Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

PD>Совершенно верно. Но, как ни странно, 10 лет назад не очень тормозил. И рендеринг и скрипт. Вполне работало.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Если девелоперу настолько всё пофигу, что он пользуется говнокодом, то это означает что он сам деградирует в говнокодера.
CC>Так что нормальных девелоперов это всё таки не провоцирует. Неиспользование говнокода как раз один из критериев нормальности.
CC>Как только появляется "да насрать что весь файл грузим в память, зато так проще" в production code — это уже не нормальный девелопер.

Если бы все так просто... Если бы человек сам все писал. А то ведь используем чей-то код, а он черт знает как написан. А сам фреймворк — не черт те как порой ?

Вот тебе пример. См. там про ppt-файлы

http://rsdn.ru/forum/philosophy/3722127.1.aspx

Приветствую, CreatorCray, вы писали:

CC> CC>> С или С++ достаточно кошерный язык?
CC> S>Дадада. Нада 2 кнопки: 0 и 1
CC> Т.е. если пишут не в машинных кода — для тебя это будет "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу"?
CC> S> Ах даааа... Каааак я мог забыть. Потоки же труднее программировать — студентов уже не посадишь за клавиатуру, придется более опытных сажать и более больше им платить. Ну просто уму непостижимо, да?
CC> Бред. Даже комментировать не стану.
Сарказма не замечаем

Ладно. Скажу проще:
1. Не надо вдаваться в крайности.
2. Чтобы писать более правильный код — нужны более опытные программеры. А более опытным программерам надо более мнеого платить.

CC> S>Ей богу, уж если и гнать "вооружения", то в сторону параллельных вычислений с кучей cpu на кристалле.
CC> Так они сейчас в эту сторону и так развиваются. По скорости одного ядра уже упёрлись в границу, выше которой подымать частоты уже нерационально.
Ясен пень, они просто вынуждены уходить в сторону многоядерности.

CC> И пусть развиваются. И для проца в 80 ядер найдётся чем его нагрузить.
Я смогу найти и чем стотыщпицот ядер загрузить. Только вот это единичные случаи.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, CreatorCray, вы писали:

CC> Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.

thebat, kmail — про них уже както забыли наверное?

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, LuciferSaratov, Вы писали:

LS>Например, веб-интерфейс уровня gmail вряд ли был возможен 10 лет назад с приемлемой производительностью.

Гм...

http://msdn.microsoft.com/en-us/default.aspx — 2010 год

http://web.archive.org/web/20030122100414/http://www.msdn.microsoft.com/ — 2003 год.

http://mail.ru/ 2010 год.
http://web.archive.org/web/20020201163224/mail.ru/cgi-bin/splash?noenter — 2002 год

с gmail не получается — кроме стартовой страницы там ничего не сохранено.

Здравствуйте, Шахтер, Вы писали:

Ш>Приличный C++ компилятор Майкрософт так и не смог написать.

А это аргумент, чтобы отказаться от поддержки W200x сервера и MS_SQL ? Можно и на чужом компиляторе откомпилировать... Oracle вроде как вообще свои компиляторы не пишет.

Здравствуйте, Sheridan, Вы писали:

S>thebat, kmail — про них уже както забыли наверное?
Ну вот дома у меня стоит thebat, а вот если мне надо с работы личной почтой попользоваться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Есть кодер а есть девелопер. Разница в мозгах.
CC>Девелопер понимает последствия своих решений и оценивает варианты решения задачи с разных критериев. Кодер — не парится всей этой чухнёй и лепит как ему будет проще.
Девелопер также будет делать, что велено. Либо начальством, либо "невидимой рукой рынка". Не надо тут образ благородного рыцаря создавать.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И ? Тормозило потому, что использовали тормозную систему (не то компилятор, не то интерпретатор, не то черт знает что).

JavaScript — самый обычный интерпретатор, даже не JIT. То есть тормознее просто некуда.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я что-то вообще перестал понимать, что мы тут обсуждаем. Сделать ПО, которое использует или не использует тот или иной набор инструкций, вроде как не такая уж большая проблема...

На сегодня это означает 3 бинарника вместо одного.

CC>> Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.

S>thebat, kmail — про них уже както забыли наверное?

Если бы они хоть один предоставляли все, что надо... Помнится, я когда-то об этом писал, http://rsdn.ru/forum/usability/3256420.aspx GMail, кстати, тоже не панацея

Здравствуйте, CreatorCray, Вы писали:

S>>thebat, kmail — про них уже както забыли наверное?
CC>Ну вот дома у меня стоит thebat, а вот если мне надо с работы личной почтой попользоваться?
Чтобы воспользоваться с работы личной почтой достаточно простого, почти статического интерфейса без мегабайта тормозных скриптов.

Здравствуйте, vdimas, Вы писали:

V>На сегодня это означает 3 бинарника вместо одного.

Или один бинарник и несколько вариантов DLL, в которую и вынесено все, что depends. При инсталляциии поставится та, что нужно. Примерно так же , как с локализацией, например.

Здравствуйте, quwy, Вы писали:

LS>>Например, веб-интерфейс уровня gmail вряд ли был возможен 10 лет назад с приемлемой производительностью.
Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.

Это уже другой вопрос.

PD>>>И ? Тормозило потому, что использовали тормозную систему (не то компилятор, не то интерпретатор, не то черт знает что).
T>>JavaScript — самый обычный интерпретатор, даже не JIT. То есть тормознее просто некуда.
Q>SWF, кстати, тоже. Насколько я помню, он декомпилируется вместе с именами идентификаторов и комментариями. А если вспомнить еще PHP то легко поставить диагноз: весь УЁБ 2.0 поражен вирусом запредельных тормозов, так сказать, by design. Сервера и клиенты 90% процессорного времени тратят не на полезную работу, а хрен знает на что. А ведь даже сегодня ВСЕ можно сделать нормально, просто взять и сделать.

Действительно. Просто взять и сделать. Причем, все. Осталось только определиться — на чем делать-то будем?

Здравствуйте, CreatorCray, Вы писали:

CC> LS>> Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

CC> S>Гы, ясен хер. Сам поймешь почему так?

CC> Потому как контент сейчас стал более тяжёлым, т.к. железо позволяет.
CC> Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.

Помнится мне, во времена DOS'а на i386 20/40MHz, игрушка была навроде спектрумовской A.B.U.S.E. (2D аркада). Я в ее файлах (картинки и прочее) ковырялся на предмет изучения. Так вот у нее вся игровая логика была написана на каком-то страшном скриптовом языке. Собственно, отличий между дерганием из скриптов нативного кода, для игрушки и браузера, в глаза не бросается

Скорее видится другое, а именно скромный функционал самих браузеров и предоставляемый скриптам API (вроде DOM, XMLRequest и подобных).

avalon 1.0rc2 rev 272

LS>>>>Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.
PD>>>Совершенно верно. Но, как ни странно, 10 лет назад не очень тормозил. И рендеринг и скрипт. Вполне работало.
LS>>Это потому, что тогда и сайты делали с учетом имеющихся мощностей.
LS>>Например, веб-интерфейс уровня gmail вряд ли был возможен 10 лет назад с приемлемой производительностью.
Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.

Ну, не скажи. Threading и поиск по почте как рулили, так и рулят.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если бы все так просто... Если бы человек сам все писал. А то ведь используем чей-то код, а он черт знает как написан.
Ну дык смотреть надо что используешь.
Понятно что народ тупо верит что в FW не может быть говнокода ибо "от создателей Титаника^W С#"

. А он там есть!

PD>А сам фреймворк — не черт те как порой ?
.NET FW изрядно погрызен усеницами, да.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, hattab, Вы писали:

H>Помнится мне, во времена DOS'а на i386 20/40MHz, игрушка была навроде спектрумовской A.B.U.S.E. (2D аркада). Я в ее файлах (картинки и прочее) ковырялся на предмет изучения. Так вот у нее вся игровая логика была написана на каком-то страшном скриптовом языке.

Дык даже в те времена активно использовалось понятие "движка". В том числе виртуальных машин (Scum Vm). Для abuse есть OS реализация движка, на который можно накатить оригинальные data файлы.

Здравствуйте, quwy, Вы писали:

Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.

gmail мне нравится, удобный.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, CreatorCray, Вы писали:

CC>>Есть кодер а есть девелопер. Разница в мозгах.
CC>>Девелопер понимает последствия своих решений и оценивает варианты решения задачи с разных критериев. Кодер — не парится всей этой чухнёй и лепит как ему будет проще.
DOO>Девелопер также будет делать, что велено. Либо начальством, либо "невидимой рукой рынка". Не надо тут образ благородного рыцаря создавать.
Драсте. Тебе что, в тасках указывается какими алгоритмами пользоваться, какие контейнеры использовать и т.п.?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, quwy, Вы писали:

S>>>thebat, kmail — про них уже както забыли наверное?
CC>>Ну вот дома у меня стоит thebat, а вот если мне надо с работы личной почтой попользоваться?
Q>Чтобы воспользоваться с работы личной почтой достаточно простого, почти статического интерфейса без мегабайта тормозных скриптов.
Это зависит от того, что тебе в почте надо сделать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Ну дык смотреть надо что используешь.

Угу. С помощью каких-то странных телодвижений получать во время отладки страницы исходников дотнета одна за одной по Интернету. Я такого больше нигде не видел. MFC, QT, Delphi, Java , да и просто C/C++ RTL/STL — все исходники открыты и поставляются вместе с продуктом.

А впрочем, не в этом дело. Не могу же я каждый раз, собираясь применить некий метод, начать изучать его внутренности. А доверять ему ... Что хорошо в RTL C — ее десятки раз обгрызли и реализацию всех функций, для которых производительность хоть рядом лежала, обсудили тоже десятки раз.

Здравствуйте, Pavel Dvorkin, Вы писали:

CC>>Ну дык смотреть надо что используешь.
PD>Угу. С помощью каких-то странных телодвижений получать во время отладки страницы исходников дотнета одна за одной по Интернету. Я такого больше нигде не видел. MFC, QT, Delphi, Java , да и просто C/C++ RTL/STL — все исходники открыты и поставляются вместе с продуктом.
Наши рефлектором там лазили. После профилирования.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Mamut, Вы писали:

M> Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.

M> Ну, не скажи. Threading и поиск по почте как рулили, так и рулят.

Пользователи Opera зевают...

avalon 1.0rc2 rev 272

Здравствуйте, CreatorCray, Вы писали:

PD>>Угу. С помощью каких-то странных телодвижений получать во время отладки страницы исходников дотнета одна за одной по Интернету. Я такого больше нигде не видел. MFC, QT, Delphi, Java , да и просто C/C++ RTL/STL — все исходники открыты и поставляются вместе с продуктом.
CC>Наши рефлектором там лазили. После профилирования.

Я о нем не забыл, конечно. Спасибо автору за него, что бы мы иначе делали вообще...

Здравствуйте, DOOM, Вы писали:

DOO>Скажем так — если я ставлю задачу инженеру поставить винду на сервер, то я ожидаю, что он ее решит в лоб — взяв диск и поставив и не будет умничать с PXE, RAD и тому подобными продвинутыми, но в данной ситуации не нужными технологиями.
Это крайне примитивный таск. На уровне "прочитать бинарный файл в память".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, neFormal, Вы писали:

F>эм, а что в первом "Хитмане" было плохо?. у меня ни одного нарекания даже не возникало..
шибко тормозной он был для того уровня графики и возможностей движка. Просто нереально тормозной.

M>> Q>Самое главное, что он как был нахрен не нужным для работы тогда, так и остался таковым сегодня. Сплошные свистелки и перделки.

M>> Ну, не скажи. Threading и поиск по почте как рулили, так и рулят.

H>Пользователи Opera зевают...

Всем известно, что главное быть не первооткрывателем, а толкателем идей.

Здравствуйте, DOOM, Вы писали:

F>>эм, а что в первом "Хитмане" было плохо?. у меня ни одного нарекания даже не возникало..
DOO>шибко тормозной он был для того уровня графики и возможностей движка. Просто нереально тормозной.

ну хз.. играл тогда на машинках типа 800-1000МГц со 128Мб ОП и 32Мб видео, тормозов не видел..

M>>Действительно. Просто взять и сделать. Причем, все. Осталось только определиться — на чем делать-то будем?

T>Уже есть Silverlight. Это конечно не идеал, но хороший шаг вперед. Надеюсь, он наконец убьет всё это аяксовебобезумие.

Не убьет — это во=первых. Так же тормозит и требует ресурсов — это во-вторых

Здравствуйте, Mamut, Вы писали:

M>Для того, чтобы пользоваться этой функциональностью, надо было иметь одинаково настроенные системы на всех компах, за которыми ты работал (как минимум, одну на работе, одну дома).
Ну вот браузер у меня сейчас как раз так и работает.

Согласись, что выносить в сеть профили настроек логичнее, чем ПО целиком

Здравствуйте, Mamut, Вы писали:

M>Не убьет — это во=первых.

Может и не убьет. Но хорошо бы, чтобы убил

M>Так же тормозит и требует ресурсов — это во-вторых

Далеко не так же. Интерпретатор и JIT-компилятор — это совсем разный уровень.

M>>Не убьет — это во=первых.
T>Может и не убьет. Но хорошо бы, чтобы убил

Чем хорошо?

M>>Так же тормозит и требует ресурсов — это во-вторых

T>Далеко не так же. Интерпретатор и JIT-компилятор — это совсем разный уровень.

Мнэээ. И? HTML с минимум скриптов может оказаться менее ресурсоемким и менее тормозным, чем аналогичный сайт на Silverlight'е. GMail — это, конечно, экстрим, но где гарантия, что аналог на Silverlight'е будет лучше по производительности?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Что-то мне сдается, что если бы на свете были только нормальные популярные сайты, а а не всякое малопосещаемое ..., то на свете сайтов было бы на пару порядков меньше...

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

PD>Сайт какого-нибудь областного театра — это как ? Турфирмы ? Городского магазина ? Вуза ? И т.д. И т.п.

Посещаемость сайта ВУЗа — в разы больше, турфирмы тоже. Городской магазин — не знаю таких сайтов. Торговых сетей да, одного маленького неспециализированного — ни разу не видел.

Здравствуйте, DOOM, Вы писали:

DOO>шибко тормозной он был для того уровня графики и возможностей движка. Просто нереально тормозной.

моему восприятию игры графика не мешала.

Здравствуйте, vdimas, Вы писали:

V>Че-то ты заблудился во времени, Пентиум-4 вышел ровно 10 лет назад, а не 3.

Я не заблудился, я про Pentium 4 + SSE2 писал если чо. Время роли не играет.

Здравствуйте, squid, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Что-то мне сдается, что если бы на свете были только нормальные популярные сайты, а а не всякое малопосещаемое ..., то на свете сайтов было бы на пару порядков меньше...

S>а зачем нужны такие сайты? хочешь домашныюю страничку — фэйсбук в помощь.

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

PD>>Сайт какого-нибудь областного театра — это как ? Турфирмы ? Городского магазина ? Вуза ? И т.д. И т.п.

S>Посещаемость сайта ВУЗа — в разы больше

Больше чего ? Областного театра ? Наверное, да.

>турфирмы тоже.
>Городской магазин — не знаю таких сайтов. Торговых сетей да, одного маленького неспециализированного — ни разу не видел.

Ну пусть торговых сетей и их магазинов.

Здравствуйте, CreatorCray, Вы писали:

DOO>>А сколько по-твоему длится жизнь среднестатистического компа на каком-нибудь предприятии?
CC>А как часто ставится новый тяжёлый софт на эти компы? АРМ какой нибудь например.

Речь не о тяжелом софте, а о совместимом с поддерживаемым набором инструкций.

Здравствуйте, squid, Вы писали:

S>Я не заблудился, я про Pentium 4 + SSE2 писал если чо. Время роли не играет.

Ну а в шустрых процах от АМД того времени никакого SSE2 не было. А производительность 3200+, зачем же его на мусорку?

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я их, что ли заказывал ? Раз заказывали и платили — значит, нужны. И, возможно, сделаны кем-то из наших коллег здесь. Я тоже делал немного, правда, не для России.

Кто сказал что маленькие сайты кто-то заказывает?

PD>Ну пусть торговых сетей и их магазинов.

Сайт мВидео — маленький сайт с сотней посещений? Ты себе постоянно противоречишь.

Здравствуйте, vdimas, Вы писали:

V>Ну а в шустрых процах от АМД того времени никакого SSE2 не было. А производительность 3200+, зачем же его на мусорку?

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

Я с этим спорю? Если есть задачи — можно и не на свалку

Здравствуйте, Sheridan, Вы писали:

A>> это только если компилятор в курсе где какие инструкции
S>Ну gcc какбэ в курсе.
угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX

Здравствуйте, Sheridan, Вы писали:

CC>> С или С++ достаточно кошерный язык?
S>Дадада. Нада 2 кнопки: 0 и 1
любой телеграфист тебе расскажет, что достаточно одной кнопки

Здравствуйте, Sheridan, Вы писали:

CC>> S> Ах даааа... Каааак я мог забыть. Потоки же труднее программировать — студентов уже не посадишь за клавиатуру, придется более опытных сажать и более больше им платить. Ну просто уму непостижимо, да?
CC>> Бред. Даже комментировать не стану.
S>Сарказма не замечаем

S>Ладно. Скажу проще:
S>1. Не надо вдаваться в крайности.
S>2. Чтобы писать более правильный код — нужны более опытные программеры. А более опытным программерам надо более мнеого платить.
не надо вдаваться в то, чего не знаешь

CC>> S>Ей богу, уж если и гнать "вооружения", то в сторону параллельных вычислений с кучей cpu на кристалле.
CC>> Так они сейчас в эту сторону и так развиваются. По скорости одного ядра уже упёрлись в границу, выше которой подымать частоты уже нерационально.
S>Ясен пень, они просто вынуждены уходить в сторону многоядерности.
пень не ясен. у тебя уже есть масштабируемые алгоритмы для всего-всего?

CC>> И пусть развиваются. И для проца в 80 ядер найдётся чем его нагрузить.
S>Я смогу найти и чем стотыщпицот ядер загрузить. Только вот это единичные случаи.
zeus?

Здравствуйте, CreatorCray, Вы писали:

S>>>Но дело не в этом. Дело в расслабляющихся в лучах мощностей программистов, которые прикрывают свой расслабон чемто типа "в тормозах моего софта виноват ваш комп, а не то как и на чем я пишу".
M>>Ты вообще в курсе, что те же видеокодеки написаны на... как там у тебя...
M>>

M>>на нормальных, компилируемых языках

CC>Тот же CoreAVC вообще ассемблерные вставки использует.
а какой нормальный кодек их не использует?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хм... Про SSE3 FreshDiagnose что-то вообще молчит, а вот про SSE2 он говорит о его пристутствии на моем 3-летней давности Athlon 4200+. Это по крайней мере дает основания предполагать о его наличии у всех AMD процессоров, выпущенных в последние 3 года. Где его нет, на Интеле ?
V>А что делать с топовыми компами, выпущенными более 3-х лет назад? Это отличные рабочие лошадки, с чего бы их на помойку?

Чет ты загнул, в моем "топовый" компе, купленном как раз три года назад, стоит Core2Duo.
В предыдущем "топовом" компе, купленным до этого в году 2004 — стоял P4 Prescott.
В предыдущем "топовом" компе, купленном еще года за три до этого, стоял P4 Northwood.

Что интересно — означенный набор инструкций есть во всех этих процессорах, причем P4 я бы не назвал сейчас "отличной рабочей лошадкой".

Может, ты ноликом ошибся?

Здравствуйте, Sheridan, Вы писали:

T>> Чертовски странная у тебя логика. 99% прог сделаны на C++ и C, а виноваты почему-то программисты "которые не умеют писать на компилируемых языках"
S>те что написаны на ц++ и ц — вполне себе пашут. А как только начинаются всякие дотнеты с питонами — сразу тормоза. Парадокс?
Ц++ и в меньшей степени Ц — г-но с точки зрения столь тебе приглянувшегося распараллеливания на хрен знает сколько ядер.

Приветствую, Antikrot, вы писали:

A> S>1. Не надо вдаваться в крайности.
A> S>2. Чтобы писать более правильный код — нужны более опытные программеры. А более опытным программерам надо более мнеого платить.
A> не надо вдаваться в то, чего не знаешь

Что, за живое задеваю?

A> S>Ясен пень, они просто вынуждены уходить в сторону многоядерности.
A> пень не ясен. у тебя уже есть масштабируемые алгоритмы для всего-всего?
Они обязательно уже должны быть? Вдобавок еще и у меня?
Дядь, а можно они будут не у меня, а их просто напишут более опытные программисты, а?

A> S>Я смогу найти и чем стотыщпицот ядер загрузить. Только вот это единичные случаи.
A> zeus?

boinc

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, Antikrot, вы писали:

A> S>Дадада. Нада 2 кнопки: 0 и 1
A> любой телеграфист тебе расскажет, что достаточно одной кнопки

Я уже и не надеялся....

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

A>> S>1. Не надо вдаваться в крайности.
A>> S>2. Чтобы писать более правильный код — нужны более опытные программеры. А более опытным программерам надо более мнеого платить.
A>> не надо вдаваться в то, чего не знаешь
S>Что, за живое задеваю?
нет, просто ты полез в параллельные вычисления, и даже по твоему "можно они будут не у меня" ясно что они тебе действительно параллельны

A>> S>Ясен пень, они просто вынуждены уходить в сторону многоядерности.
A>> пень не ясен. у тебя уже есть масштабируемые алгоритмы для всего-всего?
S>Они обязательно уже должны быть? Вдобавок еще и у меня?
S>Дядь, а можно они будут не у меня, а их просто напишут более опытные программисты, а?
может тебе более опытные программисты еще и проблемы Гильберта по-быстрому порешают, а?
ты же сравниваешь плюсовое говнокодерство и серьёзные математические проблемы.

Приветствую, Antikrot, вы писали:

A> A>> это только если компилятор в курсе где какие инструкции
A> S>Ну gcc какбэ в курсе.
A> угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
Следует ли понимать то, что ты об этом знаешь? Ну так просвяти меня, а то я знаю только что все эти 5 sse добавили в общей сложности около 250 комманд. Сдвиги, перемешивания, умножения, работа с векторами, с множеством чисел за раз, комманды работы с кешем итд. Ах да, в sse4.1 есть еще комманды работы со строками (PCMPESTRI, PCMPESTRM, PCMPISTRI, PCMPISTRM) и подсчет crc32.
Ну так как, просвятишь меня, что из этого не будет использоваться?

Хотя можешь этого не делать. Я не парюсь и просто выбираю тип процессора в конфигураторе. Мне это совсем несложно. Будет польза — замечательно. Не будет пользы — ну и хрен с ней. Но вот в чем дело, пойми. Если польза будет (а она есть, попробуй завести систему на generic x86 ядре и потом на ядре собраном под процессор), то она будет у меня, потому как я не поленился потратить 10 секунд жизни на выбор типа процессора.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, Antikrot, вы писали:

A> Ц++ и в меньшей степени Ц — г-но с точки зрения столь тебе приглянувшегося распараллеливания на хрен знает сколько ядер.

Серебрянной пули нет.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

A>> A>> это только если компилятор в курсе где какие инструкции
A>> S>Ну gcc какбэ в курсе.
A>> угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
S>Следует ли понимать то, что ты об этом знаешь? Ну так просвяти меня, а то я знаю только что все эти 5 sse добавили в общей сложности около 250 комманд. Сдвиги, перемешивания, умножения, работа с векторами, с множеством чисел за раз, комманды работы с кешем итд. Ах да, в sse4.1 есть еще комманды работы со строками (PCMPESTRI, PCMPESTRM, PCMPISTRI, PCMPISTRM) и подсчет crc32.
да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел?

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

S>Хотя можешь этого не делать. Я не парюсь и просто выбираю тип процессора в конфигураторе. Мне это совсем несложно. Будет польза — замечательно. Не будет пользы — ну и хрен с ней. Но вот в чем дело, пойми. Если польза будет (а она есть, попробуй завести систему на generic x86 ядре и потом на ядре собраном под процессор), то она будет у меня, потому как я не поленился потратить 10 секунд жизни на выбор типа процессора.
И это говорит человек, который требует от других знать как ОС работает внутри

Здравствуйте, Sheridan, Вы писали:

A>> Ц++ и в меньшей степени Ц — г-но с точки зрения столь тебе приглянувшегося распараллеливания на хрен знает сколько ядер.
S>Серебрянной пули нет.
ты не совсем понял. Ц++ тут чуть ли не худший вариант.

Приветствую, Antikrot, вы писали:

A> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел?
Про криптоапи забыл?

A> думаю не сильно ошибусь, если скажу что практически ничего. то что там используется в системной части с управлением кэшированием, быстрыми вызовами и прочим на асме прописано руками. но если надо, могу собрать ядро с нужными опциями и проверить где там тобой перечисленное.
Это уже интереснее. Давай.

A> S>Хотя можешь этого не делать. Я не парюсь и просто выбираю тип процессора в конфигураторе. Мне это совсем несложно.
A> И это говорит человек, который требует от других знать как ОС работает внутри

Кстати, выбор в конфигураторе таки влияет, но sse тут не причём.
Ну так расскажи мне, что там при чем, а я послушаю.

A>Кроме того — а ты точно уверен, что оно не будет *медленнее*?

Я несколько раз наблюдал увеличение производительности и ни разу — снижения.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Pavel Dvorkin, Вы писали:

DOO>>>>А то, что отказывается MS говорит лишь одно — ни асилили.
PD>>>Вот в это совсем не верю. Осилили бы. если бы надо было.
Ш>>Приличный C++ компилятор Майкрософт так и не смог написать.
PD>А это аргумент, чтобы отказаться от поддержки W200x сервера и MS_SQL ? Можно и на чужом компиляторе откомпилировать... Oracle вроде как вообще свои компиляторы не пишет.

Сдается мне, это был пример того, что не все МС может осилить.

Или, с другой стороны, что не все им настолько надо, чтобы действительно осилить любой ценой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, vdimas, Вы писали:

V>На сегодня это означает 3 бинарника вместо одного.

Или .NET/Java

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, neFormal, Вы писали:

F>>эм, а что в первом "Хитмане" было плохо?. у меня ни одного нарекания даже не возникало..
DOO>шибко тормозной он был для того уровня графики и возможностей движка. Просто нереально тормозной.

Там было много интересных фишек.
Скелетная анимация моделей человека с плавными переходами между фазами (сама анимация явно была сделана при помощи motion capture, очень естественно выглядело).
Ragdoll — трупы падали, катились по лестницам и повисали на перилах по всем законам физики. Собствено, не только трупы — мусорные баки катились тоже правильно, всякие занавески трепыхались как надо.
Реверсивная кинематика — когда персонажу даешь команду нажать на кнопку, он протягивает руку и нажимает на кнопку. Подбирает оружие с пола — наклоняется и берет рукой, все как положено.
Динамические тени — тогда немногие игры могли этим похвастаться.
Для игры 2000 года — по моему, неплохо. Возможно, это могло работать быстрее, но все же там было, чему тормозить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Грубо говоря, может у тебя железо до требований не дотягивало?
Меня не волнуют требования разработчика, если на том же компьютере у меня достаточно ровно идет игра с более продвинутой графикой

Здравствуйте, vdimas, Вы писали:

PD>>При инсталляциии поставится та, что нужно. Примерно так же , как с локализацией, например.
PD>>Или один бинарник и несколько вариантов DLL, в которую и вынесено все, что depends.

V>По click-once тащить надо сразу все.

Надо. И что ? На сотню Кб больше ?

>Вот и получается, что вместо обычной линковки к DLL начинаем приседать с плагинной архитектурой или ручками GetProcAddress().

Это зачем ? Просто имеем , скажем, 2 DLL. Функции те же (не хватало еще разые функции заводить!). Но в одной DLL код внутри на SSE2, а в другой — обычный float/double. Делают их в VS за 5 минут — опции поменял и перекомпилировал.

>А точек входа — под 50...

А это не важно.

Здравствуйте, squid, Вы писали:

PD>>Я их, что ли заказывал ? Раз заказывали и платили — значит, нужны. И, возможно, сделаны кем-то из наших коллег здесь. Я тоже делал немного, правда, не для России.

S>Кто сказал что маленькие сайты кто-то заказывает?

Я лично участвовал в их разработке и мне за это платили. Не для России, правда. Время разработки (разумеется , на базе готового фреймворка — 2-3 месяца вдвоем). Сделали их за год штук 5. Был такой период в моей карьере

Здравствуйте, fmiracle, Вы писали:

PD>>А это аргумент, чтобы отказаться от поддержки W200x сервера и MS_SQL ? Можно и на чужом компиляторе откомпилировать... Oracle вроде как вообще свои компиляторы не пишет.

F>Сдается мне, это был пример того, что не все МС может осилить.

F>Или, с другой стороны, что не все им настолько надо, чтобы действительно осилить любой ценой.

Я все же подозреваю, что причины более серьезные. Они там изложены.

>Why the change? The natural evolution of the x86 64-bit (“x64”) architecture has led to the creation of processors and servers which deliver the scalability and reliability needed for today’s “mission-critical” workloads. Just this week, both Intel and AMD have released new high core-count processors, and servers with 8 or more x64 processors have now been announced by a full dozen server manufacturers. Such servers contain 64 to 96 processor cores, with more on the horizon.

Здравствуйте, DOOM, Вы писали:

CC>>Грубо говоря, может у тебя железо до требований не дотягивало?
DOO>Меня не волнуют требования разработчика, если на том же компьютере у меня достаточно ровно идет игра с более продвинутой графикой

Т.е. всё таки требования не выполнялись.
Ты в курсе что кроме красивости картинки под капотом есть ещё море вычислений которых на первый взгляд не видно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Ты в курсе что кроме красивости картинки под капотом есть ещё море вычислений которых на первый взгляд не видно.
Мы о чем говорим? Есть задача — есть пути решения. Кто-то решает эффективно, кто-то решает через опу.

Мне, как потребителю, глубоко филетово до того, какие они там преобразования Фурье использовали и прочие малопонятные вещи — я вижу просто: есть картинка №1 — симпатичнее и менее требовательная, есть картинка №2 — менее симпатичная и тормозящая. Отсюда вывод: картинка №2 создавалась некачественно. При чем тут написанные ими требования? Я тоже много что написать могу...

Здравствуйте, DOOM, Вы писали:

CC>>Ты в курсе что кроме красивости картинки под капотом есть ещё море вычислений которых на первый взгляд не видно.
DOO>Мы о чем говорим? Есть задача — есть пути решения. Кто-то решает эффективно, кто-то решает через опу.

с какой игрой в стиле "Хитмана" ты сравнивал?.

DOO>Мне, как потребителю, глубоко филетово до того, какие они там преобразования Фурье использовали и прочие малопонятные вещи — я вижу просто: есть картинка №1 — симпатичнее и менее требовательная, есть картинка №2 — менее симпатичная и тормозящая. Отсюда вывод: картинка №2 создавалась некачественно. При чем тут написанные ими требования? Я тоже много что написать могу...

т.е. ты просто сравнивал картинки?.

даже Шеридан хоть сколько-нибудь внимания уделяет функционалу.. мдаа..

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, CreatorCray, Вы писали:

CC>>Грубо говоря, может у тебя железо до требований не дотягивало?
DOO>Меня не волнуют требования разработчика, если на том же компьютере у меня достаточно ровно идет игра с более продвинутой графикой

Что за игра?

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, DOOM, Вы писали:

CC>>>Ты в курсе что кроме красивости картинки под капотом есть ещё море вычислений которых на первый взгляд не видно.
DOO>>Мы о чем говорим? Есть задача — есть пути решения. Кто-то решает эффективно, кто-то решает через опу.
F>с какой игрой в стиле "Хитмана" ты сравнивал?.
Точно не помню. То ли HL 1, то ли IGI... Давно это было.

DOO>>Мне, как потребителю, глубоко филетово до того, какие они там преобразования Фурье использовали и прочие малопонятные вещи — я вижу просто: есть картинка №1 — симпатичнее и менее требовательная, есть картинка №2 — менее симпатичная и тормозящая. Отсюда вывод: картинка №2 создавалась некачественно. При чем тут написанные ими требования? Я тоже много что написать могу...
F>т.е. ты просто сравнивал картинки?.

F>даже Шеридан хоть сколько-нибудь внимания уделяет функционалу.. мдаа..

Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.

Здравствуйте, Pavel Dvorkin, Вы писали:

V>>По click-once тащить надо сразу все.

PD>Надо. И что ? На сотню Кб больше ?

На пару мег при общем объеме в полтора. Там как раз нативные вычисления в DLL, а размеры managed бинарников невелики.

>>Вот и получается, что вместо обычной линковки к DLL начинаем приседать с плагинной архитектурой или ручками GetProcAddress().

PD>Это зачем ? Просто имеем , скажем, 2 DLL. Функции те же (не хватало еще разые функции заводить!). Но в одной DLL код внутри на SSE2, а в другой — обычный float/double. Делают их в VS за 5 минут — опции поменял и перекомпилировал.

Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

Здравствуйте, vdimas, Вы писали:

PD>>Надо. И что ? На сотню Кб больше ?

V>На пару мег при общем объеме в полтора.

Что-то я в эт совсем не верю. Реально этого SSE кода в большнистве приложений кот наплакал — где там плавающая арифметика ? Ну а если все же есть — вынести ее в DLL и все. Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим. Что же касается данных и ресурсов, то их дублировать совсем незачем.

>Там как раз нативные вычисления в DLL, а размеры managed бинарников невелики.

Какое мне дело до managed ?

>>>Вот и получается, что вместо обычной линковки к DLL начинаем приседать с плагинной архитектурой или ручками GetProcAddress().

PD>>Это зачем ? Просто имеем , скажем, 2 DLL. Функции те же (не хватало еще разые функции заводить!). Но в одной DLL код внутри на SSE2, а в другой — обычный float/double. Делают их в VS за 5 минут — опции поменял и перекомпилировал.

V>Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

А зачем им лежать-то ? Инсталлятор выбирает нужную и записывает только ее. Или ты боишься, что заменят на машине процессор на худший ? Ну что же, можно и это предусмотреть и предложить ренисталляцию. Хотя вероятность такого события 10^-N.

Здравствуйте, DOOM, Вы писали:

DOO>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.

Хитман на таком не тормозит ничуть.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Что-то я в эт совсем не верю. Реально этого SSE кода в большнистве приложений кот наплакал — где там плавающая арифметика ?

У нас — везде.

PD>Ну а если все же есть — вынести ее в DLL и все.

Именно оно и вынесено.

PD>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.

Без комментариев.
Размеры исходников современных проектов себе представляешь? Не ресурсов и всякой фигни, а тупо подсчет суммарного размера *.h/*.cpp/*.cs файлов?

PD>Что же касается данных и ресурсов, то их дублировать совсем незачем.

Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

V>>Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

PD>А зачем им лежать-то ? Инсталлятор выбирает нужную и записывает только ее. Или ты боишься, что заменят на машине процессор на худший ? Ну что же, можно и это предусмотреть и предложить ренисталляцию. Хотя вероятность такого события 10^-N.

Нет, дело в Click-once и манифестах. Ты не сможешь провернуть такой фокус. Ты даже не сможешь провернуть такой трюк, как копирование/переименование при первом запуске одной из установленных библиотек (если нет админских прав), ну типа чтобы выбрать одну из скачанных по Click-once. Безопасность, однако.

Здравствуйте, Antikrot, Вы писали:

A>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX

Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.

Здравствуйте, Antikrot, Вы писали:

A>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX

А да, забыл про драйвера аудио и видео. Например, шумоподавление и эхоподавление выполняется драйвером DirectX на уровне исполнения ядра, а не юзверского кода...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.
Я правильно понимаю что под 500 кб кода понимается размер бинаря?
Такие размеры в числодробилках достижимы легко, сложнее даже сделать меньше чем 500 кб при оптимизации по скорости.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

PD>>Что-то я в эт совсем не верю. Реально этого SSE кода в большнистве приложений кот наплакал — где там плавающая арифметика ?

V>У нас — везде.

Так что у вас. У большинства приложений — вряд ли.

V>

V>Без комментариев.
V>Размеры исходников современных проектов себе представляешь? Не ресурсов и всякой фигни, а тупо подсчет суммарного размера *.h/*.cpp/*.cs файлов?

Меня мало интересуют размеры исходников, это дело разработчиков. А 500 Мб чистого кода — это очень немало.

Вот пожалуйста

ntoskrnl.exe Ядро ОС как-никак

19C000 .text , т.е. 1.5 Мб кода.

nvcuda.dll. Тоже не шутка, ПО для GPU.

1F2000 .text, т.е. 2 Мб.

winmm.dll

26000 .text. Всего-то 150 Кб.

win32k.sys (вот уж где ужас должен быть!)

29F000 .text Ан нет, примерно 2.8 Мб

PD>>Что же касается данных и ресурсов, то их дублировать совсем незачем.

V>Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

Ну и храните их в отдельной DLL.

V>>>Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

PD>>А зачем им лежать-то ? Инсталлятор выбирает нужную и записывает только ее. Или ты боишься, что заменят на машине процессор на худший ? Ну что же, можно и это предусмотреть и предложить ренисталляцию. Хотя вероятность такого события 10^-N.

V>Нет, дело в Click-once и манифестах. Ты не сможешь провернуть такой фокус. Ты даже не сможешь провернуть такой трюк, как копирование/переименование при первом запуске одной из установленных библиотек (если нет админских прав), ну типа чтобы выбрать одну из скачанных по Click-once. Безопасность, однако.

Что за ерунда ? Есть инсталлятор. Он распаковывает в какой-то временный каталог (иногда видимо для юзера, даже порой спрашивая его — куда ?, иногда невидимо). Потом берет оттуда то, что надо и записывает в Program Files\ProductName\. Что за проблемы ? Зачем мне что-то еще потом без админских прав делать-то ? Там будет только та DLL, которая нужна.

Здравствуйте, CreatorCray, Вы писали:

CC>Я правильно понимаю что под 500 кб кода понимается размер бинаря?

Нет. Секции .text в бинаре.

См. http://rsdn.ru/forum/flame.comp/3780625.1.aspx

Здравствуйте, neFormal, Вы писали:

DOO>>Точно не помню. То ли HL 1, то ли IGI... Давно это было.
F>HL1 по картинке и функционалу до "Хитмана" очень далеко..
Ты с каким хитманом сравниваешь? Там была убогая низкодетальная мультяшная графика. В отличие от...

F>IGI в плане картинки такой же или чуть лучше, но это всё таки 3D-шутер с более простым функционалом..
Непонятно... Ну да — трупы там нельзя было таскать по лесенке (кстати, я как в хитмане не отразил мега реалистичности этого процесса) — но в целом там ого-го было... Те же размеры локаций...

DOO>>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
F>что то по поводу памяти у меня очень большие подозрения.. ну и по качеству картинки тоже сомневаюсь..
F>какие нибудь ссылки/доказательства есть?.
В HL2 я первый раз играл именно на такой конфигурации — грузилось долго, но игровой процесс совершенно не тормозил.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, DOOM, Вы писали:

DOO>>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
CC>Ты ничего не путаешь?
CC>С минимальными настройками может он и заведётся, но тормозить будет.
Нет не путаю. Я в него даже достаточно долго играл, пока не дошел до большого жука — где бажный движок скриптов все-таки заглючил окончательно и вортигон после выпиливания железы их жука тупо завис...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.
CC>>Я правильно понимаю что под 500 кб кода понимается размер бинаря?
PD>Нет. Секции .text в бинаре.
PD>См. http://rsdn.ru/forum/flame.comp/3780625.1.aspx
500 КБ секция кода — легко.
По ссылке ты речь ведёшь о МБ

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Странно, мой 3200+ вполне себе SSE2 и SSE3 поддерживает, как раз года 3 назад выпустился. Хотя тот же mplayer при динамической подгрузке оптимизаций SSE3 не видит

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Меня мало интересуют размеры исходников, это дело разработчиков. А 500 Мб чистого кода — это очень немало.

PD>Вот пожалуйста

Что хотел примерами сказать?

V>>Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

PD>Ну и храните их в отдельной DLL.

Выпал в осадок... Павел, не торопись ты с ответами... Вещественные литералы — это аналоги целочисленных констант, во всех числодробилках ведется борьба за увеличение скорости подкачки вещественных чисел, и предлагать мне организовать доступ к ним через thunk — это просто из ряда вон. Я уже молчу об организационных проблемах: нафига мне многие сотни дополнительно экспортируемых символов из DLL?

PD>Что за ерунда ? Есть инсталлятор. Он распаковывает в какой-то временный каталог (иногда видимо для юзера, даже порой спрашивая его — куда ?, иногда невидимо). Потом берет оттуда то, что надо и записывает в Program Files\ProductName\. Что за проблемы ? Зачем мне что-то еще потом без админских прав делать-то ? Там будет только та DLL, которая нужна.

В большинстве популярных настроек политик инсталлятор могут запускать юзвери с админскими правами (иногда "продвинутые", но это больше на домашних PC). А Click-once позволяет скачивать, обновлять и устанавливать приложения обычным юзверям. В этом случае прога ставится не в PF, а в локальный кеш браузера, который периодически чистится.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, CreatorCray, Вы писали:

CC>>500 КБ секция кода — легко.
CC>>По ссылке ты речь ведёшь о МБ

PD>Да, но все ядро системы вместо с графикой и окнами — примерно 4 Мб. Так что 500 Кб — это более 10% ядра ОС.

Это только тот код, который работает с абстракциями. А все реальные дрова, реализующие эти абстракции, кодеки и т.д. — многократно больше.

V>>>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

M>>Угу, и сколько человеколет для этого нужно?

V>В числодробилках? Ровно столько, сколько стоит изобрести и отладить алгоритм. А реализация готового алгоритма на любом из языков (поддерживающих арифметические вычисления) — это такая незаметная и под микроскопом ерунда, что обсуждать тут нечего.

V>Или ты про реализацию фиберов спрашивал? Все уже давно работает.

Не про реализацию фиберов. А про реализацию многопоточности + асинхронных сообщений + отслеживания ошибок в этих сообщениях + иерархии процессов, как в Эрланге (где все это уже есть — бери и пользуйся). Более того, какого уровня должен ыть программист на C/C++, чтобы все это реализовать на фиберах.

Здравствуйте, Torie, Вы писали:

T>В VS2010 систему справки переделали полностью, там вместо старого просмотрщика документов теперь обычный IE, который забирает контент с винта через локальный веб-сервер. OMFG! o_O

Юзай Firefox, я в нем смотрю. Причем тут IE...

T>На переделку явно вбухана куча труда, тормозит еще хуже чем раньше,

Нет, не тормозит, лично у меня шустрее.

T>функционал зарезали, нет даже индекса слов.

Это да, юзаю стороннюю тулзу + аддон для интеграции в студию специфичной. Удобно.

T>Зачем???? Со всех сторон — одни недостатки.

Ы? У кого как... Да и апдейты через веб раз в пару месяцев а не раз в год или два как старый локальный MSDN, это не плюс?

T>Видимо, кто-то из манагеров прочитал в новостях, что сегодня web-based — это очень модно.

Ну если Хром стоит по дефолту — нереально шустро просто.

Здравствуйте, squid, Вы писали:

S>Юзай Firefox, я в нем смотрю. Причем тут IE...

Дольше всего тормозит при загрузке веб-сервера и файлов контента. При чем тут Firefox?...

S>Ы? У кого как... Да и апдейты через веб раз в пару месяцев а не раз в год или два как старый локальный MSDN, это не плюс?

Это плюс, только не имеет никакого отношения к замене оболочки

Здравствуйте, vdimas, Вы писали:

PD>>Вот пожалуйста

V>Что хотел примерами сказать?

Что в 4 Мб кода можно все ядро современной ОС уложить.

V>>>Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

PD>>Ну и храните их в отдельной DLL.

V>Выпал в осадок... Павел, не торопись ты с ответами... Вещественные литералы — это аналоги целочисленных констант, во всех числодробилках ведется борьба за увеличение скорости подкачки вещественных чисел, и предлагать мне организовать доступ к ним через thunk — это просто из ряда вон.

Слушай, не смеши. При чем тут thunk ? Есть, во-первых, разделяемые секции, доступ такой же, как к любым переменным. Есть массивы — доступ по thunk один раз, для получения адреса, а потом делай что хочешь.

Я уже молчу об организационных проблемах: нафига мне многие сотни дополнительно экспортируемых символов из DLL?

Уф... Про struct в языке С тебе рассказать или сам посмотришь ?

PD>>Что за ерунда ? Есть инсталлятор. Он распаковывает в какой-то временный каталог (иногда видимо для юзера, даже порой спрашивая его — куда ?, иногда невидимо). Потом берет оттуда то, что надо и записывает в Program Files\ProductName\. Что за проблемы ? Зачем мне что-то еще потом без админских прав делать-то ? Там будет только та DLL, которая нужна.

V>В большинстве популярных настроек политик инсталлятор могут запускать юзвери с админскими правами (иногда "продвинутые", но это больше на домашних PC). А Click-once позволяет скачивать, обновлять и устанавливать приложения обычным юзверям. В этом случае прога ставится не в PF, а в локальный кеш браузера, который периодически чистится.

Меня проги, которые ставятся в кеш браузера, не особенно интересуют. А обычные проги ставят обычым способом, и для него вариает с выбором DLL во аремя инсталляции вполне работает. Даже если при этом надо сделать 2 клика. А то, что в броузере и click-once, пусть себе остается без SSE

Здравствуйте, vdimas, Вы писали:

V>На тех задачах, где вообще звучит SSE, про эти платформы упоминать малость неприлично.

Это пока

Здравствуйте, vdimas, Вы писали:

A>>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
V>А да, забыл про драйвера аудио и видео. Например, шумоподавление и эхоподавление выполняется драйвером DirectX на уровне исполнения ядра, а не юзверского кода...
да, это шикарный аргумент за линуксовое ядро

Здравствуйте, Pavel Dvorkin, Вы писали:

V>>Выпал в осадок... Павел, не торопись ты с ответами... Вещественные литералы — это аналоги целочисленных констант, во всех числодробилках ведется борьба за увеличение скорости подкачки вещественных чисел, и предлагать мне организовать доступ к ним через thunk — это просто из ряда вон.

V>>Я уже молчу об организационных проблемах: нафига мне многие сотни дополнительно экспортируемых символов из DLL?

PD>Есть массивы — доступ по thunk один раз, для получения адреса, а потом делай что хочешь.
PD>Уф... Про struct в языке С тебе рассказать или сам посмотришь ?

Это все-равно организационные проблемы. Там где я сейчас пишу float a = b * 0.99f, я должен буду писать нечто вроде float a = b * literals.value_0_99f. Как этим всем управлять, если у меня DLL собирается из более десятка несвязанных статических либ? Это и есть ненужные организационные проблемы на ровном месте, т.к. есть куча абсолютно несвязанных вычислений со своими константами. А главное — это не разумно, ведь в процессе оптимизации компилятор склеивает одинаковые литералы, а при их ручной симуляции ничего не будет склеено.

PD>Меня проги, которые ставятся в кеш браузера, не особенно интересуют. А обычные проги ставят обычым способом, и для него вариает с выбором DLL во аремя инсталляции вполне работает. Даже если при этом надо сделать 2 клика. А то, что в броузере и click-once, пусть себе остается без SSE

Оно не в браузере работает, оно через него только ставится.

Здравствуйте, dr.Chaos, Вы писали:

V>>Ну а в шустрых процах от АМД того времени никакого SSE2 не было.
DC>Странно, мой 3200+ вполне себе SSE2 и SSE3 поддерживает, как раз года 3 назад выпустился. Хотя тот же mplayer при динамической подгрузке оптимизаций SSE3 не видит

.

У тебя какой-нить x64 скорее всего. А "того времени" было относительно упомянутого P4 в бытность его SSE2, это 2003-2005-й года, и я имел ввиду AthlonXP (конкретно Barton), про который уже высказался http://www.rsdn.ru/forum/flame.comp/3780500.1.aspx .

Здравствуйте, vdimas, Вы писали:

A>>ты не совсем понял. Ц++ тут чуть ли не худший вариант.
V>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах. Зато если речь пойдет о числодробилках, то тот же Эрланг сливает не по детски.
ну какой Эрланг, я его даже не видел. Фортран наше всё! А в плюсах есть указатели, которые страшное зло для всего более-менее автоматического, и приходится копаться в этих ваших "низкоуровневых сервисах".

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Mamut, Вы писали:

V>>>Или ты про реализацию фиберов спрашивал? Все уже давно работает.

M>>Не про реализацию фиберов. А про реализацию многопоточности + асинхронных сообщений + отслеживания ошибок в этих сообщениях + иерархии процессов, как в Эрланге (где все это уже есть — бери и пользуйся).

V>Ты уверен, что знаешь, о чем говоришь?

Я не уверен, что ты тоже знаешь, о чем говоришь

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

Да, я, пожалуй, смогу наврететь в приведенном примере какой-нить (обязательно доморощенный

) пул потоков с супервайзерами и т.п. Но где легкость-то?

V>Вот как раз на днях недавно было обсуждение процов и там готовый пример распараллеливания перемножения матриц. http://www.rsdn.ru/forum/education/3775892.1.aspx
V>Переведи на Эрланг. Сравни кол-во кода и быстродействие.

а что преводить? spawn вместо createthread — и вперед. другое дело, когда нам ВНЕЗАПНО

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

И начнутся ручные закаты солнца.

V>Понимаешь, распараллеливание в Эрланге хорошо там, где мы много автоматов "разворачиваем" из логики потактового хождения по состояниям в обычный код, и упомянутые "сообщения" и "синхронизация" в этом контексте — обычные сигналы, которыми автоматы обмениваются друг с другом. Что же касается числодробилок, то распараллеливание там предметнозависимо, т.е. нагрузка на прикладную часть все равно выходит больше, чем на языковую. Поэтому пока языки не очень помогают, зато хорошо помогают библиотеки заготовок для распараллеливания частовстречающихся вычислительных сценариев.

Ключевое выделено. Именно это и есть Эрланг и то, что есть в Эрланге.

M>>Более того, какого уровня должен ыть программист на C/C++, чтобы все это реализовать на фиберах.

V>Такого же уровня, чтобы мог реализовать на обычных тредах.

Реализацию фиберов может делать другой программист или ее можно взять готовую. Ну и опять же — давай будем внимательнее.

что я имел в виду под такую же я привел выше в 4-х пунктах.

V>На самом деле там не все так просто, "тупое" и автоматическое распараллеливание лишь ухудшает общие показатели.

Про тупое никто и не говорит

Здравствуйте, Antikrot, Вы писали:

A>ну какой Эрланг, я его даже не видел. Фортран наше всё! А в плюсах есть указатели, которые страшное зло для всего более-менее автоматического, и приходится копаться в этих ваших "низкоуровневых сервисах".

Я понятия не имею, как на Фортране писать многопоточные приложения. Знаю, что есть какие-то реализации самораспараллеливающих фортранов. Но нам же не только числодробить надо, есть же еще и обслуживающая логика, которая почти всегда многопоточна на сегодня. А если делать "тупо числодробильные либы" на Фортране, которые мы вызываем из других языков, то мы попадемся на описанный эффект: http://www.rsdn.ru/forum/flame.comp/3781531.1.aspx

Приветствую, koandrew, вы писали:

k> А ты купи себе 40+-дюймовую FullHD LCD панельку и вруби там SD-фильм, а потом тот же фильм — в 1080p/i. Тогда ты про "мегаХД" по-другому заговоришь...

Нет, я куплю 1080, а потом схожу в кинотеатр. И по другому заговорю.

Я что, против HD? Почитай внимательнее, я всего лишь выставил приоритеты.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Torie, Вы писали:

T>Дольше всего тормозит при загрузке веб-сервера и файлов контента. При чем тут Firefox?...

У меня мгновенно все... А сервер один раз запускается и потом в трее висит. Секунды за 3 где-то.

T>Это плюс, только не имеет никакого отношения к замене оболочки

Ну мне то что убрали TOC и Index не нравится, вернул другой прогой. А в остальном пока сплошные плюсы.

Здравствуйте, vdimas, Вы писали:

PD>>Батенька, не смеши. Дрова сами по себе, а это ядро системы. Оно реализует вксь kernel и executive.

V>Ну и? Там перечисление десятка основных ф-ий ядра. Какая из приведенных тобой задач должна была быть большой по объему, сравнимой хотя бы с одним видеокодеком?

Там не десяток функций ядра, а правктически все ядро.
Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?

PD>>И это далеко не все. И про win32k.sys я могу такое же найти.

V>И что оно даст? Вот что дает то, что ты смог найти?

V>ShellDll32.dll сегмент .text = 2M
V>Это в твою пользу или мою?

В мою. Это приличная , большая часть всего explorer, со всеми его интерефейсами, коих совсем не мало.

V>Ты можешь просто в фаре, в просмотрщике процессов посмотреть загруженные DLL и EXE процессов и просуммировать их размеры (не считая повторяющиеся, разумеется).

Нет, это размеры EXE (DLL), а отнюдь не кода. Кода там может быть существенно меньше. Есть еще данные, есть ресурсы...

V>И вообще, вместо приведения примеров бог весть чего, не имеющего отношения ни к чему, просто спросил бы, что у меня там? У меня там пара десятков аудио-фильтров, миксеры, пред/пост обработчики речи, кодеки (как аудио, так и видео), генераторы, детекторы речи, компрессоры/декомпрессоры и т.д.

Приведи размер секции кода твоей DLL, будет ясно.

Приветствую, koandrew, вы писали:

k> Вот когда ты сумеешь принести домой этот кинотеатр — тогда вернёмся к этому разговору.

Зачем?

k> S>Я что, против HD? Почитай внимательнее, я всего лишь выставил приоритеты.
k> Напиши плейер и кодеки, которые сумеют декодировать 1080p H264+DD/DTS звук в реальном времени на 800 МГц проце — тебе памятник при жизни поставят. А языком чесать — это не мешки таскать...
Да почти любой hd-медиаплеер имеет на борту камень с частотой сильно меньше гигагерца.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, vdimas, Вы писали:

V>Это все-равно организационные проблемы. Там где я сейчас пишу float a = b * 0.99f, я должен буду писать нечто вроде float a = b * literals.value_0_99f.

Решительно не понимаю — зачем. Во-первых, писать так — float a = b * 0.99f — дурной тон, сам знаешь почему. Во-вторых, доступ к данным DLL может быть организован так же, как к данным вне DLL. А в третьих, мы о чем говорим-то ? Я предложил все вычисления, связанные с SSE, вынести в DLL. Никаких особых организационных проблем тут нет. Берешь функцию, переносишь в DLL. Если тебя смущает thunk, то могу тебе сообщить, что там всего лишь одна команда косвенного перехода и на фоне твоей числодробилки это совершенный пустяк. Никогда не слышал, чтобы кто-то жаловался на проблемы, связанные с выносом кода в DLL.

>Как этим всем управлять, если у меня DLL собирается из более десятка несвязанных статических либ? Это и есть ненужные организационные проблемы на ровном месте, т.к. есть куча абсолютно несвязанных вычислений со своими константами. А главное — это не разумно, ведь в процессе оптимизации компилятор склеивает одинаковые литералы, а при их ручной симуляции ничего не будет склеено.

Господи, какие пустяки. Сколько у тебя там этих литералов, сотни тысяч, миллионы ? Если так — вынеси их в отдельную секцию. Если нет — не морочь себе голову. Кстати, компилятор склеивает именно литералы, то есть строки

/GF (Eliminate Duplicate Strings)

Насчет склеивания числовых констант — не слышал. И уж вряд ли линкер (а не компилятор) будет их склеивать из разных статических либ.

V>Оно не в браузере работает, оно через него только ставится.

Зачем ? Чем не устраивает обычный способ : загрузить инсталлятор и запустить ? Только вторым кликом ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Там не десяток функций ядра, а правктически все ядро.
PD>Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?
Алгоритмически — вполне молет быть и сложнее.

Вообще не понятно к чему ты тут это бинаремеряние развёл.
Объём бинарного кода в общем случае слабо связан со сложностью реализуемых им алгоритмов.
Например если посмотреть на demoscene в номинациях <=64k то окажется что колво сложной математики на единицу объёма там рвёт ядро ОС как тузик грелку.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Алгоритмически — вполне молет быть и сложнее.

Может, и еще как. Но я про алгоритмическую сложность не говорил.

CC>Вообще не понятно к чему ты тут это бинаремеряние развёл.
CC>Объём бинарного кода в общем случае слабо связан со сложностью реализуемых им алгоритмов.

Совершенно верно. Я просто пытаюсь объяснить, что если код, зависимый от употребления или неупотребления SSE, вынести в отдельную DLL да так, чтобы там ничего, кроме этого кода не было, да сделать несколько таких DLL (без SSE / SSE1 /SSE2...), то размер инсталляционного пакета изменится незначительно.

Здравствуйте, Pavel Dvorkin, Вы писали:

V>>Это все-равно организационные проблемы. Там где я сейчас пишу float a = b * 0.99f, я должен буду писать нечто вроде float a = b * literals.value_0_99f.

PD>Решительно не понимаю — зачем. Во-первых, писать так — float a = b * 0.99f — дурной тон, сам знаешь почему.

В автогенеренном коде, который генерится из того же matlab — очень даже не дурной, ровно наоборот.

PD>Я предложил все вычисления, связанные с SSE, вынести в DLL. Никаких особых организационных проблем тут нет. Берешь функцию, переносишь в DLL. Если тебя смущает thunk, то могу тебе сообщить, что там всего лишь одна команда косвенного перехода и на фоне твоей числодробилки это совершенный пустяк. Никогда не слышал, чтобы кто-то жаловался на проблемы, связанные с выносом кода в DLL.

Это ты на много постов в день похоже отвечаешь.

Сами ф-ии и вынесены, я возразил против выноса в общую DLL данных, которые используют эти ф-ии (3 их вида на разные SSE). Ибо thunk для доступа к данным — это уже как повезет с оптимизацией. Если хватит регистров — возможно, что данные будут загружены один раз, если не хватит — то в каждой итерации цикла. Да и вообще, нафига мне косвенная адресация на ровном месте?

PD>Господи, какие пустяки. Сколько у тебя там этих литералов, сотни тысяч, миллионы ? Если так — вынеси их в отдельную секцию. Если нет — не морочь себе голову.

Вот именно, что их не миллионы, т.е. вынос литералов ничего толком не сэкономит, а работы мне прибавит даже боюсь представить сколько.

PD>Кстати, компилятор склеивает именно литералы, то есть строки

Чего-чего? Что есть литерал? С-строка времени исполнения? Или символьное представление любых данных времени компиляции? Ты чего там студентам преподаешь-то?

Первоначально литерал в программировании — это символьное представление значения, которое преобразуется в само значение компилятором. В "жаргонном" и более узком смысле литералом называют константы, требующие память для размещения (наверняка из-за влияния С).

PD>Насчет склеивания числовых констант — не слышал. И уж вряд ли линкер (а не компилятор) будет их склеивать из разных статических либ.

И будет и склеивает, в том и фишка link-time codegeneration.
GCC тоже частично это уже умеет, правда пока только для С.

V>>Оно не в браузере работает, оно через него только ставится.

PD>Зачем ? Чем не устраивает обычный способ : загрузить инсталлятор и запустить ? Только вторым кликом ?

Я же уже говорил, что инсталлятор могут запускать только привелигированные пользователи, в отличие от приложений click-once.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Там не десяток функций ядра, а правктически все ядро.
PD>Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?

Назови хоть один из алгоритмов ядра ОС, который действительно тяжеловесен в плане объема кода?

PD>>>И это далеко не все. И про win32k.sys я могу такое же найти.

V>>И что оно даст? Вот что дает то, что ты смог найти?

V>>ShellDll32.dll сегмент .text = 2M
V>>Это в твою пользу или мою?

PD>В мою. Это приличная , большая часть всего explorer, со всеми его интерефейсами, коих совсем не мало.

Да что ты? А как же ADVAPI32, BrowseUI, SHDOCVW, IEFRAME и т.д. до бесконечности?

V>>И вообще, вместо приведения примеров бог весть чего, не имеющего отношения ни к чему, просто спросил бы, что у меня там? У меня там пара десятков аудио-фильтров, миксеры, пред/пост обработчики речи, кодеки (как аудио, так и видео), генераторы, детекторы речи, компрессоры/декомпрессоры и т.д.

PD>Приведи размер секции кода твоей DLL, будет ясно.

.text около 750k.

Здравствуйте, Mamut, Вы писали:

M>а что преводить? spawn вместо createthread — и вперед.

Ну так на сколько изменится в плане кода?

И на сколько в плане эффективности? Я же не ради забавы параллелить хочу.

M>другое дело, когда нам ВНЕЗАПНО

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

Мне не надо, если оно в моей задаче упало, то упало, продолжать дальше смысла нет.

M>Да еще желательно не на одном комптютере в сети

И начнутся ручные закаты солнца.

Это не по моей специфике.

M>Ключевое выделено. Именно это и есть Эрланг и то, что есть в Эрланге.

Нет, Эрланг — это тормоза и еще раз тормоза. Это то, что и есть Эрланг и то, что есть в Эрланге. Использовать его как высокоуровневый диспетчер логических потоков — еще куда ни шло. Вычислять что-то в нем — нет смысла.

V>>На самом деле там не все так просто, "тупое" и автоматическое распараллеливание лишь ухудшает общие показатели.

M>Про тупое никто и не говорит

А умного готового и нет, все-равно ручками надо конкретный вычислительный алгоритм доводить, тут помощь от конкретного языка не сильная.

M>>а что преводить? spawn вместо createthread — и вперед.

V>Ну так на сколько изменится в плане кода?

V>И на сколько в плане эффективности? Я же не ради забавы параллелить хочу.

Черт. Вот почему ты с непонятным упорство клонишь в числодробление? Здесь кто-то спорит с тем, что для числодробления Эрланг не подходит? Напомнить контекст?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:

V>>>Это все-равно организационные проблемы. Там где я сейчас пишу float a = b * 0.99f, я должен буду писать нечто вроде float a = b * literals.value_0_99f.

PD>>Решительно не понимаю — зачем. Во-первых, писать так — float a = b * 0.99f — дурной тон, сам знаешь почему.

V>В автогенеренном коде, который генерится из того же matlab — очень даже не дурной, ровно наоборот.

М-да, ну и аргумент...

PD>>Я предложил все вычисления, связанные с SSE, вынести в DLL. Никаких особых организационных проблем тут нет. Берешь функцию, переносишь в DLL. Если тебя смущает thunk, то могу тебе сообщить, что там всего лишь одна команда косвенного перехода и на фоне твоей числодробилки это совершенный пустяк. Никогда не слышал, чтобы кто-то жаловался на проблемы, связанные с выносом кода в DLL.

V>Это ты на много постов в день похоже отвечаешь.

Возможно.

V>Сами ф-ии и вынесены, я возразил против выноса в общую DLL данных, которые используют эти ф-ии (3 их вида на разные SSE). Ибо thunk для доступа к данным — это уже как повезет с оптимизацией.

Я же тебе объяснил, что для доступа к данным из DLL не нужен thunk, а можно сделать общую секцию. Если тебе этот доступ нужен вне DLL.

>Если хватит регистров — возможно, что данные будут загружены один раз, если не хватит — то в каждой итерации цикла. Да и вообще, нафига мне косвенная адресация на ровном месте?

ИМХО там не будет никакой косвенной адресации. См. #pragma dataseg.

PD>>Господи, какие пустяки. Сколько у тебя там этих литералов, сотни тысяч, миллионы ? Если так — вынеси их в отдельную секцию. Если нет — не морочь себе голову.

V>Вот именно, что их не миллионы, т.е. вынос литералов ничего толком не сэкономит, а работы мне прибавит даже боюсь представить сколько.

А если их не миллионы, то что тебя так заботит их объединение ? Ну будут у тебя в DLL один 4-байтник со значением 0.99, а в EXE — другой, тоже со значением 0.99. Ну и что ? Если бы миллионы были — я бы понял.

PD>>Кстати, компилятор склеивает именно литералы, то есть строки

V>Чего-чего? Что есть литерал? С-строка времени исполнения? Или символьное представление любых данных времени компиляции? Ты чего там студентам преподаешь-то?

Ты чего мне голову морочишь ? Что такое литерал в твоем понимании — это твое дело. А компилятор склеивает именно текстовые строки. Еще раз, подробнее. Выделено мной.

/GF (Eliminate Duplicate Strings)
Enables the compiler to create a single copy of identical strings in the program image and in memory during execution, resulting in smaller programs, an optimization called string pooling.
/GF pools strings as read-only
If you use /GF, the operating system does not swap the string portion of memory and can read the strings back from the image file. If you try to modify strings under /GF, an application error occurs.

String pooling allows what were intended as multiple pointers to multiple buffers to be as multiple pointers to a single buffer. In the following code, s and t are initialized with the same string. String pooling causes them to point to the same memory:

Copy Code
char *s = "This is a character buffer";
char *t = "This is a character buffer";

Понимаешь — string pooling. String (в смысле С), а не чего угодно. Вот в этом примере компилятор сделает одну строку "This is a character buffer", а не две. И то он это сделает, если эти строки находятся в одной единице компиляции ИМХО. Впрочем, за последнее не поручусь.

Так что если у тебя есть вот такое

char *p = "0.99";
char *t = "0.99";

то их склеят. Хотя и неясно, зачем так вещественные числа хранить.

А вот насчет такого

// глобальные переменные
float f1= 0.99;
float f2= 0.99;

ИМХО никакого склеивания не будет, а будут два четырехбайтника в секции .data со значением 0.99f.

V>Первоначально литерал в программировании — это символьное представление значения, которое преобразуется в само значение компилятором.

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

>В "жаргонном" и более узком смысле литералом называют константы, требующие память для размещения (наверняка из-за влияния С).

М-да... А не мог бы ты привести пример константы, не требующей памяти для размещения ? Я как-то плохо это себе представляю — константа есть, а памяти ей никак не надо

. Только не вздумай мне говорить, что можно ее прямо в коде разместить — на это тоже память нужна.

PD>>Насчет склеивания числовых констант — не слышал. И уж вряд ли линкер (а не компилятор) будет их склеивать из разных статических либ.

V>И будет и склеивает, в том и фишка link-time codegeneration.
V>GCC тоже частично это уже умеет, правда пока только для С.

Можно подробнее ? Со ссылками ? Я — не понимаю.

// глобальные переменные
float f1= 0.99;
float f2= 0.99;

Ты утверждаешь, что их склеят ? То есть в секции .data будет... впрочем, что будет ? Я вообще не пойму, что там может быть, если их склеить. Это же не указатели, и не на read-only память.

Здравствуйте, koandrew, Вы писали:

S>>Да почти любой hd-медиаплеер имеет на борту камень с частотой сильно меньше гигагерца.
K>"Почти любой hd-медиаплеер" имеет на борту аппаратный декодер, мы же говорим о компе с процом общего назначения.

Опаньки... Что есть, по-твоему, "аппаратный декодер"?

Здравствуйте, Mamut, Вы писали:

M>Черт. Вот почему ты с непонятным упорство клонишь в числодробление? Здесь кто-то спорит с тем, что для числодробления Эрланг не подходит? Напомнить контекст?

По той же причине, зачем вообще в форумах участвую. Вдруг коллеги чего полезного расскажут для МОИХ задач.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Там не десяток функций ядра, а правктически все ядро.
PD>>Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?

V>Назови хоть один из алгоритмов ядра ОС, который действительно тяжеловесен в плане объема кода?

Один ? Один, какой я ни назови, ты опровергать начнешь. Потому что один — действительно не может иметь большого объема кода. А вот все вместе...

PD>>>>И это далеко не все. И про win32k.sys я могу такое же найти.

V>>>И что оно даст? Вот что дает то, что ты смог найти?

V>>>ShellDll32.dll сегмент .text = 2M
V>>>Это в твою пользу или мою?

PD>>В мою. Это приличная , большая часть всего explorer, со всеми его интерефейсами, коих совсем не мало.

V>Да что ты? А как же ADVAPI32, BrowseUI, SHDOCVW, IEFRAME и т.д. до бесконечности?

Я же не сказал, что вся. А только большая.

V>>>И вообще, вместо приведения примеров бог весть чего, не имеющего отношения ни к чему, просто спросил бы, что у меня там? У меня там пара десятков аудио-фильтров, миксеры, пред/пост обработчики речи, кодеки (как аудио, так и видео), генераторы, детекторы речи, компрессоры/декомпрессоры и т.д.

PD>>Приведи размер секции кода твоей DLL, будет ясно.

V>.text около 750k.

И сколько времени писал ? Сколько человеко-часов ушло, считая с версии 0.0 ?

Здравствуйте, LuciferSaratov, Вы писали:

LS>Здравствуйте, sndanil, Вы писали:

S>>Здравствуйте, Torie, Вы писали:

T>>>Попробуем с другой стороны

Для каких задач обычного юзера не хватало процессоров 10-летней давности?

S>>Full HD Video? Crysis (и еще целая куча игрушек)?

LS>Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.

Не тормозит. РМ 1200 МГц. Вентилятор иногда жужжит, но отрисовка не тормозит.

И вообще, КДЕ показывает что большую часть времени он работает на частоте 300 МГц.

Приветствую, Eugeny__, вы писали:

E> Если честно, с появлением гмыла я с радостью отказался от специальных клиентов для почты. Они — тупо лишнее звено. Были актуальны 10 лет назад только потому, что интернет был хреновый и дорогой, и вообще не всегда был, потому копии писем лучше было хранить локально. Сейчас интернет доступен даже в лесу(с телефона), а уж настольных компов без подключения к сети я уже несколько лет в глаза не видел. Поэтому почтовые клиенты для меня напрочь потеряли смысл.

Молодец, говоришь про себя.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, vdimas, Вы писали:

V>Опаньки... Что есть, по-твоему, "аппаратный декодер"?

Аппаратный декодер — это такая микросхемка, которая умеет только одну вещь — декодировать видео. Детали чипа, к примеру, моего плейера ASUS O!PLAY AIR, под NDA, но из общих соображений и некоторого опыта в этой сфере могу предположить, что там много-много потоковых микроядер, выполняющих декодирование с высокой степенью параллелизма. А теперь покажите мне такие микроядра (причём много микроядер!) в CPU и будем считать вопрос закрытым.

Здравствуйте, koandrew, Вы писали:

K>Аппаратный декодер — это такая микросхемка, которая умеет только одну вещь — декодировать видео. Детали чипа, к примеру, моего плейера ASUS O!PLAY AIR, под NDA, но из общих соображений и некоторого опыта в этой сфере могу предположить, что там много-много потоковых микроядер, выполняющих декодирование с высокой степенью параллелизма.

Какой вид парралелизма?

K>А теперь покажите мне такие микроядра (причём много микроядер!) в CPU и будем считать вопрос закрытым.

Не угадал с ЦПУ. Т.н. "аппаратный декодер" — это DSP + программа к нему во встроенном ПЗУ. Про микроядра не смеши, современные DSP имеют много вычислительных блоков, но они не представляют из себя независимые ядра, т.е. не в состоянии независимо обрабатывать потоки вычисления. Код DSP — это нечто вроде VLIW, т.е. широкая команда, которая за один такт управляет сразу несколькими вычислительными блоками. В общем, все эти аппаратные декодеры чего бы там ни было — это просто некий популярный DSP + вшитая программа к нему.

Поинт в том, что никто в здравом уме не будет реализовывать никакие более-менее сложные алгоритмы в виде TRUE-автоматов, это всегда будет процессор, общего назначения либо сигнальный, и обычная программа к нему. Некоторые т.н. "аппаратные декодеры" даже имеют возможность эту программу перепрошить.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Один ? Один, какой я ни назови, ты опровергать начнешь. Потому что один — действительно не может иметь большого объема кода. А вот все вместе...

Именно что.

V>>.text около 750k.

PD>И сколько времени писал ? Сколько человеко-часов ушло, считая с версии 0.0 ?

Там не только наш код.

Здравствуйте, DOOM, Вы писали:

DOO>>>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
CC>>Ты ничего не путаешь?
CC>>С минимальными настройками может он и заведётся, но тормозить будет.
DOO>Нет не путаю. Я в него даже достаточно долго играл, пока не дошел до большого жука — где бажный движок скриптов все-таки заглючил окончательно и вортигон после выпиливания железы их жука тупо завис...

Спецом поставил HL2 и померял потребление памяти.

Из картинки видно, что сам HL2 потребил 485.13 Mb основной памяти и 223.85 Mb видеопамяти.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:

V>Павел, давай уже или внимательно что-то обсуждать или не обсуждать вообще. Зачем ты мне приводишь глобальные переменные, когда я говорил о константах?

Извини, невнимательно прочитал. С этим согласен. Кстати, мог еще пару #define привести — их тоже склеят

. Точнее, конечно, не склеят, а просто выкинут.

Но по существу — все равно не вижу проблемы. Константы — не переменные, где можно в одной строке пару Мб отхватить. Их все записать надо, а поэтому их много не будет. Поэтому склееены они или нет — не так уж важно. Если же их действительно много, то их в коде не размещают явно, а делают как-то иначе (скажем, R/O MMF).

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Один ? Один, какой я ни назови, ты опровергать начнешь. Потому что один — действительно не может иметь большого объема кода. А вот все вместе...

V>Именно что.

А что именно ? Вот представь себе -- тебе ядро ОС дали написать. Сам по себе, скажем, решедулинг потоков — не бог весть что. Просмотр списков и т.д. И само по себе обнаружение нового устройства по PnP — может, тоже. И т.д. А все вместо — совсем не хило. А всего-то 2 Мб.

V>>>.text около 750k.

PD>>И сколько времени писал ? Сколько человеко-часов ушло, считая с версии 0.0 ?

V>Там не только наш код.

А на ваш — сколько ? И сколько он в % от 750 Кб ? Грубо, конечно, +- 10% сойдет.

Здравствуйте, Mamut, Вы писали:

M>а что преводить? spawn вместо createthread — и вперед. другое дело, когда нам ВНЕЗАПНО

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

можно просто использовать готовые реализации..

M>Да еще желательно не на одном комптютере в сети

И начнутся ручные закаты солнца.

надуманная задача, надуманные проблемы..

Здравствуйте, Eugeny__, Вы писали:

E__>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

И не страшно вот так на всех компах пароль свой оставлять?

Здравствуйте, CreatorCray, Вы писали:

E__>>У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.
CC>-1

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

Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.

Здравствуйте, hattab, Вы писали:

E>> Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка?

H>Открой для себя уже флешки и portable applications... А вообще, сейчас, все решается сильно проще -- маленькими и легкими нетбуками.

Не, мне веб удобнее.
И да, уже есть приложения, работающие под винды, макоси, линуха, и разнообразные мобильные системы, при этом переносимые? Я на почту захожу с разных систем(дома и на работе с линухов/винды, в гостях может быть и макось, в поездках с симбиана).

H>Как-то я пытался зайти на гуглопочту Оперой... Гуглапочта сказала, что не любит мой браузер.

Я только оперой и пользуюсь. Давно, видимо, описанное было.

H>Что ты будешь делать, когда инета нет? Я, разумеется, читал выше о том, что ты уже давно не видел компов без инета, и даже в лесу с телефона можно его поиметь. Однако сотовые сети в дневное время это вообще что-то (юзал и МТС и Мегафон)... Пока прогрузится html-морда сдохнуть можно. Кроме того связь есть не везде. Отъехал от города на 30км, спустился в низинку к озеру и пипец.

Мы в разных странах

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

E>> У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.

H>Веб-интерфейсы это унылые попытки закосить под нормальный десктопный гуй. Оффлайн клиенты — это доступ к базе почты в любой момент, вне зависимости от наличия инета. Более того, есть гаратния что ты не окажешься вообще без почты в самый важный момент, а так бывает:

H>http://www.computerra.ru/vision/455478/

В этот раз, однако, сотрудники Google недооценили загрузку роутеров, перенаправлявших запросы, в результате чего в 12:30 они оказались перегружены и в результате стали отвергать запросы, что повлекло перенаправление их на свободные маршрутизаторы. Когда и те оказались перегружены, доступ пользователей к странице Gmail был отрезан, в то время как с доступом по IMAP/POP было всё в порядке поскольку эти сервера работают на собственных мощностях.

Вероятность таких событий сильно меньше вероятности потерять флешку

Здравствуйте, Константин Б., Вы писали:

E__>>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

КБ>И не страшно вот так на всех компах пароль свой оставлять?

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

Здравствуйте, vdimas, Вы писали:

V>Не угадал с ЦПУ. Т.н. "аппаратный декодер" — это DSP + программа к нему во встроенном ПЗУ. Про микроядра не смеши, современные DSP имеют много вычислительных блоков, но они не представляют из себя независимые ядра, т.е. не в состоянии независимо обрабатывать потоки вычисления. Код DSP — это нечто вроде VLIW, т.е. широкая команда, которая за один такт управляет сразу несколькими вычислительными блоками. В общем, все эти аппаратные декодеры чего бы там ни было — это просто некий популярный DSP + вшитая программа к нему.
Именно поэтому я не называл эти блоки отдельными ядрами, а "микроядрами". Это типа как в Cell — одно полноценное ядро + кучка вычислительных.
Спекулировать по поводу содержимого чипа не буду — ибо даташит найти в открытом доступе я не сумел. По сути, всё, что я нашёл, это страница продукта: http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=26&Level=3&Conn=2&ProdID=238
"Зайдя" на плейер по телнету, выяснил, что CPU там MIPS, при этом загрузка его при просмотре фильма в районе нуля, из чего можно сделать вывод о наличии там специализированного процессора для обработки видео. Т.е. ваша теория о DSP не выдерживает проверку практикой — там определённо что-то специфическое.

V>Поинт в том, что никто в здравом уме не будет реализовывать никакие более-менее сложные алгоритмы в виде TRUE-автоматов, это всегда будет процессор, общего назначения либо сигнальный, и обычная программа к нему. Некоторые т.н. "аппаратные декодеры" даже имеют возможность эту программу перепрошить.
Опять же практика частично опровергает ваши слова...

Здравствуйте, Eugeny__, Вы писали:

E> Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.

Ну так, как только — так сразу

avalon 1.0rc2 rev 272

Здравствуйте, Eugeny__, Вы писали:

E> H>Открой для себя уже флешки и portable applications... А вообще, сейчас, все решается сильно проще -- маленькими и легкими нетбуками.

E> Не, мне веб удобнее.
E> И да, уже есть приложения, работающие под винды, макоси, линуха, и разнообразные мобильные системы, при этом переносимые? Я на почту захожу с разных систем(дома и на работе с линухов/винды, в гостях может быть и макось, в поездках с симбиана).

Чтоб, и на мобилках, и на десктопах... это вряд ли. Вот тут, нетбук, все же, будет лучшим решением. Правда таскать надо... правда есть совсем компактные модельки

(уже планируют смарты на x86, т.ч. счастье не за горами

)

E> H>Как-то я пытался зайти на гуглопочту Оперой... Гуглапочта сказала, что не любит мой браузер.

E> Я только оперой и пользуюсь. Давно, видимо, описанное было.

Да давненько...

E> Мы в разных странах

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

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

E> E>> У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.

E> Вероятность таких событий сильно меньше вероятности потерять флешку

.

Я бы не был столь уверен... За всю жизнь я не потерял ни одной флэшки, а у гугла это не первый косяк, насколько мне помнится. Не, если ничего важного в почте нет, как ты говоришь, то и опасаться не стоит конечно.

avalon 1.0rc2 rev 272

Здравствуйте, Eugeny__, Вы писали:

E__>>>У оффлайн клиентов сейчас ни одного преимущества перед веб интерфейсом.
CC>>-1

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

E__>Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.
А у нас не очень давно в рабочий день с утреца родной и любимый белтелеком устроил всем бдыщ на внешний мир на пару часов.
Работа нафиг стала. SVN был в забугорье и слить то, что наколбасили наши забугорные парни было никак.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, hattab, Вы писали:

E>> Вероятность таких событий сильно меньше вероятности потерять флешку

.

H>Я бы не был столь уверен... За всю жизнь я не потерял ни одной флэшки, а у гугла это не первый косяк, насколько мне помнится. Не, если ничего важного в почте нет, как ты говоришь, то и опасаться не стоит конечно.

Ну, кому что

Я и телефонов-то более десятка провтыкал, а уж мелочи вроде флешек... Потерял, кому-то отдал, где-то оставил — не счесть. Бляго, стоят они как говно, так что я не заморачиваюсь.

Здравствуйте, CreatorCray, Вы писали:

CC>А у нас не очень давно в рабочий день с утреца родной и любимый белтелеком устроил всем бдыщ на внешний мир на пару часов.
CC>Работа нафиг стала. SVN был в забугорье и слить то, что наколбасили наши забугорные парни было никак.

Очщерт, 2 часа!! Какая потеря! Целых два часа не работали, беда-беда

На самом деле ситуации, когда от того, отправишь ли мыло прямо сейчас, или через час, очень много зависит, очень, очень редки. Как и ситуации с единым монополистом-провайдером в стране. У нас на работе тоже как-то отрубился инет, а надо было как можно скорее одну штуку в инете глянуть. Подключил телефон да посмотрел.

Здравствуйте, Eugeny__, Вы писали:

CC>>А у нас не очень давно в рабочий день с утреца родной и любимый белтелеком устроил всем бдыщ на внешний мир на пару часов.
CC>>Работа нафиг стала. SVN был в забугорье и слить то, что наколбасили наши забугорные парни было никак.

E__>Очщерт, 2 часа!!
"Пара часов" в данном случае означало "несколько часов".

E__> Какая потеря! Целых два часа не работали, беда-беда

За то время у тех пацанов настала конкретная ночь, и уже фиг созвонишься, обсудишь и т.п.

E__>На самом деле ситуации, когда от того, отправишь ли мыло прямо сейчас, или через час, очень много зависит, очень, очень редки. Как и ситуации с единым монополистом-провайдером в стране. У нас на работе тоже как-то отрубился инет, а надо было как можно скорее одну штуку в инете глянуть. Подключил телефон да посмотрел.
Тут рубанулась вся страна. В телефоне та же фигня.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, LuciferSaratov, Вы писали:

LS>Здравствуйте, alpha21264, Вы писали:

A>>Не тормозит. РМ 1200 МГц. Вентилятор иногда жужжит, но отрисовка не тормозит.

A>>И вообще, КДЕ показывает что большую часть времени он работает на частоте 300 МГц.

LS>У тебя там поди Noscript с AdBlock'ом, которые львиную долю тормозов со страниц вырезают.
LS>Ну и тормоза — дело субъективное, я все же думаю, что на мощном процессоре все это будет работать заметно приятнее. Я вот замечаю, что страницы на нетбуке рисуются тормознее, чем на десктопной машине.

Я таких умных слов не знаю

Факт тот, что железяка+софт работают и "делают то, что надо".

Здравствуйте, vdimas, Вы писали:

V>>>На сегодня это означает 3 бинарника вместо одного.

PD>>При инсталляциии поставится та, что нужно. Примерно так же , как с локализацией, например.
PD>>Или один бинарник и несколько вариантов DLL, в которую и вынесено все, что depends.

V>По click-once тащить надо сразу все. Вот и получается, что вместо обычной линковки к DLL начинаем приседать с плагинной архитектурой или ручками GetProcAddress(). А точек входа — под 50...

А ручками то зачем? Все это сто лет как умеет делать компилятор/линкер, всего-то хук, выбирающий нужную dll для delay load написать надо.

Здравствуйте, CreatorCray, Вы писали:

E__>>На самом деле ситуации, когда от того, отправишь ли мыло прямо сейчас, или через час, очень много зависит, очень, очень редки. Как и ситуации с единым монополистом-провайдером в стране. У нас на работе тоже как-то отрубился инет, а надо было как можно скорее одну штуку в инете глянуть. Подключил телефон да посмотрел.
CC>Тут рубанулась вся страна. В телефоне та же фигня.

У Белтелекома что, одна единственная точка подключения к мировому инету? В той же Украние их хватет, причем далеко не все они принадлежат Укртелекому. Конечно, казусы бывают — я помню, как упал канал Донецк-Киев, дык роуты из Донецка на киевские хосты шли через Симферополь, Турцию, Китай и т.д., жесть была

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, sndanil, вы писали:

s>> Full HD Video? Crysis (и еще целая куча игрушек)?
S>Так и запишем: для развлечений.

Visual Studio 2010

VmWare Fusion

Здравствуйте, Mamut, Вы писали:

M>Мнэээ. И? HTML с минимум скриптов может оказаться менее ресурсоемким и менее тормозным, чем аналогичный сайт на Silverlight'е. GMail — это, конечно, экстрим, но где гарантия, что аналог на Silverlight'е будет лучше по производительности?

По крайней мере silverlight быстрее флеша.

Надеюсь хотя бы его он точно убьет.

Здравствуйте, koandrew, Вы писали:

K>Именно поэтому я не называл эти блоки отдельными ядрами, а "микроядрами". Это типа как в Cell — одно полноценное ядро + кучка вычислительных.

Глубоко пофиг относительно обсуждаемого.

K>Спекулировать по поводу содержимого чипа не буду — ибо даташит найти в открытом доступе я не сумел. По сути, всё, что я нашёл, это страница продукта: http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=26&Level=3&Conn=2&ProdID=238

Ты сам-то по ссылке читал что написано? Это SoC, т.е. не процессор, а целый модуль из нескольких процессоров и периферии. Это примерно то же, чем отличается микропроцессор от микроконтроллера. Да плевать, какой там ЦПУ, судя по описанию, там более одного периферийного процессора в этой системе. Я тебе просто, для развития твоей эрудиции рассказываю, как строят т.н. "аппаратные декодеры видео", чтобы ты в следующий раз ерунду на весь интернет не писал. Понимаешь, в любом случае, какое бы там ядро или даже несколько ядер не было, какая бы система команд не была — это все не принципиально. Принцип построения этих декодеров вовсе не аппаратный, а обычный программный. Я когда-то много лет назад писал на асме для всякой embedded всячины, так что характерно, что последние лет 10 никто даже на асме не пишет. Программы для т.н. "аппаратных декодеров" пишут на языке не ниже чем С, а то и EC.

K>"Зайдя" на плейер по телнету, выяснил, что CPU там MIPS, при этом загрузка его при просмотре фильма в районе нуля, из чего можно сделать вывод о наличии там специализированного процессора для обработки видео. Т.е. ваша теория о DSP не выдерживает проверку практикой — там определённо что-то специфическое.

Да, там более одного периферийного процессора, только как ты собрался с помощью этой информации подтвердить, что мы имеем дело именно с аппаратным декодером?

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

K>Опять же практика частично опровергает ваши слова...

Ась?

Приветствую, Demandred, вы писали:

D> S>Так и запишем: для развлечений.

D> Visual Studio 2010

Гы, чувак, ты понимаешь что это тупо текстовый редактор с подсветкой и дополнительными фичами, которые не работают все время?
То что оно требует дохрена ресурсов — говорит только о известной проблеме с руками разработчиков.
Вот серьезно, сам подумай — зачем IDE столько ресурсов?

D> VmWare Fusion

Ну наконец то.
Молодец, возьми с полки пирожок. Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.

А вообще, с возвращением тебя из бана

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, vdimas, Вы писали:

V>Ты сам-то по ссылке читал что написано? Это SoC, т.е. не процессор, а целый модуль из нескольких процессоров и периферии. Это примерно то же, чем отличается микропроцессор от микроконтроллера. Да плевать, какой там ЦПУ, судя по описанию, там более одного периферийного процессора в этой системе. Я тебе просто, для развития твоей эрудиции рассказываю, как строят т.н. "аппаратные декодеры видео", чтобы ты в следующий раз ерунду на весь интернет не писал. Понимаешь, в любом случае, какое бы там ядро или даже несколько ядер не было, какая бы система команд не была — это все не принципиально. Принцип построения этих декодеров вовсе не аппаратный, а обычный программный. Я когда-то много лет назад писал на асме для всякой embedded всячины, так что характерно, что последние лет 10 никто даже на асме не пишет. Программы для т.н. "аппаратных декодеров" пишут на языке не ниже чем С, а то и EC.

Я очень хорошо представляю, о чём говорю, ибо написание таких прошивок — это одна из моих специальностей в ВУЗе. Возможно, вы не так меня поняли. Я не гвоорил о том, что все операции сделаны "в железе" — так действительно мало кто делает. Но мой поинт был в другом — чтобы декодирование работало с приемлемой скоростью, там должны выполняться аппаратно (или "микроядерно") хотя бы самые тяжёлые операции. Т.е. грубо говоря, разработчик прошивки должен иметь в своём распоряжении "достаточно железа", чтобы он смог запрограммировать его на выполнение задачи.

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

Я в курсе этого, более того, сам лично занимался программированием PLD и неплохо представляю, что можно сделать на их основе. Но так же мне известно и то, что на их основе сделать нельзя — основная проблем таких схем — это их обычно хреновое быстродействие, потому что "программирование", как правило, не учитывает аналоговые эффекты, связанные со взаимным расположением вентилей, которые иногда капитально убивают быстродействие чипа.
Но всё это не имеет к изначальному вопросу ровным счётом никакого отношения, ибо рассматриваемый чип явно построен по "заказному" маршруту...

Здравствуйте, koandrew, Вы писали:

K>Я очень хорошо представляю, о чём говорю, ибо написание таких прошивок — это одна из моих специальностей в ВУЗе. Возможно, вы не так меня поняли. Я не гвоорил о том, что все операции сделаны "в железе" — так действительно мало кто делает. Но мой поинт был в другом — чтобы декодирование работало с приемлемой скоростью, там должны выполняться аппаратно (или "микроядерно") хотя бы самые тяжёлые операции. Т.е. грубо говоря, разработчик прошивки должен иметь в своём распоряжении "достаточно железа", чтобы он смог запрограммировать его на выполнение задачи.

Что есть "достаточно" железа? Сколько должно быть АЛУ в обычном среднестатистическом современном DSP?

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

K>Я в курсе этого, более того, сам лично занимался программированием PLD и неплохо представляю, что можно сделать на их основе. Но так же мне известно и то, что на их основе сделать нельзя — основная проблем таких схем — это их обычно хреновое быстродействие, потому что "программирование", как правило, не учитывает аналоговые эффекты, связанные со взаимным расположением вентилей, которые иногда капитально убивают быстродействие чипа.

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

И не надо вводить лишних признаков водораздела, термин "микропрограмма" — это аналог термина firmware, то бишь более точный аналог этого термина — "прошивка". Как пример микропрограммы обычно приводят ПО в сотовых телефонах или BIOS, идущий на материнках. Т.е., если думаешь, что "микропрограммы" исключительно относятся ко временам микропрограммных процессоров, то это не так.

И ты же не будешь утверждать, что службы BIOS, или вот эта его конфигурационная программа, которую можно вызвать на старте, или менюхи в твоем сотовом — это все "железячное" исполнение?

K>Но всё это не имеет к изначальному вопросу ровным счётом никакого отношения, ибо рассматриваемый чип явно построен по "заказному" маршруту...

Короче, никаких аппаратных декодеров видео в природе не существует, и, надеюсь, никогда не появится. Более того, никто не будет ради кодека разрабатывать процессор с 0-ля какими-то мифическими микроядрами, ведь с этим связана еще и разработка tool chain, что может оказаться дороже разработки процессора. Поэтому обычно берут готовое ядро какого-нить обкатанного недорогого DSP вчерашнего/позавчерашнего дня, тоже самое для ЦПУ — обычно берут готовое ядро позавчерашнего дня. Во-первых — дешевле, во-вторых — надежней, в третьих — на современном процессе эту же схему ядра можно заставить работать на более высокой частоте. А другого пути выпускать электронику по разумным ценам и нет.

Если под каждый медиаплеер разрабатывать свое ядро DSP, он будет стоить гораздо дороже любого десктопа.

Да, SoC популярны уже более 20-ти лет, ибо позволяют удешевить электронику. Но это ничего не меняет, там такие же циклы разработки ПО, как и везде.

Здравствуйте, Sheridan, Вы писали:

S>Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.

Вообще-то, особенности защищенного режима x86-го не позволяют реализовать виртуализацию действительно эффективно. Для сравнения, разработанная около 40 лет назад СВМ для ЕС ЭВМ (полностью советская разработка), могла поддерживать теоретически бесконечную вложенность операционных систем на основе СВМ, ввиду того, что виртуализируемая машина работала практически с той же скоростью, что и невиртуализируемая из-за особенностей архитектуры драйверов и организации управления памятью.

Достаточно сказать, что СВМ умела отображать страницы памяти на несколько независимых процессов в нескольких виртуальных ОС на сколь угодную по счету вложенную виртуальную "матрешку", поэтому использование разделяемых загруженных бинарных образов было весьма эффективное с т.з. использования ОП.

В х86-x64 такое невозможно, поэтому да, остается гнать производительность и расширять адресное пространство.

Здравствуйте, Eugeny__, Вы писали:

E__>У Белтелекома что, одна единственная точка подключения к мировому инету?
У нас белтелеком — единственная точка подключения к внешке.
И сдохло тогда в самом белтелекоме.
Вот такой у нас трындец.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Eugeny__, Вы писали:

E__>... На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.

Это, наверное, никому не нужно, а вот спамить с твоего аккаунта могут начать по-черному.

Здравствуйте, Sheridan, Вы писали:

A>> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел?
S>Про криптоапи забыл?
то есть еще и все модули приплетаем?

A>> думаю не сильно ошибусь, если скажу что практически ничего. то что там используется в системной части с управлением кэшированием, быстрыми вызовами и прочим на асме прописано руками. но если надо, могу собрать ядро с нужными опциями и проверить где там тобой перечисленное.
S>Это уже интереснее. Давай.
чего давать-то?
объяснишь зачем вот это:

# prevent gcc from generating any FP code by mistake
KBUILD_CPLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)

в arch/x86/Makefile?

A>> S>Хотя можешь этого не делать. Я не парюсь и просто выбираю тип процессора в конфигураторе. Мне это совсем несложно.
A>> И это говорит человек, который требует от других знать как ОС работает внутри

Кстати, выбор в конфигураторе таки влияет, но sse тут не причём.
S>Ну так расскажи мне, что там при чем, а я послушаю.
там mtune причём, gcc знает всё же особенности процов, не относящиеся к расширенным наборам команд вроде sse, и пользует их

A>>Кроме того — а ты точно уверен, что оно не будет *медленнее*?

S>Я несколько раз наблюдал увеличение производительности и ни разу — снижения.
о, сравнивал значит, ну тогда всё хорошо.

Здравствуйте, vdimas, Вы писали:

A>>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
V>Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.
а ты собрался в ядре вещественные обсчитывать на FPU/SSE?
расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .

Приветствую, Antikrot, вы писали:

A> расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .

Выбрать тип процессора. Компилятору подставляется -mcpu=..., а это в свою очередь включает нужные флаги.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

A>> расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .
S>Выбрать тип процессора. Компилятору подставляется -mcpu=..., а это в свою очередь включает нужные флаги.
да ну? выбрал, добавилось mtune=core2, а вот про "нужные флаги" я тебе мягко намекнул выше — архитектурный мейкфайл их явно отключает, но всякий случай.

Приветствую, Antikrot, вы писали:

A> A>> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел?
A> S>Про криптоапи забыл?
A> то есть еще и все модули приплетаем?
Не люблю модули, все в компиливаю в ядро.

A> объяснишь зачем вот это:
A> в arch/x86/Makefile?

Объяснений не нашел

A> S>Ну так расскажи мне, что там при чем, а я послушаю.

A> там mtune причём, gcc знает всё же особенности процов, не относящиеся к расширенным наборам команд вроде sse, и пользует их
Ну про mtune я всетаки в курсе.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

PD>Компилятор VC делать SSE коды умеет

И как этого добиться без "asm"?

Здравствуйте, Timur_SPB, Вы писали:

PD>>Компилятор VC делать SSE коды умеет

T_S>И как этого добиться без "asm"?

1. /arch:[SSE|SSE2] и надеяться, что компилятор будет их использовать.
2. intrinsic — функции. Например,

_mm_add_ps
Adds the four single-precision, floating-point values of a and b.
__m128 _mm_add_ps(__m128 a , __m128 b );

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Константин Б., Вы писали:

E__>>>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

КБ>>И не страшно вот так на всех компах пароль свой оставлять?

E__>Ну, во-первых, я доверяю людям, с компов которых захожу в почту.

Трояны-кейлогеры и у очень хороших людей бывают

E__>Во-вторых, почта у меня дублируется на другой ящик с другим паролем(т.е. я ничего не потеряю в случае чего), а никакого компромата в почте на меня нет, и скрывать мне там нечего. На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.

Если этот ящик используется для восстановления паролей то потерять можно ого-го сколько.

Здравствуйте, Eugeny__, Вы писали:

E__>Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.

Мало ты ездишь по просторам нашей страны

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Sheridan, Вы писали:

s>>> а ты что ожидал в списке задач обычного юзера? научные расчеты?
S>>Домашняя бухгалтерия, "умный дом" например. Управление автомобилем в конце концов. Ей богу, лучше бы автопилот автомобилям сделали вместо говноигр и мегаХД.
K>А ты купи себе 40+-дюймовую FullHD LCD панельку и вруби там SD-фильм, а потом тот же фильм — в 1080p/i. Тогда ты про "мегаХД" по-другому заговоришь...

Извините уж, что вклиниваюсь... Но просмотр Full HD космических мощностей не требует — можете поизучать начинки аппаратных плееров.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Mamut, Вы писали:

V>Ты уверен, что знаешь, о чем говоришь? Вот как раз на днях недавно было обсуждение процов и там готовый пример распараллеливания перемножения матриц. http://www.rsdn.ru/forum/education/3775892.1.aspx
V>Переведи на Эрланг. Сравни кол-во кода и быстродействие. Понимаешь, распараллеливание в Эрланге хорошо там, где мы много автоматов "разворачиваем" из логики потактового хождения по состояниям в обычный код, и упомянутые "сообщения" и "синхронизация" в этом контексте — обычные сигналы, которыми автоматы обмениваются друг с другом. Что же касается числодробилок, то распараллеливание там предметнозависимо, т.е. нагрузка на прикладную часть все равно выходит больше, чем на языковую. Поэтому пока языки не очень помогают, зато хорошо помогают библиотеки заготовок для распараллеливания частовстречающихся вычислительных сценариев.

Можно, я свои 3 копейки добавлю ?

Я вообще не верю, что какое бы то ни было более или менее автоматическое распараллеливание возможно. Хоть на С++, хоть на C#, хоть на Эрланге. Дело в том, что при распараллеливании мы сталкиваемся с проблемами, в которых порой надо искать совсем не тривиальное решение. И одна из серьезнейших проблем тут — наличие кеша памяти у каждого ядра и все, что из этого вытекает.

Возьмем кеширование файлов. Процессов много, а страница RAM для кеша данного куска данного файла одна, так что никаких проблем. А теперь представь себе, что каждый процесс свою копию имеет (перенесем кеширование на уровень процесса

. Тут такое начнется, что мама не горюй. А ведь именно это мы и имеем для кэш-памяти.

А еще синхронизация и шедулинг на уровне ОС. Стандартный шедулинг на то и стандартный, чтобы работать более или менее прилично в среднем. Всегда найдется пример, когда он не будет работать наилучшим способом, один ты привел. А кстати, что такое фиберы, как не попытка взять шедулинг на себя ? С известными ограничениями, конечно.

Мне в моем примере с перемножением матриц хорошо. Там не нужно синхронизации. Там нет изменения общих данных. Поэтому там все просто. И все равно пропорциональное числу ядер ускорение не достигается, меньше. А когда все это появится, то если мы хотим получить серьезное улучшение, то нужна филигранная подстройка под задачу. Тот же, к примеру, IOCompletion port использует принцип LIFO для выбора потока, которому отдать новую работу, и не случайно.

Так что все не так уж просто, и надеяться, что написав нечто вроде .AsParallel, мы сразу получим ускорение в N раз, очень наивно.

Здравствуйте, koandrew, Вы писали:

K>Напиши плейер и кодеки, которые сумеют декодировать 1080p H264+DD/DTS звук в реальном времени на 800 МГц проце — тебе памятник при жизни поставят. А языком чесать — это не мешки таскать...

Ты точно ничего не путаешь?
Вот характеристики одного из плееров: http://pokazal.ru/v.php?id=678dda4089ffb1691a76e04dd8e3c2a8
Цитирую:

512 Mb DDR2 DRAM, 256 Mb Hand Flash
667 MHz CPU with floating point coprocessor

Здравствуйте, CreatorCray, Вы писали:

CC>Спецом поставил HL2 и померял потребление памяти.
CC>http://img69.imageshack.us/img69/860/hl2memory.png
CC>Из картинки видно, что сам HL2 потребил 485.13 Mb основной памяти и 223.85 Mb видеопамяти.

А ты не думал, что потребление будет зависеть от общего количества доступной памяти?
Если что, все содержимое Orange Box'а я прошел на компьютере с видяхой на 128 Мб видеопамяти...

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, koandrew, Вы писали:

K>>Напиши плейер и кодеки, которые сумеют декодировать 1080p H264+DD/DTS звук в реальном времени на 800 МГц проце — тебе памятник при жизни поставят. А языком чесать — это не мешки таскать...

DOO>Ты точно ничего не путаешь?
DOO>Вот характеристики одного из плееров: http://pokazal.ru/v.php?id=678dda4089ffb1691a76e04dd8e3c2a8
DOO>Цитирую:
DOO>

DOO>512 Mb DDR2 DRAM, 256 Mb Hand Flash
DOO>667 MHz CPU with floating point coprocessor

Речь видимо все-таки шла о десктопных х86 процессорах. Двух гигагерц моего AMD Turion x64 для FullHD не хватает.

Здравствуйте, Константин Б., Вы писали:

DOO>>Ты точно ничего не путаешь?
DOO>>Вот характеристики одного из плееров: http://pokazal.ru/v.php?id=678dda4089ffb1691a76e04dd8e3c2a8
DOO>>Цитирую:
DOO>>

DOO>>512 Mb DDR2 DRAM, 256 Mb Hand Flash
DOO>>667 MHz CPU with floating point coprocessor

КБ>Речь видимо все-таки шла о десктопных х86 процессорах. Двух гигагерц моего AMD Turion x64 для FullHD не хватает.
Наверное ты не умеешь их готовить

Абсолютно нормально настраивается Full HD на обычном P4 и даже селероне ~ 2 ГГц — это факт.
И на атоме тоже прекрасно работает.
Но тут все сильно от ПО зависит + возможности видео и звуковой карты.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Demandred, вы писали:

D>> S>Так и запишем: для развлечений.

D>> Visual Studio 2010

S>Гы, чувак, ты понимаешь что это тупо текстовый редактор с подсветкой и дополнительными фичами, которые не работают все время?
S>То что оно требует дохрена ресурсов — говорит только о известной проблеме с руками разработчиков.
S>Вот серьезно, сам подумай — зачем IDE столько ресурсов?

Тут ты неправ. Погугли на тему intellisense.
А еще лучше почитай поподробнее про фишки новой студии.

D>> VmWare Fusion

S>Ну наконец то.
S>Молодец, возьми с полки пирожок. Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.

S>А вообще, с возвращением тебя из бана

Так я давно не в бане, просто тем интересных давно небыло

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Константин Б., Вы писали:

DOO>>>Ты точно ничего не путаешь?
DOO>>>Вот характеристики одного из плееров: http://pokazal.ru/v.php?id=678dda4089ffb1691a76e04dd8e3c2a8
DOO>>>Цитирую:
DOO>>>

DOO>>>512 Mb DDR2 DRAM, 256 Mb Hand Flash
DOO>>>667 MHz CPU with floating point coprocessor

КБ>>Речь видимо все-таки шла о десктопных х86 процессорах. Двух гигагерц моего AMD Turion x64 для FullHD не хватает.
DOO>Наверное ты не умеешь их готовить

DOO>Абсолютно нормально настраивается Full HD на обычном P4 и даже селероне ~ 2 ГГц — это факт.
DOO>И на атоме тоже прекрасно работает.
DOO>Но тут все сильно от ПО зависит + возможности видео и звуковой карты.

от материала зависит. FullHD тоже разное бывает. С непорезанным битрейтом не поспоришь — если там честные 50М/с то и атому и p4 будет труба. Выручить может только декодирование на видеокарте наверное

Я вот тоже удивляюсь, дома коробочка от Egreat — так там мипс на 300МГц вместо цп. А HD показывает. Правда с преобразованием на лету из 720р в 1080р не справляется

Здравствуйте, DOOM, Вы писали:

КБ>>Речь видимо все-таки шла о десктопных х86 процессорах. Двух гигагерц моего AMD Turion x64 для FullHD не хватает.
DOO>Наверное ты не умеешь их готовить

DOO>Абсолютно нормально настраивается Full HD на обычном P4 и даже селероне ~ 2 ГГц — это факт.
DOO>И на атоме тоже прекрасно работает.
DOO>Но тут все сильно от ПО зависит + возможности видео и звуковой карты.

Если используется для декодирования видео-карты, причём с атом+ION тебе нормально декодируют, а вот интеловское видеоядро(даже последнее) может и не справиться.

DOO>>>512 Mb DDR2 DRAM, 256 Mb Hand Flash
DOO>>>667 MHz CPU with floating point coprocessor

КБ>>Речь видимо все-таки шла о десктопных х86 процессорах. Двух гигагерц моего AMD Turion x64 для FullHD не хватает.

DOO>Наверное ты не умеешь их готовить

Здравствуйте, DOOM, Вы писали:

DOO>А ты не думал, что потребление будет зависеть от общего количества доступной памяти?
Не зависит.
А зависит от объёма тех данных которые нужны для работы.
На меньших доступных объёмах может срабатывать какой либо механизм загрубления качества или стриминг.
В HL2 насколько мне известно стриминга нет — геометрия уровня в память грузится целиком. Текстуры могут подкачиваться, но это сразу тормоза.

DOO>Если что, все содержимое Orange Box'а я прошел на компьютере с видяхой на 128 Мб видеопамяти...
Со всеми настройками на High? И не тормозило, стабильные 60 FPS?
Не верю.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Константин Б., Вы писали:

КБ>Ты наверное путаешь "на процессоре" и "на компьютере с процессором".
Ты наверное уже буквоедством занимаешься

Сейчас выяснится, что вместо HDD у нас дисководы и никакое Full HD уже не светит по определению

Здравствуйте, CreatorCray, Вы писали:

CC>Со всеми настройками на High?
нет конечно...
CC>И не тормозило, стабильные 60 FPS?
С таймером не стоял — но отличительная особенность движка HL заключается как раз в том, что он не допускает выпадения кадров, а плавно замедляет весь геймплей в целом (кстати, это же хорошо делают ребята из близзард — я на 486-м играл в Starcraft).

Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, Eugeny__, Вы писали:

E__>>... На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.

P>Это, наверное, никому не нужно, а вот спамить с твоего аккаунта могут начать по-черному.

До момента, когда я его восстановлю.

Здравствуйте, Eugeny__, Вы писали:

E__>>>... На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.

P>>Это, наверное, никому не нужно, а вот спамить с твоего аккаунта могут начать по-черному.

E__>До момента, когда я его восстановлю.

Кстати, сейчас вот подумал. В 99% случаев я захожу на почту не с винды, и не самым популярным браузером(да и в винде никто из знакомых, как и я, тем же IE не пользуются, все на Опере), что, как мне кажется, еще сильнее уменьшает возможность потери ящика.

Здравствуйте, Константин Б., Вы писали:

E__>>>>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.

КБ>>>И не страшно вот так на всех компах пароль свой оставлять?

E__>>Ну, во-первых, я доверяю людям, с компов которых захожу в почту.

КБ>Трояны-кейлогеры и у очень хороших людей бывают

Да, да, особенно под линухи и прочие макоси

.
Впрочем, захожу, бывает и с винды, так что некоторая опастность есть.

E__>>Во-вторых, почта у меня дублируется на другой ящик с другим паролем(т.е. я ничего не потеряю в случае чего), а никакого компромата в почте на меня нет, и скрывать мне там нечего. На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.

КБ>Если этот ящик используется для восстановления паролей то потерять можно ого-го сколько.

Я использую оригинальную система паролей, в которой пароль является функцией от url сайта, на котором он вводится. Без знания этой функции догадаться практически невозможно(а знаю ее только я), зато я никогда не забываю паролей(ибо генерю их в уме, глядя на урл). Пароли, кстати, выходят хорошие, криптостойкие. Последний раз восстанавливал пароль оооочень давно(лет 6 назад), на каком-то ресурсе, на котором регился еще до придумывания этой системы. Так что...

Здравствуйте, DOOM, Вы писали:

E__>>Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.
DOO>

DOO>Мало ты ездишь по просторам нашей страны

Ну, наверное. В последнее время география поездок ограничивается Донецком, Харьковом и Москвой. Да, согласен, что выборка в плане интернета получается не очень.

Здравствуйте, Sheridan, Вы писали:

D>> Visual Studio 2010

S>Гы, чувак, ты понимаешь что это тупо текстовый редактор с подсветкой и дополнительными фичами, которые не работают все время?

Гы, чувак, а ты понимаешь, что современный процессор — это тупо кусок кремния. Ясен пончик, тупой текстовый редактор очень тупо работает на тупом куске тупого кремния!

Кстати, электролокомотив — это тупо дрезина с электродвигателем, и дополнительными фичами (не все из которых постоянно используются). Почему такая разница в цене — я в недоумении...

S>То что оно требует дохрена ресурсов — говорит только о известной проблеме с руками разработчиков.
S>Вот серьезно, сам подумай — зачем IDE столько ресурсов?

Анализ кода на лету, например.

Тут некоторые деятели, не будем указывать пальцем, рассказывали, что, дескать, IDE 80х годов были ничуть не хуже. Но это кажется ровно до тех пор, пока не поработаешь в них снова. Я недавно поработал в VS2003, и после VS2008 оказалось весьма неудобно. Хотя на первый взгляд — вообще то же самое.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Sheridan, Вы писали:

A>> A>> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел?
A>> S>Про криптоапи забыл?
A>> то есть еще и все модули приплетаем?
S>Не люблю модули, все в компиливаю в ядро.
Бгг. Так у тебя под "ядром" понимается вся эта туева хуча всего_что_может_пригодиться_и_я_это_вкомпилил?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, DOOM, Вы писали:

DOO>И на атоме тоже прекрасно работает.
FullHD (1080p) на атоме с HT 1.6Gz все таки сильно дёргается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, DOOM, Вы писали:

CC>>И не тормозило, стабильные 60 FPS?
DOO>С таймером не стоял — но отличительная особенность движка HL заключается как раз в том, что он не допускает выпадения кадров, а плавно замедляет весь геймплей в целом
Я запускал HL2 на встроенном видео — всё как и должно быть, картинка дёргается но геймтик не изменяется. Ничего он не замедляет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, fmiracle, Вы писали:

F>Тут некоторые деятели, не будем указывать пальцем, рассказывали, что, дескать, IDE 80х годов были ничуть не хуже. Но это кажется ровно до тех пор, пока не поработаешь в них снова. Я недавно поработал в VS2003, и после VS2008 оказалось весьма неудобно. Хотя на первый взгляд — вообще то же самое.
Ты уточняй что использовал то: С++ или С#.
Потому как для С++ что 2003 что 2008 — один хрен. У меня пара проектов под 2003 и один под 2008. Разницы в юзабилити никакой (и там и там стоит VAX)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, fmiracle, Вы писали:

F>>Тут некоторые деятели, не будем указывать пальцем, рассказывали, что, дескать, IDE 80х годов были ничуть не хуже. Но это кажется ровно до тех пор, пока не поработаешь в них снова. Я недавно поработал в VS2003, и после VS2008 оказалось весьма неудобно. Хотя на первый взгляд — вообще то же самое.
CC>Ты уточняй что использовал то: С++ или С#.
CC>Потому как для С++ что 2003 что 2008 — один хрен. У меня пара проектов под 2003 и один под 2008. Разницы в юзабилити никакой (и там и там стоит VAX)

Ну да, С#.
Под плюсами давным давно уже не работал

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Приветствую, CreatorCray, вы писали:

CC> Бгг. Так у тебя под "ядром" понимается вся эта туева хуча всего_что_может_пригодиться_и_я_это_вкомпилил?
Я буквоедством не страдаю.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, vdimas, Вы писали:

A>>>>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX
V>>>Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.
A>>а ты собрался в ядре вещественные обсчитывать на FPU/SSE?
V>Ты уверен, что расширения SSE только вещественные числа считают?
это был вопрос с подвохом, ты клюнул

разница-то какая, если задействованы регистры st/mm/xmm? ну нельзя их автоматом генерить в ядерном коде просто так.

A>>расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .
V>Зачем тебе эта утилита для нубов?
ну доставай что-ли линейку уже...

V>Не понимаешь мейкфайлов?
читаем фрагмент мейкфайла здесь до просветления.

Здравствуйте, Antikrot, Вы писали:

A>это был вопрос с подвохом, ты клюнул

разница-то какая, если задействованы регистры st/mm/xmm? ну нельзя их автоматом генерить в ядерном коде просто так.

Это опять нубство, вот такой уровень общения. Что, где и почему нельзя? Давай по полочкам, а не вот этот бесполезный пинг-понг. Просто ты не прав категорически, но мне интересен ход твоих мыслей.

A>>>расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .
V>>Зачем тебе эта утилита для нубов?
A>ну доставай что-ли линейку уже...

Ну просто это как бэ идиотизм получается. Мало ли что с того, что эта утилита не умеет конфигурить все опции gcc. Как это может служить аргументом и какое вообще имеет отношение к обсуждаемому?

V>>Не понимаешь мейкфайлов?
A>читаем фрагмент мейкфайла здесь до просветления.

Смешно. Ты бы хоть поинтересовался, почему так, а не "читал до просветления"... Мде...

Здравствуйте, vdimas, Вы писали:

A>>это был вопрос с подвохом, ты клюнул

разница-то какая, если задействованы регистры st/mm/xmm? ну нельзя их автоматом генерить в ядерном коде просто так.
V>Это опять нубство, вот такой уровень общения. Что, где и почему нельзя? Давай по полочкам, а не вот этот бесполезный пинг-понг. Просто ты не прав категорически
опровергай. аргументов не видно.

Здравствуйте, Antikrot, Вы писали:

A>>>это был вопрос с подвохом, ты клюнул

разница-то какая, если задействованы регистры st/mm/xmm? ну нельзя их автоматом генерить в ядерном коде просто так.
V>>Это опять нубство, вот такой уровень общения. Что, где и почему нельзя? Давай по полочкам, а не вот этот бесполезный пинг-понг. Просто ты не прав категорически
A>опровергай. аргументов не видно.

Я пока не вижу что опровергать, т.к. ты вообще еще ничего по делу не сказал.

Мое мнение:
Есть дополнительные инструкции процессора? — Есть.
Работают? — Очень даже хорошо работают.
Преценденты их использования в режиме ядра есть? — Сколько угодно в тех же виндах.

Все, что ты там увидел и чего неожиданно испугался — это всего навсего опции для сборки переносимого ядра. Компилят себе ядро нынче лишь экспериментаторы (коих гораздо меньше 1%), а все остальные пользуют уже сбилженные бинарные инсталляхи. Вот о них-то и беспокоятся. А если ты сам себе экспериментатор и сам собираешь ядро — то компили как хочешь, с любыми опциями, на здоровье.

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

Здравствуйте, Eugeny__, Вы писали:

E__>Я использую оригинальную система паролей, в которой пароль является функцией от url сайта, на котором он вводится. Без знания этой функции догадаться практически невозможно(а знаю ее только я), зато я никогда не забываю паролей(ибо генерю их в уме, глядя на урл). Пароли, кстати, выходят хорошие, криптостойкие. Последний раз восстанавливал пароль оооочень давно(лет 6 назад), на каком-то ресурсе, на котором регился еще до придумывания этой системы. Так что...

Что толку от криптостойких паролей, если можно нажать ссылочку "забыл пароль" и получить новый на твой почтовый ящик.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Константин Б., Вы писали:

КБ>>Ты наверное путаешь "на процессоре" и "на компьютере с процессором".
DOO>Ты наверное уже буквоедством занимаешься

Вообще-то это ты занимаешься буквоедством: "Да конечно можно смотреть FullHD на 800 мегагерцовом проце, только вот мы возъмем не обычный CPU, а GPU или специализированный DSP.".

Здравствуйте, Константин Б., Вы писали:

КБ>Вообще-то это ты занимаешься буквоедством: "Да конечно можно смотреть FullHD на 800 мегагерцовом проце, только вот мы возъмем не обычный CPU, а GPU или специализированный DSP.".
Стоп-стоп. Про характеристики GPU или DSP я ни слова не говорил — понятно, что что-то такое на борту тоже есть. Причем не надо думать, что в дешевых аппаратных видеоплеерах стоит что-то особенное — там те же самые железки, что и в обычных десктопах, разве что другого форм-фактора и послабже.
Конечно, на ноутбуке с Вистой и медиаплеером трудно получить FullHD без тормозов — но у связки Linux + mplayer требования уже в разы ниже...

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Константин Б., Вы писали:

КБ>>Вообще-то это ты занимаешься буквоедством: "Да конечно можно смотреть FullHD на 800 мегагерцовом проце, только вот мы возъмем не обычный CPU, а GPU или специализированный DSP.".
DOO>Стоп-стоп. Про характеристики GPU или DSP я ни слова не говорил — понятно, что что-то такое на борту тоже есть. Причем не надо думать, что в дешевых аппаратных видеоплеерах стоит что-то особенное — там те же самые железки, что и в обычных десктопах, разве что другого форм-фактора и послабже.

Это в каком таком обычном десктопе есть Nvidia ION и прочее?

DOO>Конечно, на ноутбуке с Вистой и медиаплеером трудно получить FullHD без тормозов — но у связки Linux + mplayer требования уже в разы ниже...

С чего бы это вдруг?

Я же пробовал — никаких "в разы" не наблюдалось.

Здравствуйте, Константин Б., Вы писали:

E__>>Я использую оригинальную система паролей, в которой пароль является функцией от url сайта, на котором он вводится. Без знания этой функции догадаться практически невозможно(а знаю ее только я), зато я никогда не забываю паролей(ибо генерю их в уме, глядя на урл). Пароли, кстати, выходят хорошие, криптостойкие. Последний раз восстанавливал пароль оооочень давно(лет 6 назад), на каком-то ресурсе, на котором регился еще до придумывания этой системы. Так что...

КБ>Что толку от криптостойких паролей, если можно нажать ссылочку "забыл пароль" и получить новый на твой почтовый ящик.

Да, на этот("рабочий") ящик много всего зарегано, но все это не особо важно. Всякие говносайты, которые требуют для чего-то регистрацию, не особо живые аккаунты на всяких sun, launchpad и пр., да тот же вконтакте, на который я захожу хорошо если раз в месяц. Только потеря этих аккаунтов меня не волнует. Ну и да, эти восстановления паролей придется делать взломщикам вручную, беда в том, что получат они с этого меньше, чем затратили.
"Напоминалки" на более важные ресурсы(как, например, инет-банкинг) я регил на тот, второй ящик, пароль к которому другой, и на который я зайду только в случае ЧП и сделаю это аккуратно. Благо, все важные ресурсы можно пересчитать по пальцам.

Здравствуйте, DOOM, Вы писали:

КБ>>Это в каком таком обычном десктопе есть Nvidia ION и прочее?
DOO>А в каком-таком плеере? Обычно там те же ATI, nvidia, а то и Intel или VIA.

Так и запишем: CPU не используется.

DOO>>>Конечно, на ноутбуке с Вистой и медиаплеером трудно получить FullHD без тормозов — но у связки Linux + mplayer требования уже в разы ниже...
КБ>>С чего бы это вдруг?

Я же пробовал — никаких "в разы" не наблюдалось.
DOO>Недопробовал?

DOO>На самом деле эффект, что называется, налицо. Можно даже без смены ОС — просто поставить какой-нибудь K-lite Codec Pack и выполнить многостраничную инструкцию по настройке — до этого действа на ноуте тормозило даже 720p, после — вполне приемлемо заработало 1080p.

И у этого ноута наверняка был 800мегагерцовый проц

Кстати ссылку можно на эту волшебную инструкцию?

DOO>А фанатизмом с линуксом + заточенное ядро + скомпилированный из исходников mplayer я занимался во времена распространения DivX и компании — реально получилось смотреть фильмы на моем компьютере, который и близко по системным требованиям не подходил..

Фильмы в FullHD?

M>>Да еще желательно не на одном комптютере в сети

И начнутся ручные закаты солнца.

F>надуманная задача, надуманные проблемы..

Вот ненадуманная: http://grey-kristy.livejournal.com/87271.html

Здравствуйте, Mamut, Вы писали:

M>>>Да еще желательно не на одном комптютере в сети

И начнутся ручные закаты солнца.
F>>надуманная задача, надуманные проблемы..
M>Вот ненадуманная: http://grey-kristy.livejournal.com/87271.html

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

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

говорит ли это о производительности питона в многопоточных приложениях?. да нифига, это говорит о кривой реализации на перле..

Здравствуйте, vdimas, Вы писали:

V>>>Это опять нубство, вот такой уровень общения. Что, где и почему нельзя? Давай по полочкам, а не вот этот бесполезный пинг-понг. Просто ты не прав категорически
A>>опровергай. аргументов не видно.
V>Я пока не вижу что опровергать, т.к. ты вообще еще ничего по делу не сказал.
V>Мое мнение:
V>Есть дополнительные инструкции процессора? — Есть.
V>Работают? — Очень даже хорошо работают.
ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.

V>Преценденты их использования в режиме ядра есть? — Сколько угодно в тех же виндах.
я уже Шеридану и в линуксовом ядре показал что и где есть, и *как* оно там используется

V>Все, что ты там увидел и чего неожиданно испугался — это всего навсего опции для сборки переносимого ядра. Компилят себе ядро нынче лишь экспериментаторы (коих гораздо меньше 1%), а все остальные пользуют уже сбилженные бинарные инсталляхи. Вот о них-то и беспокоятся. А если ты сам себе экспериментатор и сам собираешь ядро — то компили как хочешь, с любыми опциями, на здоровье.
ага. с любыми. щаз.

V>Я когда то давно собирал себе минимальное ядро Линуха для кое-какой железки, так вот меня наше обсуждение неприкосновенности опций компилятора просто умиляет, в сравнении с тем, что мы вытворяли с самими исходниками и как кромсали реализации сетевых протоколов, убирая нафик все лишнее.

ты кромсание-то лишнего не сравнивай с генерацией кода

Здравствуйте, Antikrot, Вы писали:

A>ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.

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

Здравствуйте, vdimas, Вы писали:

A>>ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.
V>А как же их сохранение при переключении обычных задач, которые могут их использовать?
вот такая вот оптимизация, всякие xsave вызываются не всегда, всё же не сохранять состояние sse даёт выгоду по времени.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, sndanil, Вы писали:

T>>>Попробуем с другой стороны

Для каких задач обычного юзера не хватало процессоров 10-летней давности?

S>>Full HD Video? Crysis (и еще целая куча игрушек)?

PD>Для игрушек никогда не хватит, на то они и игрушки. Для видео — тоже понятно. Давай что-нибудь из более деловой сферы.

да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок

поясню — это требуется например для оформления прайс-листов

Здравствуйте, mister-AK, Вы писали:

MA>да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок

MA>поясню — это требуется например для оформления прайс-листов

Hint: отключение автоматического пересчета обычно помогает работать с такими документами. Правда в этом #%@#$!% экселе данная опция является не опцией документа, а опцией приложения.

Здравствуйте, mister-AK, Вы писали:

PD>>Для игрушек никогда не хватит, на то они и игрушки. Для видео — тоже понятно. Давай что-нибудь из более деловой сферы.

MA>да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок

Это лишь говорит о том, как хорошо он написан. Вычислить по 2000 * 10 == 20000 формулам — для этого никак без 3GHz и $ Gb обойтись нельзя, разумеется

. Особенно когда формулы содержат , например, расчет зарплаты (невероятно сложный NP-полный алгоритм

Для сведения. В DOS времена не было Excel, а был Supercalc, например. Он как-то умел работать в 640 Кб памяти. Можешь посмотреть, что он умел.

http://www.alex.krsk.ru/199_/1993/1993_08.htm

Дата этого документа внизу — 1993. Windows 95 еще только разрабатывается.

Приветствую, Pavel Dvorkin, вы писали:

PD> Для сведения. В DOS времена не было Excel, а был Supercalc, например. Он как-то умел работать в 640 Кб памяти. Можешь посмотреть, что он умел.

А вот так выглядел. Имхо — очень даже ничего.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Roman Odaisky, Вы писали:

PD>>Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ? Не знаю. Не верю.

RO>Причем здесь Итаниум? А для персоналок ARM наше всё.

ARM наше все для тока для мобильных девайсов. Нетбуков там, с линухами и ChromeOS.

И, как ни странно, для низкопотребляющий фермовых серверов. Продуктов пока нет, но двухядерный Cortex A9, доступный на одной крупной тайваньской фабрике по техпроцессу 45 нм, вчетверо быстрее топового Атома. Суперскалярный (до 4-х инструкций за такт), работает на 2-х гигагерцах, и может быть синтезирован с кэшами L4 до 16 мегабайт. Что наводит на мысли.

Другое дело, что ядро ядром, и хищнические намерения ARM можно понять, но есть проблема. Кто-то должен отважится сделать микросхему для серверных продуктов на этой платформе

. Пока героев я не заметил.

Кстати, если кто узнает про реальную микруху с этим ядром (1-2ГГц, Cortex A9, приличного размера кэши, интегрированные Ethernet-ы и switching fabric, плюс контроллер DDR на 64 бита) — скажите, она мне ппц как нужна, а я не нашел.

Здравствуйте, Gaperton, Вы писали:

G> инструкций за такт), работает на 2-х гигагерцах, и может быть синтезирован с кэшами L4 до 16 мегабайт. Что наводит на мысли.

С кэшами L2, естественно.

Здравствуйте, Gaperton, Вы писали:

G>Кстати, если кто узнает про реальную микруху с этим ядром (1-2ГГц, Cortex A9, приличного размера кэши, интегрированные Ethernet-ы и switching fabric, плюс контроллер DDR на 64 бита) — скажите, она мне ппц как нужна, а я не нашел.

Да, и контроллер PCIe штоб был. Это, в принципе, по предназначению микруха для раутеров-свитчей должна быть. Что по интерфейсам вполне понятно.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, squid, Вы писали:

S>>x86 столь ужасна?

RO>В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть. Соответственно, в 21 веке компилируют программы в машинный код i386.

Почему?
Это кто смотря кто как пишет эти программы.
XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

Приветствую, A13x, вы писали:

A> Почему?
A> Это кто смотря кто как пишет эти программы.
A> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, Antikrot, вы писали:

A> Здравствуйте, Sheridan, Вы писали:

A> A>> Почему?
A> A>> Это кто смотря кто как пишет эти программы.
A> A>> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A> A>> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

A> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A> объясни разницу применительно к "в 21 веке компилируют в код i386"?
Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?

A> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
Постой ка, назови остальные "болееменее серьезные".

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, DOOM, Вы писали:

DOO>Павел. Ей-богу, смешно.
DOO>Весь мир HPC построен на итаниумах — вся линейка HP Integrity, например. Вплоть до Superdome. Если бы HP сказали, что они отказываются от итаниумов в этой линейке — это было бы да.

Интересно, как Вы считаете "весь мир HPC", если, например, в Top500 списке единственный пункт с Itanium это 86-е место? При том, что все прочие распределены с преобладанием x86 и некоторого количества Cell'ов.
Или Вы под HPC имеете в виду что-то другое?

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

Думаю, надо признать следующее:
1. VLIW как идея провалилась.
2. Причины этого провала толком неясны и, видимо, для них понимания нужен или кто-то очень грамотный в теме, или данные изнутри Intel и HP. Потому что, например, когда P4 разгонялись до 4GHz, а итаниумы в это время еле-еле тянули 2GHz — что мешало разогнать вторые? Только маркетинг? Слабо верится.

DOO>А то, что отказывается MS говорит лишь одно — ни асилили. У них была очень ограниченная поддержка. Винды для NUMA систем не было — там был только вариант с HP-UX или OpenVMS и нарезка на партиции, на которых уже винду ставить.

Их "ниасиливают" почти все. Но те, кому смена архитектуры — замена нескольких десятков файлов и небольшое дотачивание компилятора — "асиливают" за счёт разработки на других платформах; к этому классу относятся все юниксы. С Windows так просто не получалось.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Antikrot, вы писали:

A>> расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .

S>Выбрать тип процессора. Компилятору подставляется -mcpu=..., а это в свою очередь включает нужные флаги.

-march, вообще-то. Но это не поможет без дополнительного разрешения. gcc автоматически не генерирует SSE2 и SSE3 вообще. Он может только первый SSE для плавучки, если разрешено.
(Я уж молчу, что в ядре Linux и аналогах использование FPU и SSE* резко ограничено административно. Ибо таки нефиг.)

Здравствуйте, Eugeny__, Вы писали:

S>>thebat, kmail — про них уже както забыли наверное?

E__>Если честно, с появлением гмыла я с радостью отказался от специальных клиентов для почты. Они — тупо лишнее звено. Были актуальны 10 лет назад только потому, что интернет был хреновый и дорогой, и вообще не всегда был, потому копии писем лучше было хранить локально. Сейчас интернет доступен даже в лесу(с телефона), а уж настольных компов без подключения к сети я уже несколько лет в глаза не видел. Поэтому почтовые клиенты для меня напрочь потеряли смысл.

А приватный ключ для подписывания своих сообщений ты тоже хранишь на gmail? ;)
Или ты считаешь, что честному человеку все эти меры не нужны? ;)

Здравствуйте, vdimas, Вы писали:

V>И не надо вводить лишних признаков водораздела, термин "микропрограмма" — это аналог термина firmware, то бишь более точный аналог этого термина — "прошивка". Как пример микропрограммы обычно приводят ПО в сотовых телефонах или BIOS, идущий на материнках. Т.е., если думаешь, что "микропрограммы" исключительно относятся ко временам микропрограммных процессоров, то это не так.

V>И ты же не будешь утверждать, что службы BIOS, или вот эта его конфигурационная программа, которую можно вызвать на старте, или менюхи в твоем сотовом — это все "железячное" исполнение? :)

Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.
Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.

V>Короче, никаких аппаратных декодеров видео в природе не существует, и, надеюсь, никогда не появится. Более того, никто не будет ради кодека разрабатывать процессор с 0-ля какими-то мифическими микроядрами, ведь с этим связана еще и разработка tool chain, что может оказаться дороже разработки процессора. Поэтому обычно берут готовое ядро какого-нить обкатанного недорогого DSP вчерашнего/позавчерашнего дня, тоже самое для ЦПУ — обычно берут готовое ядро позавчерашнего дня. Во-первых — дешевле, во-вторых — надежней, в третьих — на современном процессе эту же схему ядра можно заставить работать на более высокой частоте. А другого пути выпускать электронику по разумным ценам и нет. :xz: Если под каждый медиаплеер разрабатывать свое ядро DSP, он будет стоить гораздо дороже любого десктопа.

Полностью аппаратных декодеров — да, не бывает.
Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.

А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.

Здравствуйте, vdimas, Вы писали:

A>>И это говорит человек, который требует от других знать как ОС работает внутри :))) Кстати, выбор в конфигураторе таки влияет, но sse тут не причём. Кроме того — а ты точно уверен, что оно не будет *медленнее*? ;)

V>Для GCC последних версий — не будет. Кстати, этот зоопарк несовместимых по командам x86-х — реальный аргумент в пользу Шеридана в его агитации собирать все из исходников.

На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач), или i386, в котором даже если ограничиваться уровнем i486 можно получить практически всё необходимое.

У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся. Есть варианты сборки i586 (Mandrake, Alt), i486 (ASP несколько лет назад; не знаю как сейчас). Есть деление на i386 и i686 (RedHat до относительно недавнего; сейчас они оставили только i686). Но никто не предлагает специальный дистрибутив под Pentium4 или CoreDuo только потому, что якобы будет быстрее. Если для какого-то приложения версия процессора крайне важна, оно само себе соберёт версии под конкретный процессор и набор команд (как это делает mplayer). А вот оптимизация генерации кода (-mtune=) идёт под современные процессоры.

Аналогичное слышу про Windows, хотя руками столь подробно не щупал.

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

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, A13x, вы писали:
...
S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?

да. И, соответственно, используется код, написанный с учетом расширений этого процессора.

Приветствую, A13x, вы писали:

A> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A> да. И, соответственно, используется код, написанный с учетом расширений этого процессора.

Можно и так, но это более трудоемкий процесс, хотя и результатов имхо принесет больше.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

A>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?

A>> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
S>Постой ка, назови остальные "болееменее серьезные".
да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.

Здравствуйте, Sheridan, Вы писали:

A>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>> да. И, соответственно, используется код, написанный с учетом расширений этого процессора.
S>Можно и так, но это более трудоемкий процесс, хотя и результатов имхо принесет больше.
чем это он трудоёмкий?
добавить

if (cpuid(1).edx & (1<<26)) {
  idct_sse2(...);
} else {
  idct_i386(...);
}

сложно?

Приветствую, Antikrot, вы писали:

A> чем это он трудоёмкий?
A> добавить
A>

A> if (cpuid(1).edx & (1<<26)) {
A>   idct_sse2(...);
A> } else {
A>   idct_i386(...);
A> }
A>

A> сложно?

Сложнее, чем просто idct(...);

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, Mamut, вы писали:

M> Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!
Мамут, я поражаюсь твоей способности выдергивать из контекста только то, что тебе полезно...

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

M>> Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!
S>Мамут, я поражаюсь твоей способности выдергивать из контекста только то, что тебе полезно...

Я специально отметил это злостным оффтопом и смайликом.

Здравствуйте, Antikrot, Вы писали:

A>Здравствуйте, Sheridan, Вы писали:

A>>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
A>нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
A>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?

Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.

A>>> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
S>>Постой ка, назови остальные "болееменее серьезные".
A>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.

Назови свой кодек, будет понятнее.

Здравствуйте, netch80, Вы писали:

A>>>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>>>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>>>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
A>>нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
A>>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?
N>Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.
это ж не к тебе вопрос был

это мягкий намёк на то, что 95% фанатов source-based в эти сорцы не полезут вообще, а из оставшихся — 95% всё равно не будут знать во что их превратил компилятор.

S>>>Постой ка, назови остальные "болееменее серьезные".
A>>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.
N>Назови свой кодек, будет понятнее.
да я хз. но если в media player classic убрать галочку h264/avc(dxva), жрёт в 7 раз больше cpu.

Здравствуйте, Antikrot, Вы писали:

A>Здравствуйте, netch80, Вы писали:

A>>>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?
N>>Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.
A>это ж не к тебе вопрос был :) это мягкий намёк на то, что 95% фанатов source-based в эти сорцы не полезут вообще, а из оставшихся — 95% всё равно не будут знать во что их превратил компилятор.

Ну, во-первых, действительно какая разница, что там написано, если "результат на лице" — видим, что нечто работало до пересборки медленнее, чем после пересборки?
Для этого результата не нужно ни читать исходники, ни копаться в ассемблере.

С другой стороны, обычно для тех же ~95% фанатов source-based оказывается, что ускорение от пересборки — это чистое плацебо. Потому что собирают не то, что нужно.
Шеридан, кажется, этому тоже частично подвластен, но он хоть наполовину честен:)

S>>>>Постой ка, назови остальные "болееменее серьезные".
A>>>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.
N>>Назови свой кодек, будет понятнее.
A>да я хз. но если в media player classic убрать галочку h264/avc(dxva), жрёт в 7 раз больше cpu.

Понятно. Сраанил бы на чём-то вроде mplayer, которому можно внутрь заглянуть...

Здравствуйте, netch80, Вы писали:

N>Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.

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

N>Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.

Вот и не сбивай с толку упоминаниями об архитектурах процессоров 20-тилетней давности.

Тем более, что это "четкое различие" — полная ерунда с т.з. принципов исполнения, поэтому и не существует разных терминов для одного и того же. Пусть там получилось два уровня исполнения... да хоть десять, это ничего не меняет.

N>Полностью аппаратных декодеров — да, не бывает.
N>Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
N>И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.

Ты реально смотрел состав обсуждаемого SoC, или мы на отвлеченные темы будем разговаривать? Я все равно не поверю, что под некий SoC для бытовой аппаратуры кто-то будет изобретать новые ядра. Ну нереально это — никогда не окупиться. И не смеши ты "железной структурой", пожалуйста, а посмотри бы устройство современных DSP, даже позавчерашнего дня. Уж чего-чего, а вычислительных блоков там хватает с головой.

N>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.

Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:

N>>Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.
V>Во-первых, эти два термина идентичны.

Своим "во-первых" ты тут же постановил "есть два мнения — одно моё, другое неправильное". Зачем тогда вообще о чём-то говорить? Нарисуй себе сайт и выкладывай на нём:)
А если хочешь хоть немного послушать других — попробуй ответить на вопросы:
* BIOS это firmware или нет? (если нет — прошу доказать)
* если firmware исполняется в процессоре как входной язык — как называется то, что внутри?
* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?

V>Во-вторых, Нету уже давно никакого выделенного потока микрокода, там теперь более десятка взаимодействующих автоматов.

Кажется, словосочетание "выделенный поток", которое ты тут опровергаешь, появилось именно в твоей реплике. Я такого не называл и даже не подразумевал. Как я могу это воспринять иначе, чем дискуссионный приём выдвинуть возражение и тут же его разгромить с блеском?

N>>Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.
V>Вот и не сбивай с толку упоминаниями об архитектурах процессоров 20-тилетней давности. :)
V>Тем более, что это "четкое различие" — полная ерунда с т.з. принципов исполнения,

Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

N>>Полностью аппаратных декодеров — да, не бывает.
N>>Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
N>>И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.
V>Ты реально смотрел состав обсуждаемого SoC, или мы на отвлеченные темы будем разговаривать?

Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.

V> Я все равно не поверю, что под некий SoC для бытовой аппаратуры кто-то будет изобретать новые ядра. Ну нереально это — никогда не окупиться. И не смеши ты "железной структурой", пожалуйста, а посмотри бы устройство современных DSP, даже позавчерашнего дня. Уж чего-чего, а вычислительных блоков там хватает с головой.

То есть ситуацию развития DSP иначе как механическим склеиванием ты вообще не предполагаешь?;) Кстати, ограничение тематики именно DSP — опять же от тебя. Тред обсуждал проблему в общем, и DSP, криптография и векторная алгебра здесь частные случаи. Кстати, конкретно меня сейчас DSP вообще не интересует, а вот нужны таймеры типа "зафиксировать значения внутреннего счётчика времени в моменты прихода фронтов по внешней линии, помнить 4 последних значения". Каким DSP я это могу реализовать и накойхер так извращаться?

N>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.

Здравствуйте, netch80, Вы писали:

V>>Во-вторых, Нету уже давно никакого выделенного потока микрокода, там теперь более десятка взаимодействующих автоматов.

N>Кажется, словосочетание "выделенный поток", которое ты тут опровергаешь, появилось именно в твоей реплике. Я такого не называл и даже не подразумевал. Как я могу это воспринять иначе, чем дискуссионный приём выдвинуть возражение и тут же его разгромить с блеском?

Давай мы не будем на этом уровне обсуждать. Довольно подробно архитектура современного интелла расписана и источники открыты. Того единого потока исполнения микрокода, как некоей внутренней "подпрограммы" (чтобы ее именно можно было считать за полноценную микропрограмму, которая была там до пентиума), давно уже нет. Еще раз русским по белому: единый некогда автомат, построенный на микропрограммной технологии, исполняющий входные инструкции, был давно уже усложнен и разобран на составляющие автоматы, 90% которых выполнены именно в классическом железе, т.е. логикой этих автоматов управляет не микропрограмма, а функциональная схема из вентилей. И слово "единого" я добавил не зря, чтобы отсечь спекуляции. Даже если оставшиеся несколько этих частей работают под микропрограммным управлением, совершенно нельзя уже говорить, что входные инструкции выполняет микропрограмма, ибо доля микропрограммы в общем объеме работ исполнения очень мала. Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

В общем, хочешь всерьез — будем всерьез, будешь на уровне "а вот у них я слышал" — ну так на уровне слухов и останемся.

N>Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

Ерунда, и пример тому — Трансмета. И вопрос твой неудачен, процессоры нужны чтобы предоставлять вычислительные ресурсы, т.е. к обсуждаемому не относится. И на сегодня наилучшее соотношение в координатах потребление/кол-во_транзисторов/вычислительная_мощность дают многоядерные процы на "языках" довольно высокого уровня, типа Forth. И да, они микропрограммные. О чем и речь, собсно. Еще раз хочешь спросить, для чего процы нужны?

N>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?

А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел.

У Интела "прошивка" однократная, у тех настраиваемая. А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"?

Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

В общем, весь этот спор от того, что кое-кто попал в ловушку, перепутав процессор как абстракцию "черного ящика", с реально используемыми технологиями. Я ведь не против микропрограммных процов, как таковых. Просто эта технология должна быть использована по прямому назначению, т.е. для поднятия уровня входного языка процессора. А сегодня она используется вовсе не по прямому, а лишь для обеспечения совместимости с унаследованным бинарным кодом.

N>Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.

Так ты встрял, чтобы вернуть нас к первоначальной теме?

N>То есть ситуацию развития DSP иначе как механическим склеиванием ты вообще не предполагаешь?

Кстати, ограничение тематики именно DSP — опять же от тебя. Тред обсуждал проблему в общем, и DSP, криптография и векторная алгебра здесь частные случаи. Кстати, конкретно меня сейчас DSP вообще не интересует, а вот нужны таймеры типа "зафиксировать значения внутреннего счётчика времени в моменты прихода фронтов по внешней линии, помнить 4 последних значения". Каким DSP я это могу реализовать и накойхер так извращаться?

То, что ты говоришь — это устройства ввода/вывода, и так умели еще самые первые таймеры. Что сказать-то хотел? В некоторых DSP тоже есть таймеры, только регистры ввода-вывода не совсем к DSP относятся, если не сказать больше. Да, практически в каждом уважающем себя микроконтроллере есть таймер (чем микроконтроллер от микропроцессора отличается, надеюсь понимаешь?)

И при чем тут упомянутое тобой устройство ввода/вывода, когда обсуждение шло насчет того, насколько исполнение кодека H.264 является по своей природе "железячным" в конкретном плеере?

Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер. Я уже высказывался тут неоднократно, что многие студенты "гении программного исскуства" обычно мало уделяют внимания дисциплинам, связанным с цифровой электроникой (наверно считают, что оно им не так надо), что дает потом знать о себе в реальной работе.

N>>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

N>Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.

Мде, приплызд...
Во-первых, Core i7 построено на выч. блоках от Core2 Duo, просто их теперь больше напихали. Во-вторых, сравнивать кол-во продаж процов Интелла и кол-во продаж этого медиадекодера даже не смешно. В третьих, tool-chain нужен для разработки ПО, для x86 эти tool chain копились 4 десятка лет, и они по факту уже есть. Ну и наконец, у Интелла фактический коллапс идей. Давно уже нет такого развития архитектуры ядер их процессоров, который они демонстрировали до этого. Начиная с 2003-го года все изменения в ядрах, за исключением внедрения гипертрединга, носили исключительно косметический характер. Никогда еще Интелл не задерживалась так долго с выпуском принципиально новых архитектур. Насколько мощные были переходы x86->x286->x386->x486->Pentium->P2->P3->P4, настолько же выпуск i7/i9 является пшиком и фактической росписью в беспомощности. И вот при своем уровне продаж Интелл не изобретает принципиально новые ядра, не поднимает частоту, а уплотняет на одном кристалле старые. И ты хочешь сказать, что некая noname будет разрабатывать свой SoC с совершенно уникальными ядрами собственной разработки? Окстись!

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

Здравствуйте, vdimas, Вы писали:

V>>>Во-вторых, Нету уже давно никакого выделенного потока микрокода, там теперь более десятка взаимодействующих автоматов.

N>>Кажется, словосочетание "выделенный поток", которое ты тут опровергаешь, появилось именно в твоей реплике. Я такого не называл и даже не подразумевал. Как я могу это воспринять иначе, чем дискуссионный приём выдвинуть возражение и тут же его разгромить с блеском?

V>Давай мы не будем на этом уровне обсуждать. Довольно подробно архитектура современного интелла расписана и источники открыты. Того единого потока исполнения микрокода, как некоей внутренней "подпрограммы" (чтобы ее именно можно было считать за полноценную микропрограмму, которая была там до пентиума), давно уже нет.

А меня и не интересует "единый поток". Понятно, что коренное отличие (как минимум одно из;)) нынешней архитектуры от этак PDP-11/60 — отказ от строго последовательного исполнения и замена этого на свободные связи и зависимости. Но если понять, что и там и тут внешний код переводится во внутренний и исполняется уже внутренний — фатальной разницы не возникает.

Кстати, ты опять ушёл от вопроса, при чём тут firmware. Даже если мы согласимся с тем, что эти микропрограммы — это не микропрограммы, а на самом деле это другие микропрограммы;)) — всё равно не видно смысла принудительно отождествлять разные термины.

V> Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

Они транслируются не микропрограммой, а в микропрограмму. Даже в 60-х даже в страшном сне никто не думал, что микропрограмма будет управлять процессом отработки команд (не считая всяких условных переходов) — потому что это уже эмуляция получается, со всеми её тормозами.

V>В общем, хочешь всерьез — будем всерьез, будешь на уровне "а вот у них я слышал" — ну так на уровне слухов и останемся.

Где слухи-то?

N>>Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

V>Ерунда, и пример тому — Трансмета. И вопрос твой неудачен, процессоры нужны чтобы предоставлять вычислительные ресурсы, т.е. к обсуждаемому не относится. И на сегодня наилучшее соотношение в координатах потребление/кол-во_транзисторов/вычислительная_мощность дают многоядерные процы на "языках" довольно высокого уровня, типа Forth. И да, они микропрограммные. О чем и речь, собсно. Еще раз хочешь спросить, для чего процы нужны?

Forth — это крайне низкий уровень. Я бы понял, если бы ты Smalltalk вспомнил... но не этот портабельный ассемблер-переросток. (Disclaimer: я люблю Форт, но реальная ниша у него — именно такая)

А про Transmeta — а почему у них не было выхода на исполнение других архитектур?

N>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. :xz: У Интела "прошивка" однократная, у тех настраиваемая.

У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)

V> А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"? :)))
V>Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

Ну и где выход на рынок с каким-то реальным предложением? Ладно, x86 не любят — оно действительно слишком неровное. Ну а MIPS? S/390? Sparc?
Боюсь, что у Transmeta проблема где-то в консерватории.

V>В общем, весь этот спор от того, что кое-кто попал в ловушку, перепутав процессор как абстракцию "черного ящика", с реально используемыми технологиями.

Ну ты загнул (tm)

V> Я ведь не против микропрограммных процов, как таковых. Просто эта технология должна быть использована по прямому назначению, т.е. для поднятия уровня входного языка процессора. А сегодня она используется вовсе не по прямому, а лишь для обеспечения совместимости с унаследованным бинарным кодом.

Хорошо, предложи альтернативу. Какие реально пути есть? VLIW не предлагать. Нужно что-то такое, чтобы и современные требования нормально обеспечивало (включая тотальный реордеринг), и при этом с ним работать было можно, и чтобы компиляторы были в состоянии для них код сделать не решая каждую секунду 500 NP-полных задач... А я посмотрю, в какие ловушки ты попадёшь.

N>>Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.
V>Так ты встрял, чтобы вернуть нас к первоначальной теме? :)

Да нет, поговорить захотелось.:))

N>>То есть ситуацию развития DSP иначе как механическим склеиванием ты вообще не предполагаешь?;) Кстати, ограничение тематики именно DSP — опять же от тебя. Тред обсуждал проблему в общем, и DSP, криптография и векторная алгебра здесь частные случаи. Кстати, конкретно меня сейчас DSP вообще не интересует, а вот нужны таймеры типа "зафиксировать значения внутреннего счётчика времени в моменты прихода фронтов по внешней линии, помнить 4 последних значения". Каким DSP я это могу реализовать и накойхер так извращаться?
V>То, что ты говоришь — это устройства ввода/вывода, и так умели еще самые первые таймеры.

Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).

V> Что сказать-то хотел? В некоторых DSP тоже есть таймеры, только регистры ввода-вывода не совсем к DSP относятся, если не сказать больше. Да, практически в каждом уважающем себя микроконтроллере есть таймер (чем микроконтроллер от микропроцессора отличается, надеюсь понимаешь?)

Понимаю. А ты понимаешь, чем отличается описанный мной таймер от тупого счётчика, который в лучшем случае умеет выдавать чего-то на внутреннюю линию при переходе через 0?

V>И при чем тут упомянутое тобой устройство ввода/вывода, когда обсуждение шло насчет того, насколько исполнение кодека H.264 является по своей природе "железячным" в конкретном плеере? :xz:

Тред в целом не был посвящён исполнению H.264 и данная частная тема мне неинтересна. Если же ты имеешь в виду то письмо, на которое я отвечал в начале своего "вмешательства", то у меня просто нет готовых примеров под рукой. Но не надо быть колючим млекопитающим, чтобы понять, что 1) работа с видео уже настолько не-DSP'шная задача, что нехорошо называть его реализацию словом DSP, 2) оптимизации именно под конкретный алгоритм могут быть важнее, чем количество странных функций ЦАП.

V>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.

Мне??? ;) Я и не претендую на потребность в DSP.

N>>>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>>>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.
N>>Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.
V>Мде, приплызд...
V>Во-первых, Core i7 построено на выч. блоках от Core2 Duo, просто их теперь больше напихали. Во-вторых, сравнивать кол-во продаж процов Интелла и кол-во продаж этого медиадекодера даже не смешно. В третьих, tool-chain нужен для разработки ПО, для x86 эти tool chain копились 4 десятка лет, и они по факту уже есть. Ну и наконец, у Интелла фактический коллапс идей. Давно уже нет такого развития архитектуры ядер их процессоров, который они демонстрировали до этого. Начиная с 2003-го года все изменения в ядрах, за исключением внедрения гипертрединга, носили исключительно косметический характер. Никогда еще Интелл не задерживалась так долго с выпуском принципиально новых архитектур. Насколько мощные были переходы x86->x286->x386->x486->Pentium->P2->P3->P4, настолько же выпуск i7/i9 является пшиком и фактической росписью в беспомощности. И вот при своем уровне продаж Интелл не изобретает принципиально новые ядра, не поднимает частоту, а уплотняет на одном кристалле старые. И ты хочешь сказать, что некая noname будет разрабатывать свой SoC с совершенно уникальными ядрами собственной разработки? Окстись! :)

По-моему, кститься надо кому-то другому. Потому что против такой чудовищной смеси правды с бредом и смешения совершенно разноуровневых вещей в одной каше, кажется, действительно поможет только божественное вмешательство.
По деталям.
1. Я не отделял разработку того же Corei7 от предыдущих этапов. Извини, если это не видно чётко из текста. На сейчас он последний из активно видного, именно поэтому взят как пример.
2. Развитие безусловно есть: появляются новые общие принципы (такие, как прямое управление шиной, размещение ядра видеоадаптера в центральном процессоре), новые группы команд, происходят реформы внутренней структуры.
3. Про коллапс идей — вот тут, считаю, тебе полностью отказало критическое мышление и мы имеем в лучшем случае приступ брюзжания. Идеи не обязаны проявляться в виде "весь мир насилья мы разроем, а затем...", как это было в случае ходячего кошмара под названием P4. Даже при "простом" увеличении количества ядер есть чего решать (а особенности i7 & etc. далеко не только в этом). Далее, даже в последовательности шагов ты ошибся: называя Pentium, а затем P2, ты почему-то забыл про PPro, в котором произошла самая кардинальная революция всей линии и по сравнению с которым P2 — попсовый кастрат.

Когда специалист твоего уровня начинает выдавать реплики в стиле журналюги из жёлтой газеты, переврав и смешав в кучу факты и добавив к этому вердикт уровня моськи — "слон не тот, слон плохо ходит, слон скоро умрёт" — это всё удивляет и удручает.

Здравствуйте, netch80, Вы писали:

N>А меня и не интересует "единый поток". Понятно, что коренное отличие (как минимум одно из

) нынешней архитектуры от этак PDP-11/60 — отказ от строго последовательного исполнения и замена этого на свободные связи и зависимости. Но если понять, что и там и тут внешний код переводится во внутренний и исполняется уже внутренний — фатальной разницы не возникает.

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

V>> Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

N>Они транслируются не микропрограммой, а в микропрограмму. Даже в 60-х даже в страшном сне никто не думал, что микропрограмма будет управлять процессом отработки команд (не считая всяких условных переходов) — потому что это уже эмуляция получается, со всеми её тормозами.

Мда... терпение и еще раз терпение... Нет, все-таки надо отослать. Гуглить по микропрограммный автомат. Все-таки, когда общался с коллегой, предполагал что мне нет нужды тут подробностями за 4-й курс обучения засорять пост. Конечно эмуляция — это тормоза, но с чего ты решил, что я это имелл виду. Я же ссылался на классику уже.

V>>В общем, хочешь всерьез — будем всерьез, будешь на уровне "а вот у них я слышал" — ну так на уровне слухов и останемся.

N>Где слухи-то?

Ну, всегда считалось, что процессоры интелл построены по классической микропрограммной технологии, и до пентиума это так и было. Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ. О какой нафиг эмуляции тут вообще можно было говорить? Это или нубство, или попытка приписать оное оппоненту. Выходом ф-ии является след. состояние автомата + выходные целевые сигналы, управляющие исполнительными устройствами (другими автоматами/схемами). Ну как можно было выделить лишь эти выходные сигналы, управляющие исполнительными блоками (т.е. то, во что именно транслируются входные опкоды), и обозвать их микропрограммой?!! Это — лишь часть пространства выходных сигналов автомата с микропрограммным управлением. Или же, из клиссического определения функционального преобразователя с памятью — просто мн-во выходных сигналов. Но это, блин, никакая не микропрограмма.

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

N>Forth — это крайне низкий уровень. Я бы понял, если бы ты Smalltalk вспомнил... но не этот портабельный ассемблер-переросток. (Disclaimer: я люблю Форт, но реальная ниша у него — именно такая)

Forth, вернее та его часть, которая делается "в железе" — это язык уровня байткодов Java/Net. Очень неплохой уровень в сравнении с x86. И я плохо представляю себе реализацию small talk процессора, так же как и любого другого языка действительно выского уровня, ввиду того, что размеры данных (объектов) могут быть произвольны, и для них банально может не хватить места в памяти проца. Т.е. поин в том, что такая микропрограмма должна выходиь за рамки ресурсов процессора и работать как обычная прогамма, общаясь с окружающей системой. Для сравенения, все данные, которыми оперирует Forth-процессор, являются для него примитивами, которые он может прочитать или записать за раз.

N>А про Transmeta — а почему у них не было выхода на исполнение других архитектур?

Как это не было?

N>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел.

У Интела "прошивка" однократная, у тех настраиваемая.

N>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)

Тогда с чего ты решил, что избегают этого термина?

V>> А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"?

V>>Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

N>Ну и где выход на рынок с каким-то реальным предложением? Ладно, x86 не любят — оно действительно слишком неровное. Ну а MIPS? S/390? Sparc?
N>Боюсь, что у Transmeta проблема где-то в консерватории.

На момент выхода трансметы рынок MIPS был смешон, Sparc — тем более, а инвестиции были нехилые и амбиции соответствующие. Это сейчас, когда поперло все мобильное, возможно попытаются что-то сделать в другом направлении. К тому же за эти годы тот же Линукс распространился на невероятное кол-во платформ, что можно даже предположить сценарий, когда впору сделать уникальный набор команд, выжимающий всю мощь из этого кристалла, и это решение не будет выглядеть как утопия. Посмотрим.

V>> Я ведь не против микропрограммных процов, как таковых. Просто эта технология должна быть использована по прямому назначению, т.е. для поднятия уровня входного языка процессора. А сегодня она используется вовсе не по прямому, а лишь для обеспечения совместимости с унаследованным бинарным кодом.

N>Хорошо, предложи альтернативу. Какие реально пути есть? VLIW не предлагать. Нужно что-то такое, чтобы и современные требования нормально обеспечивало (включая тотальный реордеринг), и при этом с ним работать было можно, и чтобы компиляторы были в состоянии для них код сделать не решая каждую секунду 500 NP-полных задач... А я посмотрю, в какие ловушки ты попадёшь.

Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор?

). Пусть один из регистров называется указателем стека или как угодно — не суть. Во-первых, очень мало опкодов (упрощается дешифратор), во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения. Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там. Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).

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

(не путать цифроаналоговым таймером, напр. 555)
Перефразирую твое: нужна схема со счетчиком, на которую подаются такты и сигналы stop/reset. Да, это именно одна из популярных схем таймера, широко использовалась для АЦП. Другая схема — обратная, есть счетчик, такты, ты выставляешь начальное значение, говоришь start, а счетчик считает до 0-ля. Небольшое усовершествование этой схемы, когда она сама себя перезапускает по достижению 0-ля — это классический делитель частоты на таймере. Программируемый таймер

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

Иначе схема не имеет смысла.

Вот наш аналог программируемого таймера, который всю жисть был в IBM PC и сейчас в чипсетах материнок его функциональность есть: http://elancev.narod.ru/texno/bi53/bi53.htm
Второй его режим — это твоя задача. К сожалению, конкретно в IBM PC он подключен не совсем удобно, но в свою схему можешь включить как пожелаешь.

V>> Что сказать-то хотел? В некоторых DSP тоже есть таймеры, только регистры ввода-вывода не совсем к DSP относятся, если не сказать больше. Да, практически в каждом уважающем себя микроконтроллере есть таймер (чем микроконтроллер от микропроцессора отличается, надеюсь понимаешь?)

N>Понимаю. А ты понимаешь, чем отличается описанный мной таймер от тупого счётчика, который в лучшем случае умеет выдавать чего-то на внутреннюю линию при переходе через 0?

Да, тем же, чем просто счетчик отличается от таймера.

Заканчивай уже на весь интернет-то...

N>Но не надо быть колючим млекопитающим, чтобы понять, что 1) работа с видео уже настолько не-DSP'шная задача, что нехорошо называть его реализацию словом DSP, 2) оптимизации именно под конкретный алгоритм могут быть важнее, чем количество странных функций ЦАП.

Ниче не понял.

V>>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.

N>Мне???

Я и не претендую на потребность в DSP.

Ну ты так вопрос поставил в пред. сообщении. DSP для таймера не нужен, зато дешево и эффективно на нем обсчитывать многочлены с плавающей запятой. Практически все популярные DSP имеют ф-ию суммировани многочлена, т.е. однотактную операцию вида sum = sum + a * b, а некоторые могут за этот же такт обсчитывать более одного sum, a и b. Т.е. вид параллельности в DSP обычно явный и жесткий, когда в одном опкоде зашито управление сразу несколькими вычислительными блоками, как в VLIW. Использовать же современные процы для этого — из пушки по воробьям, как по потреблению, так и по невостребованности всех их наворотов для однообразных вычислений в процессе работы кодека.

N>1. Я не отделял разработку того же Corei7 от предыдущих этапов. Извини, если это не видно чётко из текста. На сейчас он последний из активно видного, именно поэтому взят как пример.
N>2. Развитие безусловно есть: появляются новые общие принципы (такие, как прямое управление шиной, размещение ядра видеоадаптера в центральном процессоре), новые группы команд, происходят реформы внутренней структуры.
N>3. Про коллапс идей — вот тут, считаю, тебе полностью отказало критическое мышление и мы имеем в лучшем случае приступ брюзжания. Идеи не обязаны проявляться в виде "весь мир насилья мы разроем, а затем...", как это было в случае ходячего кошмара под названием P4. Даже при "простом" увеличении количества ядер есть чего решать (а особенности i7 & etc. далеко не только в этом). Далее, даже в последовательности шагов ты ошибся: называя Pentium, а затем P2, ты почему-то забыл про PPro, в котором произошла самая кардинальная революция всей линии и по сравнению с которым P2 — попсовый кастрат.

О да, я забыл по PPro, а так же про 8088/186/188.

Все равно не согласен, самая кардинальная революция — это 286-е, и отшлифованное оно же в 386-м. А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".

N>Когда специалист твоего уровня начинает выдавать реплики в стиле журналюги из жёлтой газеты, переврав и смешав в кучу факты и добавив к этому вердикт уровня моськи — "слон не тот, слон плохо ходит, слон скоро умрёт" — это всё удивляет и удручает.

Тот факт, что я не разбил на абзацы, не говорит, что я смешал в кучу.

По крайней мере отделил через "во-первых, во-вторых" и т.д., ибо ты очень много накидал чего до этого, на что можно было ответить. В любом случае, принципиально я прав, с 2003-го все улучшения лишь косметические, в сравнении с предыдущими поколениями. Я понимаю, что лично тебе эти улучшения интересны, я уже заметил за несколько лет, что ты тяготеешь почему-то именно к Интеллу. Но, чтобы не провозносить их выше некуда, можно было бы посмотреть на процессоры от AMD, подробнее на тот же IA64, на топовые процы от Sun, с большим кол-вом ядер и 4-хпотоковостью на ядро, и т.д. и т.п., и тогда иначе как косметическими изменения за последние 7 лет (!!!) назвать уже не получится.

Я прекрасно знаю почему так: вина не в Интелле, а в "проклятых конкурентах", продливших жизнь архитектуре x86. Все, что мы видим сейчас, это результат того факта, что Интелл не была готова к такому повороту событий. Ну не верю я, что фирма скурвилась (если честно), зато верю, что ресурсы были потрачены не туда (см. заголовок темы). Вернее, я-то считаю, что туда и сам бы так поступил на их месте, но во оно как потом вышло...

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

Здравствуйте, netch80, Вы писали:

N>На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач),

Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

N>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.

Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.

N>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.

Просто задачи разные бывают.

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

Здравствуйте, vdimas, Вы писали:

N>>На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач),
V>Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

Это про 64-битку? Я сейчас не могу найти, но мне казалось, что в ней SSE2 обязателен с рождения.

N>>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.
V>Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.

Вообще-то крайне мало случаев, когда компилятор способен получить такую эффективность из кода, написанного "вообще". Практически значимый случай — когда ускоренные версии пишутся на целевом ассемблере. А такое делать лучше с детектом в рантайме.

N>>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.
V>Просто задачи разные бывают.

Не задачи, а подходы. Всё компилить подряд под высокий процессор в надежде получить ускорение на кодеке, когда легче с этим кодеком разобраться напрямую — это плохой, негодный подход.

Здравствуйте, netch80, Вы писали:

V>>Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

N>Это про 64-битку? Я сейчас не могу найти, но мне казалось, что в ней SSE2 обязателен с рождения.

В 64 бит да, но я не говорил именно про 64 бит.

N>>>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.
V>>Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.

N>Вообще-то крайне мало случаев, когда компилятор способен получить такую эффективность из кода, написанного "вообще". Практически значимый случай — когда ускоренные версии пишутся на целевом ассемблере. А такое делать лучше с детектом в рантайме.

Я конкретно про SSE2 и выше, которые с double работают. Просто много кодеков используют double для приличной части вычислений.

N>>>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.
V>>Просто задачи разные бывают.

N>Не задачи, а подходы. Всё компилить подряд под высокий процессор в надежде получить ускорение на кодеке, когда легче с этим кодеком разобраться напрямую — это плохой, негодный подход.

Без коментариев... кодеки и так обычно вылизаны по самое нехочу. Речь, повторюсь, исключительно о бенефитах от SSE.

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

Здравствуйте, kig, Вы писали:

V>>могла поддерживать теоретически бесконечную вложенность операционных систем на основе СВМ, ввиду того, что виртуализируемая машина работала практически с той же скоростью, что и невиртуализируемая

kig>Теоретически — да. Но на практике, например, на ЕС-1046 с 8 мгб, третий уровень работал сносно, четвертый изрядно тормозил, а пятый — еле двигался.

Вот мне интересно посмотреть на пятый уровень вложенности какого-нить VirtualPC.

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

Здравствуйте, vdimas, Вы писали:

V>>>Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг. :)
N>>Это про 64-битку? Я сейчас не могу найти, но мне казалось, что в ней SSE2 обязателен с рождения.
V>В 64 бит да, но я не говорил именно про 64 бит.

Посмотри внимательно на мои слова, на которые ты отвечал — там именно 64 бит было. Ветку про 32 бита ты куда-то срезал.

N>>Вообще-то крайне мало случаев, когда компилятор способен получить такую эффективность из кода, написанного "вообще". Практически значимый случай — когда ускоренные версии пишутся на целевом ассемблере. А такое делать лучше с детектом в рантайме.
V>Я конкретно про SSE2 и выше, которые с double работают. Просто много кодеков используют double для приличной части вычислений.

Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?

N>>>>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.
V>>>Просто задачи разные бывают. ;)
N>>Не задачи, а подходы. Всё компилить подряд под высокий процессор в надежде получить ускорение на кодеке, когда легче с этим кодеком разобраться напрямую — это плохой, негодный подход.
V>Без коментариев... кодеки и так обычно вылизаны по самое нехочу.

Вот это и будет препятствовать умению компилятора впихнуть туда SSE.

Здравствуйте, vdimas, Вы писали:

N>>А меня и не интересует "единый поток". Понятно, что коренное отличие (как минимум одно из;)) нынешней архитектуры от этак PDP-11/60 — отказ от строго последовательного исполнения и замена этого на свободные связи и зависимости. Но если понять, что и там и тут внешний код переводится во внутренний и исполняется уже внутренний — фатальной разницы не возникает.
V>Разница большая, раз мы говорим именно о технологиях микропрограмм. Да, принцип трансляции остался, но смешивать трансляцию опкодов и микропрограмму даже не смешно. Так и чешутся руки отослать к основам цифровой техники.

К каким? Штриху Шеффера?;))

N>>Они транслируются не микропрограммой, а в микропрограмму. Даже в 60-х даже в страшном сне никто не думал, что микропрограмма будет управлять процессом отработки команд (не считая всяких условных переходов) — потому что это уже эмуляция получается, со всеми её тормозами.

V>Мда... терпение и еще раз терпение... Нет, все-таки надо отослать. Гуглить по микропрограммный автомат.

Непонятен переход от микропрограммы к микропрограммному автомату.
Когда говорится про микропрограммы, обычно подразумевается, что микропрограммы представимы в каком-то явном виде и к тому же пригодны к изменению (например, для расширения системы команд), и реально процессор исполняет (уже на железном уровне) именно их, а не входной код. К описанному понятию "микропрограммного автомата" (который изображается так, что под его определение подпадает фактически любое вычислительное устройство с внешней тактировкой) это в лучшем случае омоним.

V> Все-таки, когда общался с коллегой, предполагал что мне нет нужды тут подробностями за 4-й курс обучения засорять пост. Конечно эмуляция — это тормоза, но с чего ты решил, что я это имелл виду. Я же ссылался на классику уже. :xz:

У меня такого не было ни на каком курсе. Но дело не в этом (я знаю, что такое микропрограммный автомат, из других источников), а в том, что ты смешиваешь разные вещи в одно только из-за сходства названий.

V>Ну, всегда считалось, что процессоры интелл построены по классической микропрограммной технологии, и до пентиума это так и было.

Опаньки — и что поменялось? И при чём тут именно пентиум, когда он как раз очень мало изменений принёс? Конвейер появился ещё в 8086. Внутренний язык, переупорядочение команд, etc. — в PPro. Чем тебя так это несчастное разделение конвейеров заинтересовало, что ты считаешь его революцией, а остальное — нет?

V> Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ.

Кошмар какой. Меня действительно не учили централизованно цифровой схемотехнике — в этом я самоучка. Может, поэтому я замечаю то, что остальные штатно обученные не видят — что о микропрограммах начинают говорить только тогда, когда они выделены в явном виде, записаны в памяти процессора (неважно, какого она типа) и реально процессор исполняет именно их, а входной код в лучшем случае играет роль начального селектора. И даже если процессор является тем самым "микропрограммным автоматом" в целом (нонсенс), если у него этого нет — то и про микропрограммы не говорят.

V>Сейчас совсем другая технология порождения этих управляющих сигналов, то бишь транслированных опкодов. В генерации последовательности этих управляющих сигналов участвует много автоматов. Да, некоторые из них в свою очередь выполнены по микропрограммной схеме. Надеюсь объяснил, почему я говорил о "слухах"? И какова роль микропрограмм в современных процессорах?

Да, мне действительно теперь понятно — что цепляясь за нелепый устарелый термин ты теряешь суть.

N>>Forth — это крайне низкий уровень. Я бы понял, если бы ты Smalltalk вспомнил... но не этот портабельный ассемблер-переросток. (Disclaimer: я люблю Форт, но реальная ниша у него — именно такая)
V>Forth, вернее та его часть, которая делается "в железе" — это язык уровня байткодов Java/Net. Очень неплохой уровень в сравнении с x86. И я плохо представляю себе реализацию small talk процессора, так же как и любого другого языка действительно выского уровня, ввиду того, что размеры данных (объектов) могут быть произвольны, и для них банально может не хватить места в памяти проца. Т.е. поин в том, что такая микропрограмма должна выходиь за рамки ресурсов процессора и работать как обычная прогамма, общаясь с окружающей системой.
V> Для сравенения, все данные, которыми оперирует Forth-процессор, являются для него примитивами, которые он может прочитать или записать за раз.

N>>А про Transmeta — а почему у них не было выхода на исполнение других архитектур?
V>Как это не было?

Где реальный результат? Пошуметь любой может.

N>>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. :xz: У Интела "прошивка" однократная, у тех настраиваемая.
N>>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)
V>Тогда с чего ты решил, что избегают этого термина?

потому что у них "микрокод", а не firmware.

N>>Ну и где выход на рынок с каким-то реальным предложением? Ладно, x86 не любят — оно действительно слишком неровное. Ну а MIPS? S/390? Sparc?
N>>Боюсь, что у Transmeta проблема где-то в консерватории.
V>На момент выхода трансметы рынок MIPS был смешон, Sparc — тем более,

Чииво? Ты вообще на календарь смотрел? На момент выхода трансметы Sun фактически владел рынком больших серверов (с лёгкой поправкой на Tandem, S/390, AS/400 и прочие маргинальные для нас сущности). Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?;))

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

N>>Хорошо, предложи альтернативу. Какие реально пути есть? VLIW не предлагать. Нужно что-то такое, чтобы и современные требования нормально обеспечивало (включая тотальный реордеринг), и при этом с ним работать было можно, и чтобы компиляторы были в состоянии для них код сделать не решая каждую секунду 500 NP-полных задач... А я посмотрю, в какие ловушки ты попадёшь.
V>Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор? ;) ).

Да-да. И терять при этом в эффективности за счёт того, что данные вечно бегают из памяти в этот единственный аккумулятор и обратно. Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

V> Пусть один из регистров называется указателем стека или как угодно — не суть. Во-первых, очень мало опкодов (упрощается дешифратор),

Дешифратор в цене современного процессора — это даже не копейки, это меньше.

V> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.

Ну да, просто убивая возможность анализа на корню. Пусть компилятор думает, у него голова большая.

V> Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там.

Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.

V> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала. Несмотря на все свои спецмеры типа "снимем с процессора задачу умничать в исполнении команд".
Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

N>>Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).
V>Я не знаю, чего ты там двигаешь мышкой, но термином "таймер" называют целый класс цифровых схем со счетчиком, работу самой популярной из которых ты вполне четко описал. :xz: (не путать цифроаналоговым таймером, напр. 555)

Ещё раз — какой из них позволяет запомнить несколько последних моментов фронта?
На один — я и так знаю, где это найти.

V>Конкретно у тебя, насчет помнить последние 4 значения — это зависит от соотношения частот. Если процессор будет успевать по прерываниям забирать данные

Нет, он не будет даже пытаться "успевать" забирать их — это не его задача.
Ты всё время стараешься мне подсовывать какие-то левые решения вместо прямого ответа. Я описал задачу. Она специфическая для нас, но реальная. Она не решается существующими средствами (вариант накоммутировать в FPGA я не рассматриваю). Её тривиально решить, сделав конвейер из 4-х регистров и счётчик вначале, но это надо спроектировать. Что тут непонятного и зачем ты вместо того, чтобы просто понять и осознать проблему, подсовываешь мне тысячу способов как извратиться, но не решить её?

V>Вот наш аналог программируемого таймера, который всю жисть был в IBM PC и сейчас в чипсетах материнок его функциональность есть: http://elancev.narod.ru/texno/bi53/bi53.htm
V>Второй его режим — это твоя задача. К сожалению, конкретно в IBM PC он подключен не совсем удобно, но в свою схему можешь включить как пожелаешь.

Во-первых, в PC — i8254, а не i8253. Отличия мелкие, но существенные. Во-вторых, мне это нужно не ломая основной таймер (от которого ничего не осталось, кроме наследства в виде одного канала). Остальное я сказал выше. Перестань юлить.

V>Заканчивай уже на весь интернет-то...

Вот и заканчивай отказываться признавать очевидное — что новые требования возникают всегда, что разработка нового совершенно не обязательно связана с миллиардными затратами, наконец, то, что есть множество вариантов как решить проблемы простыми и достаточно эффективными решениями.

V>>>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.
N>>Мне??? ;) Я и не претендую на потребность в DSP.
V>Ну ты так вопрос поставил в пред. сообщении. DSP для таймера не нужен,

Не ставил я такого, читай заново.

V> зато дешево и эффективно на нем обсчитывать многочлены с плавающей запятой. Практически все популярные DSP имеют ф-ию суммировани многочлена, т.е. однотактную операцию вида sum = sum + a * b, а некоторые могут за этот же такт обсчитывать более одного sum, a и b. Т.е. вид параллельности в DSP обычно явный и жесткий, когда в одном опкоде зашито управление сразу несколькими вычислительными блоками, как в VLIW. Использовать же современные процы для этого — из пушки по воробьям, как по потреблению, так и по невостребованности всех их наворотов для однообразных вычислений в процессе работы кодека.

"Кто бы спорил, я не буду". Для такой частной задачи — да.

V>О да, я забыл по PPro, а так же про 8088/186/188. :)

186 и близкие — неважны. А PPro — самая большая революция во всём ряду. Это не "забыл", это незнание.

V>Все равно не согласен, самая кардинальная революция — это 286-е, и отшлифованное оно же в 386-м.

Это что? Виртуальная память и слои защиты? Это не революция собственно внутренней архитектуры — и в 286 и в 386 они были пришлёпками сверху. Только в 486 они вошли нормально в структуру. А ты что, воспринимаешь именно такие революции внешнего облика? Ну так их скорее всего и не будет ещё лет 10. И что, это значит, развития нет?

V> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".

Ничего себе "частности", всё нутро поменялось до неузнаваемости.

V>Тот факт, что я не разбил на абзацы, не говорит, что я смешал в кучу. :)

Дело не в абзацах.

V> По крайней мере отделил через "во-первых, во-вторых" и т.д., ибо ты очень много накидал чего до этого, на что можно было ответить. В любом случае, принципиально я прав, с 2003-го все улучшения лишь косметические, в сравнении с предыдущими поколениями.

Нет.

V> Я понимаю, что лично тебе эти улучшения интересны, я уже заметил за несколько лет, что ты тяготеешь почему-то именно к Интеллу. Но, чтобы не провозносить их выше некуда, можно было бы посмотреть на процессоры от AMD,

Это ничего, что у меня с 96-го года дома только AMD? "тяготеешь к Интелу"... ещё одно высосанное даже не из пальца, а вообще не знаю из чего, слов нет.

V> подробнее на тот же IA64, на топовые процы от Sun, с большим кол-вом ядер и 4-хпотоковостью на ядро, и т.д. и т.п., и тогда иначе как косметическими изменения за последние 7 лет (!!!) назвать уже не получится.

От того, что эти изменения идут параллельно от разных производителей и архитектур — они не становятся косметическими.

V>Я прекрасно знаю почему так: вина не в Интелле, а в "проклятых конкурентах", продливших жизнь архитектуре x86. Все, что мы видим сейчас, это результат того факта, что Интелл не была готова к такому повороту событий. Ну не верю я, что фирма скурвилась (если честно), зато верю, что ресурсы были потрачены не туда (см. заголовок темы). Вернее, я-то считаю, что туда и сам бы так поступил на их месте, но во оно как потом вышло... :))) И да, конкретно этот последний абзац вовсе не технический, а самый что ни на есть журналюгский, как и весь этот раздел форума.

За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.

Здравствуйте, netch80, Вы писали:

N>К описанному понятию "микропрограммного автомата" (который изображается так, что под его определение подпадает фактически любое вычислительное устройство с внешней тактировкой) это в лучшем случае омоним.

Ну тогда стоит тебе пройтись еще раз тщательнее, ибо говоришь полную чушь.

V>> Все-таки, когда общался с коллегой, предполагал что мне нет нужды тут подробностями за 4-й курс обучения засорять пост. Конечно эмуляция — это тормоза, но с чего ты решил, что я это имелл виду. Я же ссылался на классику уже.

N>У меня такого не было ни на каком курсе. Но дело не в этом (я знаю, что такое микропрограммный автомат, из других источников), а в том, что ты смешиваешь разные вещи в одно только из-за сходства названий.

Угу. Подробней, плиз.

V>> Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ.

N>Кошмар какой. Меня действительно не учили централизованно цифровой схемотехнике — в этом я самоучка. Может, поэтому я замечаю то, что остальные штатно обученные не видят — что о микропрограммах начинают говорить только тогда, когда они выделены в явном виде, записаны в памяти процессора (неважно, какого она типа) и реально процессор исполняет именно их, а входной код в лучшем случае играет роль начального селектора.

Не знаю как заставить тебя отойти от абстракций к конкретике. Сложно общаться, ей-богу. "Входной код" — это твоя абстракция, когда ты смотришь на процессор как на черный ящик. А для процессора как автомата — это входные сигналы.

N>И даже если процессор является тем самым "микропрограммным автоматом" в целом (нонсенс), если у него этого нет — то и про микропрограммы не говорят.

Знаешь, можно на пальцах объяснить что к чему, но даже на пальцах это будет довольно длинный пост.

V>>Сейчас совсем другая технология порождения этих управляющих сигналов, то бишь транслированных опкодов. В генерации последовательности этих управляющих сигналов участвует много автоматов. Да, некоторые из них в свою очередь выполнены по микропрограммной схеме. Надеюсь объяснил, почему я говорил о "слухах"? И какова роль микропрограмм в современных процессорах?

N>Да, мне действительно теперь понятно — что цепляясь за нелепый устарелый термин ты теряешь суть.

Я не цепляюсь, я разъясняю, что он означает.

Если ты сутью называешь свои абстракции, то я их теряю, разумеется, когда мы говорим о значении терминов. Чтобы не было разночтений. Ты понимаешь, чем отличается конвеер команд 8086 и современный конвеер? И интереса ради, какова разрядность современного внутреннего конвеера? И что именно в нем содержится? По сути, этот вопрос содержит ответ, и если найдешь ответ — вопросы отпадут.

N>Где реальный результат? Пошуметь любой может.

Ты имеешь ввиду коммерчесский успех? Или уточни, что есть реальный результат, ибо они демонстрировали эмуляцию нескольких наборов команд. Но единственной возможностью хоть как-то продавать кристалл — на тот момент это эмуляция x86. технологиям и терминологиям, как ты понимаешь, этот факт никак не относится.

N>>>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел.

У Интела "прошивка" однократная, у тех настраиваемая.
N>>>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)
V>>Тогда с чего ты решил, что избегают этого термина?

N>потому что у них "микрокод", а не firmware.

Ну а в ветке, куда ты подключился, было именно firware.

Понимаешь, в русской терминологии "микропрограмма" либо синоним термина "прошивка", либо применяется к содержимому ПЗУ в миропрограммных автоматах, даже если вместо ячеек памяти ПЗУ есть просто перемычки в кристалле к 0 или 1. По-сути, это одно и то же. Когда изобрели преобразование последовательности команд во внутренний RISC, эти RISC инструкции стали называть микрокодом. В нашей терминологии — это управляющие сигналы, т.е. те, которые непосредственно подаются на исполняющие блоки и не требуют дешифрации. Т.е. вот идет там, например, сотня разрядов, и эти разряды — просто "составленные рядом" коды команд управляющих устройств. Это именно то, что сейчас содержится в конвейере, в отличие от 8086. А вот порождаться этот код может микропрограммой, автоматом с микропрограммным управлением, как и было в 8086.

Возможно тут произошла мутация термина. Если в 386-м эти управляющие сигналы непосредственно подавали на управляющие блоки, то в 486-м, выполнив по асинхронной схеме работу с памятью, эти управляющие сигналы сложили в очередь, т.е. сохранили их последовательность. Похоже, эту последовательность управляющих сигналов назвали микрокодом. Я вот погуглил, да, термин встречается в этом смысле. Но это не синоним термину "микропрограмма", в том смысле как он дается нашей IT (хоть некоторые на форумах пытаются утверждать обратное). Ибо обозначают принципиально разные вещи. Микропрограмма управляет состоянием автомата, а микрокод — просто логическими схемами, которые не обязаны быть автоматами. Например, с помощью микропрограммы можно организовать цикл (заставив автомат переходить в одно и то же состояние по достижению какого-нить внешнего условия), ветвление вообще происходит на каждом шаге (т.е. расчет следующего состояния), в то время как микрокод — абсолютно линейно прокручиваемая лента.

N>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?

)

Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.

V>>Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор?

).

N>Да-да. И терять при этом в эффективности за счёт того, что данные вечно бегают из памяти в этот единственный аккумулятор и обратно.

Ниче не понял... Мы по RISC говорим, или CISC, с переупорядочиванием, переименованием и прочим одновременным исполнением независимых операций?

N>Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

Именно что больше регистров. А сколько конкретно надо? Много сделаешь — много сохранять при переключении задач, и вот тут недавно воевали насчет использования файлов SSE в ядре ОС, вернее неиспользовании, чтобы не сохранять его. А сделаешь регистров мало — ты не доволен.

Посмотрел бы на байт-код дотнета, хотя бы. Локальная стековая память, которая заведомо относится к одному текущему потоку — чем не файл регистров произвольно требуемого размера?

Понимаешь, технология кэш-памяти постепенно стирает различия м/у файлом регистров и страницей памяти, отображенной в кэш.

V>> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.

N>Ну да, просто убивая возможность анализа на корню. Пусть компилятор думает, у него голова большая.

Надеюсь, теперь ты так не считаешь. Если не понимаешь, посмотри как работает JIT-компилятор дотнета. Он проще, чем декомпилятор x86-го, вот в чем прикол.

V>> Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там.

N>Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.

Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм?

Дело, как обычно, в софте.

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

V>> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала.

Первый VLIW комом, зато Эльбрус получился, который Интелл купил.

N>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

Ну и почему? Разве не понятно?

N>>>Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).
V>>Я не знаю, чего ты там двигаешь мышкой, но термином "таймер" называют целый класс цифровых схем со счетчиком, работу самой популярной из которых ты вполне четко описал.

(не путать цифроаналоговым таймером, напр. 555)

N>Ещё раз — какой из них позволяет запомнить несколько последних моментов фронта?
N>На один — я и так знаю, где это найти.

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

N>Нет, он не будет даже пытаться "успевать" забирать их — это не его задача.
N>Ты всё время стараешься мне подсовывать какие-то левые решения вместо прямого ответа. Я описал задачу. Она специфическая для нас, но реальная. Она не решается существующими средствами (вариант накоммутировать в FPGA я не рассматриваю). Её тривиально решить, сделав конвейер из 4-х регистров и счётчик вначале, но это надо спроектировать. Что тут непонятного и зачем ты вместо того, чтобы просто понять и осознать проблему, подсовываешь мне тысячу способов как извратиться, но не решить её?

Э-э-э... Это ты сам с собой или как? В чем проблема? Это вообще задача не того уровня, чтобы на форуме обсуждать, и я вообще не понял, из чего был напор-то. Дал бы как ТЗ, я бы тебе функциональную схему за 10 секунд накидал бы. На 3-м курсе в течении одной лабораторки по схемотехнике студенты на стендах такие схемы по вариантам собирают, лабы оформляют и еще сдавать/защищать успевают. В чем проблема-то?

N>Во-первых, в PC — i8254, а не i8253. Отличия мелкие, но существенные. Во-вторых, мне это нужно не ломая основной таймер (от которого ничего не осталось, кроме наследства в виде одного канала). Остальное я сказал выше. Перестань юлить.

Юлить?

Ню-ню. Если проблема действительно есть (хоть я ее и не пойму), ты это, в личку ТЗ скинь, мне ведь не сложно. А то ведь выясняется, то эти 4 значения процессору не нужны. А кому нужны? А как именно нужны, т.е. интерфейс забора этих 4-х значений какой? А частоты и прочие характеристики? Как я тебе дам готовое решение, если описанное тобою даже на черновик ТЗ не тянуло? И я еще и юлю? Нахал...

N>Вот и заканчивай отказываться признавать очевидное — что новые требования возникают всегда, что разработка нового совершенно не обязательно связана с миллиардными затратами, наконец, то, что есть множество вариантов как решить проблемы простыми и достаточно эффективными решениями.

Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?

V>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".

N>Ничего себе "частности", всё нутро поменялось до неузнаваемости.

Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира.

V>> По крайней мере отделил через "во-первых, во-вторых" и т.д., ибо ты очень много накидал чего до этого, на что можно было ответить. В любом случае, принципиально я прав, с 2003-го все улучшения лишь косметические, в сравнении с предыдущими поколениями.

N>Нет.

Хоть одно не косметическое, влияющее на архитектуру ядра?

N>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.

Во-первых, как это сломана? Если 64-битные винды спокойно напрямую запускают 32-битные приложения, а не в окне эмулятора, то для пользователя никакая совместимость не сломана.
Во-вторых, почему не Интелл первая пошла на такой же шаг? Как и в случае "революционного" PPro — выступила в роли догоняющего.

Здравствуйте, netch80, Вы писали:

N>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
ICC

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, vdimas, Вы писали:

V>>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".
N>>Ничего себе "частности", всё нутро поменялось до неузнаваемости.
V>Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира. :)

Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.

V>>> По крайней мере отделил через "во-первых, во-вторых" и т.д., ибо ты очень много накидал чего до этого, на что можно было ответить. В любом случае, принципиально я прав, с 2003-го все улучшения лишь косметические, в сравнении с предыдущими поколениями.
N>>Нет.
V>Хоть одно не косметическое, влияющее на архитектуру ядра?

Устранение северного моста и прямое управление памятью.
Внос видеоконтроллера в процессор (в моделях, где он есть).

N>>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.
V>Во-первых, как это сломана? Если 64-битные винды спокойно напрямую запускают 32-битные приложения, а не в окне эмулятора, то для пользователя никакая совместимость не сломана.

Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.

V>Во-вторых, почему не Интелл первая пошла на такой же шаг? Как и в случае "революционного" PPro — выступила в роли догоняющего.

Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.

N>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

V>Ну и почему? Разве не понятно?

Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.

V>>> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>>AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала.

V>Первый VLIW комом, зато Эльбрус получился, который Интелл купил.

Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

N>>Вот и заканчивай отказываться признавать очевидное — что новые требования возникают всегда, что разработка нового совершенно не обязательно связана с миллиардными затратами, наконец, то, что есть множество вариантов как решить проблемы простыми и достаточно эффективными решениями.

V>Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?

Спор превращаешь в фарс ты. Это ж надо — упорно доказывать, что никто ничего нового в мире железа не разрабатывает... да, у меня примеры из моей области, и я намеренно беру простые (есть и сложные, но мне облом тратить три страницы на объяснение, нафига оно надо и почему такое). В процессорах тебе, видите ли, ничего нового. Я контрпример привёл — прими его. Не хочешь — докажи, что ничего нового не происходит. А я посмотрю, как ты будешь доказывать недоказуемое.:))

V>Юлить? :) Ню-ню. Если проблема действительно есть (хоть я ее и не пойму), ты это, в личку ТЗ скинь, мне ведь не сложно. А то ведь выясняется, то эти 4 значения процессору не нужны.

Не вижу никаких оснований в моих словах для такого вывода.

V> А кому нужны? А как именно нужны, т.е. интерфейс забора этих 4-х значений какой? А частоты и прочие характеристики? Как я тебе дам готовое решение, если описанное тобою даже на черновик ТЗ не тянуло? И я еще и юлю? Нахал...

Ага, ну просто безумное нахальство — вместо того, чтобы молчать в тряпочку и кланяться, даже чего-то возражаю. Во молодёжь невоспитанная пошла...

N>>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?;))
V>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.

Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.:)

V>>>Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор? ;) ).

N>>Да-да. И терять при этом в эффективности за счёт того, что данные вечно бегают из памяти в этот единственный аккумулятор и обратно.

V>Ниче не понял... Мы по RISC говорим, или CISC, с переупорядочиванием, переименованием и прочим одновременным исполнением независимых операций?

Про RISC, про RISC. Ты в курсе скорости работы RAM по сравнению с процессором? Да, по сравнению с архитектурой стиля 6502 мы имеем регистровый файл как кэш нулевого уровня. И что в этом плохого? Не зря большинство архитектур сейчас целятся на 16-32 регистра, если не больше — потому что такой кэш как раз оптимален. А ты предлагаешь не то нулевую страницу применить, не то вообще неведомую шлёпанную херню. И нафига?

N>>Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

V>Именно что больше регистров. А сколько конкретно надо? Много сделаешь — много сохранять при переключении задач, и вот тут недавно воевали насчет использования файлов SSE в ядре ОС, вернее неиспользовании, чтобы не сохранять его. А сделаешь регистров мало — ты не доволен. :)

Да, недоволен. Потому что оптимум для современных задач — в районе тех же 16-32 регистров. Вроде ближе пока к 16, но твёрдо не уверен — давно не смотрел тематику.
Сохранять при переключении задач? Да, сохранять. Но посмотри, например, на Sparc. Там этот вопрос решается достаточно гибко — если задача много не хочет, можно много и не сохранять. Кажется, можно на ходу менять пределы сохранения, но твёрдо не уверен. в IA64 другой подход, но тоже гибкий.

V> Посмотрел бы на байт-код дотнета, хотя бы. Локальная стековая память, которая заведомо относится к одному текущему потоку — чем не файл регистров произвольно требуемого размера? :xz: Понимаешь, технология кэш-памяти постепенно стирает различия м/у файлом регистров и страницей памяти, отображенной в кэш.

Плохой, негодный пример. Во-первых, компьютер — не среда дотнета: иногда стека вообще нет, иногда кэш может быть не включён. Во-вторых, ты не пробовал взять ручку и подсчитать регистры в минимальном варианте?
* два аккумулятора (ой только не надо 6502 вспоминать. два нужны хотя бы для операций умножения и деления)
* два индексных регистра (ты сам сказал про два)
* указатель стека
* указатель TLS (извините, такое на стеке не хранят)
* счётчик команд

Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.

А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?

Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.

V>>> Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там.
N>>Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.
V>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм? :xz:
V>Дело, как обычно, в софте.

Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.

V>Да, современные процы делают то, что могли бы делать компиляторы. Я уже высказывался, что не против этого, но эту концепцию надо использовать до конца, т.е. входной код должен быть более для этого приспособлен.

Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?

V>>> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.
N>>Ну да, просто убивая возможность анализа на корню. Пусть компилятор думает, у него голова большая.
V>Надеюсь, теперь ты так не считаешь. Если не понимаешь, посмотри как работает JIT-компилятор дотнета. Он проще, чем декомпилятор x86-го, вот в чем прикол.

Где посмотреть? И у меня нет пары дней закопаться в детали.

N>>>>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>>>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. :xz: У Интела "прошивка" однократная, у тех настраиваемая.
N>>>>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)
V>>>Тогда с чего ты решил, что избегают этого термина?
N>>потому что у них "микрокод", а не firmware.
V>Ну а в ветке, куда ты подключился, было именно firware. :)))

Угу, и при этом никто не мог договориться, что именно имеется в виду.

N>>Да, мне действительно теперь понятно — что цепляясь за нелепый устарелый термин ты теряешь суть.
V>Я не цепляюсь, я разъясняю, что он означает. :)
V>Если ты сутью называешь свои абстракции, то я их теряю, разумеется, когда мы говорим о значении терминов. Чтобы не было разночтений. Ты понимаешь, чем отличается конвеер команд 8086 и современный конвеер? И интереса ради, какова разрядность современного внутреннего конвеера? И что именно в нем содержится? По сути, этот вопрос содержит ответ, и если найдешь ответ — вопросы отпадут.

Ну так для себя у меня вопросов и не было. Это ты завёл разговор в такую область, что мы зачем-то не можем договориться.:)

V>Не знаю как заставить тебя отойти от абстракций к конкретике. Сложно общаться, ей-богу. "Входной код" — это твоя абстракция, когда ты смотришь на процессор как на черный ящик. А для процессора как автомата — это входные сигналы.

У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет). Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".

V>Возможно тут произошла мутация термина. Если в 386-м эти управляющие сигналы непосредственно подавали на управляющие блоки, то в 486-м, выполнив по асинхронной схеме работу с памятью, эти управляющие сигналы сложили в очередь, т.е. сохранили их последовательность.

Если в 086 был конвейер, то он и был этой очередью.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, netch80, Вы писали:

N>>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
CC>ICC

Интересно. Можно пример входного и выходного кода?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vdimas, Вы писали:

V>>>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".
N>>>Ничего себе "частности", всё нутро поменялось до неузнаваемости.
V>>Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира.

N>Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.

Слушай, а чего ты вообще к PPro прицепился? Я вот его в глаза не видел и ни один из коллег, с кем знаком лично, тоже его не видел. Изменения в указанной последовательности Пентиум->Пентиум II практически идентичны изменениям Пентиум->Пентиум Про. Я же показывал смену поколений, т.е. если бы указал ППро, надо было бы не указывать П2. А это не справедливо, ибо популярность в те времена П2 и ППро абсолютно несравнима. Или ты типа нашел за что меня поймать?

Ну это несерьезно. Если интересуют подробности, то да, когда-то давно, до того как к нас в город пришел нормальный интернет, я выписывал "компьютерное обозрение" и очень внимательно следил за соревнованием процов примерно до 2000-2001-го года, потом надоело.

V>>Хоть одно не косметическое, влияющее на архитектуру ядра?

N>Устранение северного моста и прямое управление памятью.

Мимо, шинный формирователь никуда не делся, просто теперь он в процессоре. Но не в ядре. Помнишь, я говорил о различиях микропроцессоров и микроконтроллеров. Так вот, микроконтроллер — это ядро микропроцессора + некоторая периферия прямо в проце. Для примера посмотри на AMD Alchemy, там ядро известной архитектуры, и куча периферии на кристалле. Есть много разновидностей Alchemy, отличающихся периферией, но ядро идентично для них всех. Поэтому извини, но мимо. Даже если вообще всю оперативку в процессор запихают, как на многих микроконтроллерах, это не будет относится к ядру, а будет классическим SoC.

N>Внос видеоконтроллера в процессор (в моделях, где он есть).

Из той же оперы. Я же задал вопрос не про микросхему, как таковую, а про ядро, т.е. про сам процессор.

N>>>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.
V>>Во-первых, как это сломана? Если 64-битные винды спокойно напрямую запускают 32-битные приложения, а не в окне эмулятора, то для пользователя никакая совместимость не сломана.

N>Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.

Э нет, два несовместимых ядра в гибриде, или же одно ядро с доработанным дешифратором и удвоенной разрядностью АЛУ — это две большие разницы. И все равно из этого сумбура (выделил) я не понял, как amd-x64 ломает совместимость. Обратная совместимость не сломана, а "прямой" быть не может в случае любого расширения набора команд, необязательно в сторону расширения битности.

Плохо в расширениях команд x86-го все это годы в том, что расширения идут через ограниченное мн-во префиксов, удлиняя код команды. Отсюда бинарники, использующие новомодные инструкции выходят довольно большими. Вот за весь этот наследованный груз и критикуют систему команд. Даже тот же набор команд (мнемонический их набор), если закодировать с 0-ля, можно получить куда как более оптимальное использование байт кода.

N>Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.

Нет, они пошли правильно, доводя до абсолюта две идеи: сверхдлинный конвейер и сверхширокие команды. Сейчас длина конвейеров тоже довольно большая, просто первый блин комом, им надо было постепенно развивать отличный (самый удачный ИМХО, если позиционировать на технологии "своего времени") Пень-3. А сейчас технологически реально Интелл отстает, и значительно. Они держат лидерство исключительно за счет экстенсивных факторов: это кол-во ядер на кристалл + раньше всех переходят на более миниатюрный процесс.

N>>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

V>>Ну и почему? Разве не понятно?

N>Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.

Из-за цены. Вторые пни пошли по реально низким ценам, Интеллу удалось взять реванш за K-5, которые практически полностью задавили первый пентиум. Твой любимый Пень-Про в массы не пошел, если помнишь. И я скажу почему — исключительно из-за цены, хотя этот проц, судя по публикуемым характеристикам, был не плох.

N>Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

(остальное потом)

Здравствуйте, netch80, Вы писали:

N>>>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
CC>>ICC

N>Интересно. Можно пример входного и выходного кода?

Ну навскидку например вот:

void SerialCorrelation::Update (const void* buf, DWORD len)
{
    const BYTE* buffer = (const BYTE*)buf;

    while (len--)
    {
        double value = *buffer++;

        if (!m_total) 
            m_first = value;
        else m_sumLast += m_last * value;

        m_sum += value;
        m_sumSq += value * value;
        m_last = value;
        
        m_total++;
    }
}

    PUBLIC ?Update@SerialCorrelation@@QAEXPBXK@Z
?Update@SerialCorrelation@@QAEXPBXK@Z    PROC NEAR 
; parameter 1: ecx
; parameter 2(buf): 16 + esp
; parameter 3(len): 20 + esp
.B1.1:                          ; Preds .B1.0

;;; {

$LN1:
        push      esi                                           ;27.1
        sub       esp, 8                                        ;27.1
$LN3:

;;;     const BYTE* buffer = (const BYTE*)buf;
;;; 
;;;     while (len--)

        cmp       DWORD PTR [20+esp], 0                         ;30.2
        je        .B1.11        ; Prob 0%                       ;30.2
                                ; LOE ecx ebx ebp edi
.B1.2:                          ; Preds .B1.1
$LN5:

;;;     {
;;;         double value = *buffer++;
;;; 
;;;         if (!m_total) 

        mov       esi, DWORD PTR [ecx]                          ;34.3
        mov       eax, DWORD PTR [4+ecx]                        ;34.3
$LN7:

;;;             m_first = value;
;;;         else m_sumLast += m_last * value;
;;; 
;;;         m_sum += value;

        movsd     xmm0, QWORD PTR [32+ecx]                      ;38.3
$LN9:

;;;         m_sumSq += value * value;

        movsd     xmm1, QWORD PTR [40+ecx]                      ;39.3
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
.B1.3:                          ; Preds .B1.2
$LN11:
        je        .B1.10        ; Prob 10%                      ;30.2
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
.B1.4:                          ; Preds .B1.11 .B1.3
        xor       edx, edx                                      ;
        mov       DWORD PTR [4+esp], edi                        ;
        mov       DWORD PTR [esp], ebx                          ;
        mov       ebx, DWORD PTR [16+esp]                       ;
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1
.B1.5:                          ; Preds .B1.8 .B1.4
$LN13:
        movzx     edi, BYTE PTR [edx+ebx]                       ;32.16
        cvtsi2sd  xmm3, edi                                     ;32.16
$LN15:
        mov       edi, esi                                      ;34.3
        or        edi, eax                                      ;34.3
        jne       .B1.7         ; Prob 50%                      ;34.3
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.6:                          ; Preds .B1.5
$LN17:
        movsd     QWORD PTR [8+ecx], xmm3                       ;35.4
        jmp       .B1.8         ; Prob 100%                     ;35.4
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.7:                          ; Preds .B1.5
$LN19:
        movsd     xmm2, QWORD PTR [16+ecx]                      ;36.8
        mulsd     xmm2, xmm3                                    ;36.8
        addsd     xmm2, QWORD PTR [24+ecx]                      ;36.8
        movsd     QWORD PTR [24+ecx], xmm2                      ;36.8
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.8:                          ; Preds .B1.6 .B1.7
$LN21:
        addsd     xmm0, xmm3                                    ;38.3
        movsd     QWORD PTR [32+ecx], xmm0                      ;38.3
$LN23:
        movaps    xmm2, xmm3                                    ;39.3
        mulsd     xmm2, xmm3                                    ;39.3
$LN25:

;;;         m_last = value;
;;;         
;;;         m_total++;

        add       esi, 1                                        ;42.3
        adc       eax, 0                                        ;42.3
$LN27:
        inc       edx                                           ;30.2
        cmp       edx, DWORD PTR [20+esp]                       ;30.2
$LN29:
        addsd     xmm1, xmm2                                    ;39.3
        movsd     QWORD PTR [40+ecx], xmm1                      ;39.3
$LN31:
        movsd     QWORD PTR [16+ecx], xmm3                      ;40.3
$LN33:
        mov       DWORD PTR [ecx], esi                          ;42.3
        mov       DWORD PTR [4+ecx], eax                        ;42.3
$LN35:
        jb        .B1.5         ; Prob 82%                      ;30.2
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1
.B1.9:                          ; Preds .B1.8
        mov       edi, DWORD PTR [4+esp]                        ;
        mov       ebx, DWORD PTR [esp]                          ;
                                ; LOE ebx ebp edi
.B1.10:                         ; Preds .B1.11 .B1.9 .B1.3

;;;     }
;;; }

$LN37:
        add       esp, 8                                        ;44.1
        pop       esi                                           ;44.1
        ret       8                                             ;44.1
                                ; LOE
.B1.11:                         ; Preds .B1.1                   ; Infreq
        xorps     xmm1, xmm1                                    ;
        movaps    xmm0, xmm1                                    ;
        mov       esi, 0                                        ;
        mov       eax, esi                                      ;
        jne       .B1.4         ; Prob 90%                      ;
        jmp       .B1.10        ; Prob 100%                     ;
        ALIGN     16
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
; mark_end;
?Update@SerialCorrelation@@QAEXPBXK@Z ENDP
.LN?Update@SerialCorrelation@@QAEXPBXK@Z:
;?Update@SerialCorrelation@@QAEXPBXK@Z    ENDS
_TEXT    ENDS

Касательно эффективности:
(первая цифра — время в тиках, вторая — в секундах, третья — результат выполнения)

E:\Temp\1>TestFPU.exe
781'364'936 0.354324 0.000107

E:\Temp\1>TestFPU.exe
782'137'356 0.354674 0.000107

E:\Temp\1>TestFPU.exe
781'556'457 0.354410 0.000107

E:\Temp\1>TestFPU.exe
781'267'476 0.354279 0.000107

E:\Temp\1>TestFPU.exe
781'008'800 0.354162 0.000107

E:\Temp\1>TestSSE.exe
659'993'378 0.299285 0.000107

E:\Temp\1>TestSSE.exe
659'511'996 0.299067 0.000107

E:\Temp\1>TestSSE.exe
660'818'675 0.299524 0.000107

E:\Temp\1>TestSSE.exe
659'963'150 0.299272 0.000107

E:\Temp\1>TestSSE.exe
660'893'662 0.299693 0.000107

Пример конечно мелкий, но всё равно разница составляет ~15% на полностью автоматической генерации.
Пример побольше займёт много страниц asm кода и пару страниц C++ кода. Даже не говоря о том, что я тот код публиковать не могу.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, netch80, Вы писали:

N>Есть пословица: кто не хочет учить свою историю — будет учить чужую. Ты отвергаешь PPro только потому, что он "непопулярен", значит, ты рассказываешь ложную историю. В сочетании с крайне странным подходом к тому, что есть важное изменение, а что нет — выглядит как попытка навязывания искажённого образа.

Угу, заклинило. Я уже понял, что тебе хотелось продемонстрировать некую причастность к ППро, молодец. Однако, для демонстрации смены архитектуры, привязанннойко времени, моя последовательность тоже не плоха, чтобы ты там не говорил. Ты все время путаешь архитектуру и частости, например, упоминая свои 128 бит float. Это не есть разница в архитектуре. Например, есть куча тех-же PIC-контроллеров с разной разрядностью, но абсолютно идентичной архитектурой ядра.

N>Я не слежу за микропоколениями, эта информация в случае чего легко находится (и я в упор не помню, чем там Sledgehammer был лучше Clawhammer). Но основные вехи надо помнить, если ты вообще взялся что-то говорить про историю.

Кому надо?

N>Не "мимо", а он теперь совсем другой.

Он для каждой новой памяти другой, ибо другие спецификации, и что с того?

N>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?

Да, все кеши, кроме того, с которым работает непосредственно ядро — периферия. Это как инкапсуляция в ООП, при сохранении интерфейса не суть важно что за ним.

N>А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.

Чтобы сказать более точно, мне надо взглянуть на архитектуру. Там одно от другого отделить в принципе очень просто, т.е. если доступ по внешней, по отношению к ядру шине, то оно вне ядра, хоть даже и на одном кристалле. Вот это и есть единственный аргумент, а остальное — банальный SoC.

V>>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

N>Не понял — чем тут три цикла лучше или хуже?

Описка, предполагалось "цикл в три такта". Для x86 тот же исходник генерит около 50-ти команд, т.е. это будет порядка 30 тактов. Причем, задача плохо параллелится на потоковом параллелизме, ибо там вычислений по-сути никаких, только чтение-запись памяти, граф объектов — он один, и многократно зациклен взаимными ссылками. Т.е. выделить независимые данные для потокового паралелизма не получается, зато прекрасно получается оптимизировать код для явного.

Здравствуйте, netch80, Вы писали:

V>>Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?

N>Спор превращаешь в фарс ты. Это ж надо — упорно доказывать, что никто ничего нового в мире железа не разрабатывает... да, у меня примеры из моей области, и я намеренно беру простые (есть и сложные, но мне облом тратить три страницы на объяснение, нафига оно надо и почему такое). В процессорах тебе, видите ли, ничего нового. Я контрпример привёл — прими его.

Извини, но ты привел пример из области разработки периферии. Вот пройдись по фирмам, которые выпускают SoC. Они предлагают обычно на одном кристалле совместить какое-нить ядро проца общего назначения (обычно MIPS или ARM), добавить какое-нить ядро DSP, иногда с готовой прошивкой для популярных аудио и видео форматов, добавить какую-нить периферию, например контролер памяти, или даже некоторую память прямо на кристалл, добавить USB, I2C и т.д. А теперь представь, это они просто рядом расположили на кристалле и оно само работает?

Понятное дело, что надо сопрягать и всякое такое, но эта задача примерно на порядок сложнее твоей с регистром, но не 4-5 порядков, как в случае разработки нового ядра процессора. Доработать обвеску и доработать ядро под конкретные нужды — это две большие разницы, ибо объем разработки и тестирования несопоставим.

N>Не хочешь — докажи, что ничего нового не происходит. А я посмотрю, как ты будешь доказывать недоказуемое.

Ответил рядом на первую половину.

N>Ага, ну просто безумное нахальство — вместо того, чтобы молчать в тряпочку и кланяться, даже чего-то возражаю. Во молодёжь невоспитанная пошла...

Ты не возражаешь, ты дал мало инфы, а потом раскритиковал мое решение, да еще я так и не понял насчет "юлить". Я могу более четко повторить: разработка "своего" ядра — это крайне дорогое удовольствие, особенно оно дорогое, если будет разрабатываться своя система команд, потому как надо будет разработать эту непротиворечивую систему команд, и весь tool-chain к ней. Это я тебе просто напоминаю, в какое обсуждаение ты встрял. Так вот, в случае декодеров, т.е. DSP, система команд DSP обычно определяет архитектуру ядра, ибо это честный VLIW RISC, безовсяких переименований, out-of-order и т.д., ибо эти вещи делаются компилятором, но не процом. Поэтому я и был так уверен в той подветке, что никакое ядро специально никто для этого кодека не разрабатывал. Да хороший компилятор под DSP сегодня разработать дороже выйдет даже, чем спроектировать ядро, тут не о чем спорить.

N>>>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?

)
V>>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.

N>Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.

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

N>Плохой, негодный пример. Во-первых, компьютер — не среда дотнета: иногда стека вообще нет, иногда кэш может быть не включён. Во-вторых, ты не пробовал взять ручку и подсчитать регистры в минимальном варианте?
N>* два аккумулятора (ой только не надо 6502 вспоминать. два нужны хотя бы для операций умножения и деления)
N>* два индексных регистра (ты сам сказал про два)
N>* указатель стека
N>* указатель TLS (извините, такое на стеке не хранят)
N>* счётчик команд

N>Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
N>Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.

Я многое поскипал, ибо ты одно и то же говоришь. Но тебе двойка за невнимательность. Я говорил о байт-коде, который подается CISC процу. Пусть процессор внутри имеет 16/32 реагистров, да сколько угодно, это его дело, ибо CISC все-равно полностью переделывает входной код под внутренние регистры. И пусть он сохраняет внутренние регистры, это же делается одной командой. Задача драйвера будет лишь выделить нужное кол-во памяти в данных потока для данной модели проца. Ты хорошо сказал про гибкость во время сохранения кол-ва регистров, только не довел эту мысль до конца. А повторяться о том, что байт-код уровня дотнета гораздо более поддается анализу, чем x86, смысла нет, ибо это более чем очевидно.

Понимаешь, после компиляции программ я вижу кучу пар push/pop, когда компилятор жонглирует временными результатами вычислений. Прикол в том, что сегодня проц не имеет права оптимизировать такие вещи, поэтому это все тормозит вычисления, ибо проц оперирует с реальной памятью, а не файлом регистров. Если же заведомо объявить архитектуру работающей по верифицированному коду, т.е. когда есть гарантии целостности стека, то для описания алгоритма достаточно будет пары индексных регистров и аккумулятора (пусть с твоими поправками насчет удвоенной его разрядности). И не надо путать эти регистры как абстракции входного байт-кода с реальными регистрами, требуемыми для исполнения этого кода, получаемыми после всех оптимизаций и переименований внутри проца. И оптимальное кол-во регистров, разумеется, разное для разных задач. Для некоторых задач и 32 мало, поэтому "гибкость" в плане сохранения регистров будет развиваться и далее.

N>А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?

Ну ты нить разговора потерял, очевидно.

N>Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.

Считать могут все, только тут нечего считать. Очень сложно в одном процессоре учесть все вооразимые алгоритмы, на нем прогоняяемые. Поэтому на разных задачах одни и те же процы могут как выигрывать друг у друга более 100% производительности, так и проигрывать столько же на других задачах. Поэтому мне нравится подход Sun, с их заведомо большим файлом регистров. Тут ведь чем больше, тем лучше, а ограничения пусть уже сама задача указывает, ибо она лучше процессора знает, как ей лучше.

V>>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм?

V>>Дело, как обычно, в софте.

N>Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.

Да, грузить архитектуру по полной. Я понимаю, что в gсс такого нет, о том и речь.

V>>Да, современные процы делают то, что могли бы делать компиляторы. Я уже высказывался, что не против этого, но эту концепцию надо использовать до конца, т.е. входной код должен быть более для этого приспособлен.

N>Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?

К Эльбрусу уже отсылал. К современным процам от Sun тоже. Их архитектуры, будь у них такой же процесс изготовления в распоряжении, как у Интелл, надрали бы задницу легко.

N>Где посмотреть? И у меня нет пары дней закопаться в детали.

Я тебя огорчу, парой дней там не обойдешься. В кратце — очень сильно упрощает анализ кода некие гарантии, суть ограничения, которыми обложен байт-код по спецификации. Т.е. память у нас не совсем идет как фон-неймановская, для абстракции стека гарантируется во-первых его целостность, во-вторых — доступ лишь из текущего потока, т.е. стек не рассматривается как общая память. Ввиду этого, команды обращения к данным по смещению указателя стекового фрейма, не обязательно выполнять явно, т.е. писать/читать из внешней памяти, а можно распихивать на все регистры имеющегося файла у данной архитектуры процессора. Именно это я и имел ввиду, предлагая упрощенный байт-код, оперирующий минимум абстракций. Ведь в любом случае, архитектура x86 — это не более чем абстракция, которая переводится во внутреннее представление. Просто входная абстракция не очень, особенно вот эти push/pop, и спец. команды, которые могут быть выполнены лишь на некоторых регистрах.

N>Угу, и при этом никто не мог договориться, что именно имеется в виду.

Я лишь спорил против того, что H.264 декодируется "аппаратно", и утверждал, что там DSP+прошивка.

N>У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет).

"Он" это кто? Если ядро проца — то у к нему данные и код по разным шинам подходят от кеша первого (в другой терминологии 0-го) уровня. Сигналы — это программный код (вернее, часть сигналов), данные же идут на исполнительные механизмы, и напрямую на состояние процессора не влияют. (лишь коссвенно, через биты состояний акумулятора)

N>Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".

Ниче не понял. Ты про защиту памяти? Дык она с т.з. процессора, как исполнительного блока, тоже "инкапсулирована" через интерфейсы, т.е. управляется отдельным механизмом. Не зря на одном и том же ядре делали варианты с 2-мя и с 3-мя уровнями кешей.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:

N>>Есть пословица: кто не хочет учить свою историю — будет учить чужую. Ты отвергаешь PPro только потому, что он "непопулярен", значит, ты рассказываешь ложную историю. В сочетании с крайне странным подходом к тому, что есть важное изменение, а что нет — выглядит как попытка навязывания искажённого образа.

V>Угу, заклинило. Я уже понял, что тебе хотелось продемонстрировать некую причастность к ППро, молодец.

Я его не разрабатывал — к чему причастность-то? Элементарная справедливость.

V> Однако, для демонстрации смены архитектуры, привязанннойко времени, моя последовательность тоже не плоха, чтобы ты там не говорил. Ты все время путаешь архитектуру и частости, например, упоминая свои 128 бит float.

А я и не говорил, что это свойство его архитектуры. Хотя подумать стоит — например, объединение FP соседних процессоров — уже архитектурное решение.

N>>Я не слежу за микропоколениями, эта информация в случае чего легко находится (и я в упор не помню, чем там Sledgehammer был лучше Clawhammer). Но основные вехи надо помнить, если ты вообще взялся что-то говорить про историю.
V>Кому надо?

Извини, я не знаю, как ответить на этот вопрос вежливо.

N>>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?
V>Да, все кеши, кроме того, с которым работает непосредственно ядро — периферия. Это как инкапсуляция в ООП, при сохранении интерфейса не суть важно что за ним.

Тогда ты очень странно понимаешь слово "архитектура". Для тебя это — какие блоки есть и что они делают, причём на самом верхнем уровне?

N>>А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.
V>Чтобы сказать более точно, мне надо взглянуть на архитектуру. Там одно от другого отделить в принципе очень просто, т.е. если доступ по внешней, по отношению к ядру шине, то оно вне ядра, хоть даже и на одном кристалле. Вот это и есть единственный аргумент, а остальное — банальный SoC.

Таким образом можно отделить что угодно. Например, FPU. И даже целочисленный АЛУ — он ведь не участвует в собственно исполнении команд... и что у тебя остаётся от процессора?

Нормальный метод деления — всё-таки логический по функциональности.

V>>>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).
N>>Не понял — чем тут три цикла лучше или хуже?
V>Описка, предполагалось "цикл в три такта". Для x86 тот же исходник генерит около 50-ти команд, т.е. это будет порядка 30 тактов. Причем, задача плохо параллелится на потоковом параллелизме, ибо там вычислений по-сути никаких, только чтение-запись памяти, граф объектов — он один, и многократно зациклен взаимными ссылками. Т.е. выделить независимые данные для потокового паралелизма не получается, зато прекрасно получается оптимизировать код для явного.

Ладно, sweep написали хорошо (хотя тот sweep сейчас разве что в учебных задачах нужен). И всё? Хотелось бы видеть несколько классов задач...

Здравствуйте, netch80, Вы писали:

N>>>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?
V>>Да, все кеши, кроме того, с которым работает непосредственно ядро — периферия. Это как инкапсуляция в ООП, при сохранении интерфейса не суть важно что за ним.

N>Тогда ты очень странно понимаешь слово "архитектура". Для тебя это — какие блоки есть и что они делают, причём на самом верхнем уровне?

Ключевое слово здесь не "архитектура", а "ядро". Ты все время скатываешься на описание микросхемы, а речь о собственно ядре процессора. Я же тебе давал затравку — известны случаи, когда на одном и том же ядре делали варианты с 2-мя и с 3-мя уровнями кешей, т.е. ядру в принципе пофиг, что происходит за кешем 0-го уровня, ибо этим занимается отдельный механизм.

V>>Чтобы сказать более точно, мне надо взглянуть на архитектуру. Там одно от другого отделить в принципе очень просто, т.е. если доступ по внешней, по отношению к ядру шине, то оно вне ядра, хоть даже и на одном кристалле. Вот это и есть единственный аргумент, а остальное — банальный SoC.

N>Таким образом можно отделить что угодно. Например, FPU. И даже целочисленный АЛУ — он ведь не участвует в собственно исполнении команд... и что у тебя остаётся от процессора?

Вот еще. Были добавлены 75 новых команд для работы с FPU, сами регистры FPU теперь адресовались непосредственно и это значит, что эти регистры были доступны из общей внутренней шины. А сколько инструкций было добавлено для работы с видеосопроцессором?

N>Нормальный метод деления — всё-таки логический по функциональности.

Да все методы нормальные, смотря с какой целью выполняется декомпозиция. Если тебе более понятно из ПО, то деплой и логическое деление — две большие разницы, порой существенно влияющие на издержки. Первое деление обычно более крупное, но бывает ровно наоборот.

В принципе, даже если они полностью интегрируют видеосопроцессор в ядро (хотя непонятно, почему бы просто не добавить обычных ядер с очередным расширением какого-нить SSE5), то пока это не будет означать серьезных изменений архитектуры ядра, это по прежнему будет экстенсивное наращивание вычислительных блоков. Или ты считаешь, что их ядро уже устоялось, и в принципе не нуждается в модернизации? Глядя на то, что AMD ядра на той же частоте работают практически в полтора раза быстрее, и AMD медленно, но верно догоняет Intel по частоте ядра, я так не считаю. На самом деле, когда они захотят поместить туда более 16-ти ядер, вот тут встанет вопрос о смене архитектуры. Дело в том, что сейчас ресурсы ядра простаивают в среднем на 70%, т.е. каждое ядро обладает таким набором исполнительных механизмов, которое редко задействуется одновременно. Гипертрединг спасает, но эту идею тоже надо доводить до ума, делая настоящие многопоточные ядра, т.е. размывая само понятие современного ядра, которое концентрируется вокруг дешифратора/шедуллера и очереди. Шедуллеров/очередей может быть несколько, исполнительных механизмов, расшаренных м/у шедуллерами тоже. В принципе, у современных ядер Интелл уклон в эту область, но опять же, Sun уже пошел в этом направлении гораздо дальше, показывая большую производительность в пересчете на вентиль (противоположное направление — это Cell, т.е. разнородные ядра на кристалле, и сложности с ПО к ним, как показал твой пример с компиляцией).

N>Ладно, sweep написали хорошо (хотя тот sweep сейчас разве что в учебных задачах нужен). И всё? Хотелось бы видеть несколько классов задач...

Любые числодробилки стабильно показывают до 400%-600% прироста производительности на ядро при той же тактовой, даже с учетом всех SSE, ибо последний в реальных приложениях более 2-х раз ускоряет редко (по своему опыту). Вот тут в сообщении ссылка: http://rsdn.ru/forum/education/3775434.1.aspx, и вообще в той теме обсуждали достаточно. VLIW особенно интересен "многоэтажными" командами, типа за один такт вычислить следующее (a*b)+(c/d), да еще и разветвиться потом по результату.

Интересно в том документе, что в некоторых тестах показаны результаты Итаниума, который например в задачах умножения матриц на вдвое меньшей частоте показывает вдвое большую производительность, чем Xeon, поэтому обзывать Итаниум плохими словами преждевременно. Надо просто довести до ума, т.к. на многих классах задач VLIW однозначно рулит. (Кстати, "частотная" производительность Эльбрус в 2 раза выше Итаниума, т.е. если привести все к одной частоте). И еще интересный момент в том, что будучи и процессором общего назначения и VLIW, Эльбрус значительно "дрючит" популярные производительные DSP (которые тоже давно VLIW, просто малость упрощенные).

На самом деле многоядерный VLIW как раз и позволит полностью отказаться от каких-либо видеосопроцессоров и прочих DSP сопроцессоров, ибо те и есть VLIW, но выполненные по компромиссным схемам, дабы не стоить в 10 раз дороже центрального процессора.

Это вкратце, почему я считаю, что Интелл пошла по верному пути со своими Итаниумами, просто остановилась на пол-пути. Выпустила бы 8-миядерный Итаниум хотя бы на 2.4 ГГЦ тактовой — конкурентов бы не было.

Здравствуйте, vdimas, Вы писали:

V>Извини, но ты привел пример из области разработки периферии. Вот пройдись по фирмам, которые выпускают SoC. Они предлагают обычно на одном кристалле совместить какое-нить ядро проца общего назначения (обычно MIPS или ARM), добавить какое-нить ядро DSP, иногда с готовой прошивкой для популярных аудио и видео форматов, добавить какую-нить периферию, например контролер памяти, или даже некоторую память прямо на кристалл, добавить USB, I2C и т.д. А теперь представь, это они просто рядом расположили на кристалле и оно само работает? :)

V>Понятное дело, что надо сопрягать и всякое такое, но эта задача примерно на порядок сложнее твоей с регистром, но не 4-5 порядков, как в случае разработки нового ядра процессора. Доработать обвеску и доработать ядро под конкретные нужды — это две большие разницы, ибо объем разработки и тестирования несопоставим.

Верю. Только вот почему-то у одних это сопряжено качественно, а у других — совершенно на тяп-ляп, так, что оно вообще работать не может или работает через пень-колоду (блок X имеет рабочие частоты 5-50 МГц, Y — 45-200 МГц, в результате в единственном нужном тебе режиме остаётся 45-50). К чему это всё — к тому, что человеку свойственно лениться? Мне, как потребителю, это всё пофиг.

Это я не к тому, что нет объективных оценок сложности. Они, конечно, есть. Но останавливать работу только из-за того, что "ах! сложно!" — плохая идея. Я ж не предлагаю всё делать заново с нуля: ни в софте, ни в железе так не делают. Берётся готовое и дорабатывается, развивается. В конце концов, даже в проекте толщиной с gcc или линуксовое ядро можно сделать свою небольшую доработку — на это даже студент способен. У тебя же получается "ах! только мегагуру знает, как это вообще работает, а трогать... да никто кроме бога".

V>Ты не возражаешь, ты дал мало инфы, а потом раскритиковал мое решение, да еще я так и не понял насчет "юлить". Я могу более четко повторить: разработка "своего" ядра — это крайне дорогое удовольствие,

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

V> особенно оно дорогое, если будет разрабатываться своя система команд, потому как надо будет разработать эту непротиворечивую систему команд, и весь tool-chain к ней. Это я тебе просто напоминаю, в какое обсуждаение ты встрял. Так вот, в случае декодеров, т.е. DSP, система команд DSP обычно определяет архитектуру ядра, ибо это честный VLIW RISC, безовсяких переименований, out-of-order и т.д., ибо эти вещи делаются компилятором, но не процом. Поэтому я и был так уверен в той подветке, что никакое ядро специально никто для этого кодека не разрабатывал.

Чуть хакнули готовое.

V> Да хороший компилятор под DSP сегодня разработать дороже выйдет даже, чем спроектировать ядро, тут не о чем спорить.

Ну я и не спорю. Разработка качественного компилятора для таких средств очень дорога. И то — обычно критичные участки всё равно дорабатывают вручную.

V>>>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.
N>>Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.:)
V>Речь шла о процесорах для компов общего назначения, на этом рынке MIPS не видно и под микроскопом, просто ты многое за меня додумываешь.

Cisco на MIPS знаю. Это уже очень дохрена. Другой вопрос, что они как раз не хотели оптимизацию в стиле Transmeta.

N>>Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
N>>Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.
V>Я многое поскипал, ибо ты одно и то же говоришь. Но тебе двойка за невнимательность. Я говорил о байт-коде, который подается CISC процу. Пусть процессор внутри имеет 16/32 реагистров, да сколько угодно, это его дело, ибо CISC все-равно полностью переделывает входной код под внутренние регистры.

Тогда вообще непонятно, что ты доказываешь. Ты доказываешь, что надо минимизировать "промежуточное" представление кода, чтобы убрать паразитные зависимости, завышенные объёмы регистров и тэ дэ? Я показываю, что их и так немного (в основной рассматриваемой архитектуре) и минимизировать толком уже некуда. Вот увеличивать — да, можно.

V> И пусть он сохраняет внутренние регистры, это же делается одной командой. Задача драйвера будет лишь выделить нужное кол-во памяти в данных потока для данной модели проца.

Ага, и таблицы переименований... конечно, это можно сделать. Вопрос — зачем? Переключение контекстов, когда требуется сохранять регистры, и так операция достаточно дорогая. Впрочем, это надо считать. Но мне кажется, что затраты на запись этого всего в память превысят в разы возможную экономию от сохранения промежуточных результатов. 16 байт — 300 тактов. Пару тысяч тактов на то, что восстанавливается за десяток... ну спасибо.

V> Ты хорошо сказал про гибкость во время сохранения кол-ва регистров, только не довел эту мысль до конца. А повторяться о том, что байт-код уровня дотнета гораздо более поддается анализу, чем x86, смысла нет, ибо это более чем очевидно.

Конечно, легче перераспределить по фактическому оборудованию обобщённый код, чем специально подготовленный. Только вот описывать его надо или так, чтобы компилятор (возможно, JIT) точил под конкретное железо, или так, чтобы годилось под всё, но чтобы процессор мог это разобрать. Первый путь даёт VLIW. Второй — CISC.

А если ты будешь требовать от процессора понимания, что сделанный тобой K шагов назад push должен быть отработан парным pop — ты потребуешь нерабочую систему, и всё.

V>Понимаешь, после компиляции программ я вижу кучу пар push/pop, когда компилятор жонглирует временными результатами вычислений. Прикол в том, что сегодня проц не имеет права оптимизировать такие вещи, поэтому это все тормозит вычисления, ибо проц оперирует с реальной памятью, а не файлом регистров. Если же заведомо объявить архитектуру работающей по верифицированному коду, т.е. когда есть гарантии целостности стека, то для описания алгоритма достаточно будет пары индексных регистров и аккумулятора (пусть с твоими поправками насчет удвоенной его разрядности). И не надо путать эти регистры как абстракции входного байт-кода с реальными регистрами, требуемыми для исполнения этого кода, получаемыми после всех оптимизаций и переименований внутри проца. И оптимальное кол-во регистров, разумеется, разное для разных задач. Для некоторых задач и 32 мало, поэтому "гибкость" в плане сохранения регистров будет развиваться и далее.

Ну, во-первых, push/pop сейчас по крайней мере на x86 неэффективны. Грамотные компиляторы (вроде gcc) заранее сдвигают указатель стека, а затем используют смещение от %ebp или даже %esp. push/pop требуют слежения за изменениями позиции головы стека и поэтому крайне неэффективны. Лучше уж тогда возродить на новом уровне "нулевую страницу" (снова приходим к подходу имени IA64).

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

N>>А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?
V>Ну ты нить разговора потерял, очевидно.

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

N>>Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.
V>Считать могут все, только тут нечего считать. Очень сложно в одном процессоре учесть все вооразимые алгоритмы, на нем прогоняяемые. Поэтому на разных задачах одни и те же процы могут как выигрывать друг у друга более 100% производительности, так и проигрывать столько же на других задачах. Поэтому мне нравится подход Sun, с их заведомо большим файлом регистров. Тут ведь чем больше, тем лучше, а ограничения пусть уже сама задача указывает, ибо она лучше процессора знает, как ей лучше.

А мне нравится подход IA64. Да, тоже большой файл регистров, но заметь — во-первых, он разумно фиксированный, даже слишком большой (ну кому реально нужно более 96 регистров?), во-вторых, в пределах вертикальных переключений тривиально решается задача занять именно столько, сколько нужно, и не больше. У Сана же, во-первых, получаешь слишком много регистров, во-вторых, доступаться к ним через окно — извращение.

V>>>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм? :xz:
V>>>Дело, как обычно, в софте.
N>>Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.
V>Да, грузить архитектуру по полной. Я понимаю, что в gсс такого нет, о том и речь.

Дело не в gcc. Как ты собираешься описывать процессору исполнение этих тредов? Разнести их просто так по "тредам" в стиле HT — ничем не отличается от обычного распараллеливания в стиле OpenMP. Перед каждой командой ставить тег треда? Мало преимуществ перед автоматическим разбросом, особенно учитывая различие реальных архитектур; проблемы фальшстарта и сброса конвейера. В общем, проблем очень много.

V>>>Да, современные процы делают то, что могли бы делать компиляторы. Я уже высказывался, что не против этого, но эту концепцию надо использовать до конца, т.е. входной код должен быть более для этого приспособлен.
N>>Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?
V>К Эльбрусу уже отсылал. К современным процам от Sun тоже. Их архитектуры, будь у них такой же процесс изготовления в распоряжении, как у Интелл, надрали бы задницу легко.

Не надо вспоминать Sun. Тем более что с заводами у него было неплохо, но дело не в этом. Возьмём один и тот же Intel, у которого заводы полностью свои. Почему x86 на коне, а IA64 — наоборот? Где IA64 на 5ГГц? Дай ответ на последний вопрос, и ты сам поймёшь половину ситуации.

N>>Где посмотреть? И у меня нет пары дней закопаться в детали.
V>Я тебя огорчу, парой дней там не обойдешься. В кратце — очень сильно упрощает анализ кода некие гарантии, суть ограничения, которыми обложен байт-код по спецификации. Т.е. память у нас не совсем идет как фон-неймановская, для абстракции стека гарантируется во-первых его целостность, во-вторых — доступ лишь из текущего потока, т.е. стек не рассматривается как общая память. Ввиду этого, команды обращения к данным по смещению указателя стекового фрейма, не обязательно выполнять явно, т.е. писать/читать из внешней памяти, а можно распихивать на все регистры имеющегося файла у данной архитектуры процессора.

А можно просто L1+writeback, и это общим и дешёвым образом покроет все проблемы.

V> Именно это я и имел ввиду, предлагая упрощенный байт-код, оперирующий минимум абстракций. Ведь в любом случае, архитектура x86 — это не более чем абстракция, которая переводится во внутреннее представление. Просто входная абстракция не очень, особенно вот эти push/pop, и спец. команды, которые могут быть выполнены лишь на некоторых регистрах.

что "не очень" я согласен, но использование push и pop — это к кривым компиляторам. А спецкоманды — их что, много? В общем пуле действий я кроме умножения и деления таких не вижу, всё остальное отлично распределяется на 5-6 общих.

N>>У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет).
V>"Он" это кто? Если ядро проца — то у к нему данные и код по разным шинам подходят от кеша первого (в другой терминологии 0-го) уровня.

Представь себе, что кэша нет.

V> Сигналы — это программный код (вернее, часть сигналов), данные же идут на исполнительные механизмы, и напрямую на состояние процессора не влияют. (лишь коссвенно, через биты состояний акумулятора)

Ну ещё всякие jmp по регистру забыл. Но даже с этой поправкой такое рассмотрение — Обстракция с большой буквы О. Надо считать состояние с учётом реальных факторов.

N>>Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".
V>Ниче не понял. Ты про защиту памяти?

Нет.

	От:	squid
	Дата:	18.04.10 16:26
	Оценка:	1 (1) +2 -2

	От:	Шахтер
	Дата:	17.04.10 10:29
	Оценка:	+1 -5

	От:	sndanil
	Дата:	18.04.10 14:16
	Оценка:	4 (2) +2

	От:	quwy
	Дата:	19.04.10 10:50
	Оценка:	1 (1) +2 -2

	От:	Sheridan
	Дата:	18.04.10 12:03
	Оценка:	+2 -2

	От:	Pavel Dvorkin
	Дата:	19.04.10 03:49
	Оценка:	2 (1) +2

	От:	Roman Odaisky
	Дата:	15.04.10 20:50
	Оценка:	1 (1) +1

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	21.04.10 00:24
Оценка:	+3

От:	Mamut	http://dmitriid.com
Дата:	19.04.10 12:30
Оценка:	+2

	От:	CreatorCray
	Дата:	19.04.10 11:14
	Оценка:	1 (1)

	От:	LuciferSaratov
	Дата:	18.04.10 21:14
	Оценка:	+1

	От:	Константин Б.
	Дата:	23.04.10 11:18
	Оценка:	+1

От:	netch80	http://netch80.dreamwidth.org/
Дата:	16.05.10 06:45
Оценка:	+1

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	17.04.10 13:16
Оценка:

	От:	Воронков Василий
	Дата:	19.04.10 18:11
	Оценка:

	От:	vdimas
	Дата:	20.04.10 06:38
	Оценка:	+2

	От:	Torie
	Дата:	20.04.10 07:46
	Оценка:	+2

	От:	vdimas
	Дата:	20.04.10 09:32
	Оценка:	+1 -1

	От:	Ночной Смотрящий
	Дата:	19.04.10 22:14
	Оценка:

От:	dr.Chaos	Украшения HandMade
Дата:	20.04.10 09:31
Оценка:

	От:	Тот кто сидит в пруду
	Дата:	21.04.10 15:06
	Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	29.04.10 16:00
Оценка: