Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Там не десяток функций ядра, а правктически все ядро. PD>Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?
Алгоритмически — вполне молет быть и сложнее.
Вообще не понятно к чему ты тут это бинаремеряние развёл.
Объём бинарного кода в общем случае слабо связан со сложностью реализуемых им алгоритмов.
Например если посмотреть на demoscene в номинациях <=64k то окажется что колво сложной математики на единицу объёма там рвёт ядро ОС как тузик грелку.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, CreatorCray, Вы писали:
CC>Алгоритмически — вполне молет быть и сложнее.
Может, и еще как. Но я про алгоритмическую сложность не говорил.
CC>Вообще не понятно к чему ты тут это бинаремеряние развёл. CC>Объём бинарного кода в общем случае слабо связан со сложностью реализуемых им алгоритмов.
Совершенно верно. Я просто пытаюсь объяснить, что если код, зависимый от употребления или неупотребления SSE, вынести в отдельную DLL да так, чтобы там ничего, кроме этого кода не было, да сделать несколько таких DLL (без SSE / SSE1 /SSE2...), то размер инсталляционного пакета изменится незначительно.
With best regards
Pavel Dvorkin
Re[26]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Совершенно верно. Я просто пытаюсь объяснить, что если код, зависимый от употребления или неупотребления SSE, вынести в отдельную DLL да так, чтобы там ничего, кроме этого кода не было, да сделать несколько таких DLL (без SSE / SSE1 /SSE2...), то размер инсталляционного пакета изменится незначительно.
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.
Re[24]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Там не десяток функций ядра, а правктически все ядро. PD>Ну а если ты считаешь, что кодек сложнее ОС — о чем тогда говорить ?
Назови хоть один из алгоритмов ядра ОС, который действительно тяжеловесен в плане объема кода?
PD>>>И это далеко не все. И про win32k.sys я могу такое же найти.
V>>И что оно даст? Вот что дает то, что ты смог найти?
V>>ShellDll32.dll сегмент .text = 2M V>>Это в твою пользу или мою?
PD>В мою. Это приличная , большая часть всего explorer, со всеми его интерефейсами, коих совсем не мало.
Да что ты? А как же ADVAPI32, BrowseUI, SHDOCVW, IEFRAME и т.д. до бесконечности?
V>>И вообще, вместо приведения примеров бог весть чего, не имеющего отношения ни к чему, просто спросил бы, что у меня там? У меня там пара десятков аудио-фильтров, миксеры, пред/пост обработчики речи, кодеки (как аудио, так и видео), генераторы, детекторы речи, компрессоры/декомпрессоры и т.д.
PD>Приведи размер секции кода твоей DLL, будет ясно.
Здравствуйте, Sheridan, Вы писали:
k>> Вот когда ты сумеешь принести домой этот кинотеатр — тогда вернёмся к этому разговору. S> Зачем?
Затем, что речь шла о домашнем видео.
S>Да почти любой hd-медиаплеер имеет на борту камень с частотой сильно меньше гигагерца.
"Почти любой hd-медиаплеер" имеет на борту аппаратный декодер, мы же говорим о компе с процом общего назначения.
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";
то их склеят. Хотя и неясно, зачем так вещественные числа хранить.
ИМХО никакого склеивания не будет, а будут два четырехбайтника в секции .data со значением 0.99f.
V>Первоначально литерал в программировании — это символьное представление значения, которое преобразуется в само значение компилятором.
Вот тебе два таких символьных представления , которые и будут преобразованы.
>В "жаргонном" и более узком смысле литералом называют константы, требующие память для размещения (наверняка из-за влияния С).
М-да... А не мог бы ты привести пример константы, не требующей памяти для размещения ? Я как-то плохо это себе представляю — константа есть, а памяти ей никак не надо . Только не вздумай мне говорить, что можно ее прямо в коде разместить — на это тоже память нужна.
PD>>Насчет склеивания числовых констант — не слышал. И уж вряд ли линкер (а не компилятор) будет их склеивать из разных статических либ.
V>И будет и склеивает, в том и фишка link-time codegeneration. V>GCC тоже частично это уже умеет, правда пока только для С.
Ты утверждаешь, что их склеят ? То есть в секции .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 ?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, CreatorCray, вы писали:
CC>> Та же гуглопочта — там полно нужных скриптов. Раньше это было просто невозможно, т.к. у юзера это бы дико тормозило.
S>thebat, kmail — про них уже както забыли наверное?
Если честно, с появлением гмыла я с радостью отказался от специальных клиентов для почты. Они — тупо лишнее звено. Были актуальны 10 лет назад только потому, что интернет был хреновый и дорогой, и вообще не всегда был, потому копии писем лучше было хранить локально. Сейчас интернет доступен даже в лесу(с телефона), а уж настольных компов без подключения к сети я уже несколько лет в глаза не видел. Поэтому почтовые клиенты для меня напрочь потеряли смысл.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, sndanil, Вы писали:
S>>Здравствуйте, Torie, Вы писали:
T>>>Попробуем с другой стороны Для каких задач обычного юзера не хватало процессоров 10-летней давности?
S>>Full HD Video? Crysis (и еще целая куча игрушек)?
LS>Какое там Full HD, на 10-летнем проце даже интернет (рендеринг страниц и интерпретация яваскрипта на них) сегодня тормозить будет нещадно.
Не тормозит. РМ 1200 МГц. Вентилятор иногда жужжит, но отрисовка не тормозит.
И вообще, КДЕ показывает что большую часть времени он работает на частоте 300 МГц.
Здравствуйте, alpha21264, Вы писали:
A>Не тормозит. РМ 1200 МГц. Вентилятор иногда жужжит, но отрисовка не тормозит. A>И вообще, КДЕ показывает что большую часть времени он работает на частоте 300 МГц.
У тебя там поди Noscript с AdBlock'ом, которые львиную долю тормозов со страниц вырезают.
Ну и тормоза — дело субъективное, я все же думаю, что на мощном процессоре все это будет работать заметно приятнее. Я вот замечаю, что страницы на нетбуке рисуются тормознее, чем на десктопной машине.
Приветствую, Eugeny__, вы писали:
E> Если честно, с появлением гмыла я с радостью отказался от специальных клиентов для почты. Они — тупо лишнее звено. Были актуальны 10 лет назад только потому, что интернет был хреновый и дорогой, и вообще не всегда был, потому копии писем лучше было хранить локально. Сейчас интернет доступен даже в лесу(с телефона), а уж настольных компов без подключения к сети я уже несколько лет в глаза не видел. Поэтому почтовые клиенты для меня напрочь потеряли смысл.
Здравствуйте, vdimas, Вы писали:
V>Опаньки... Что есть, по-твоему, "аппаратный декодер"?
Аппаратный декодер — это такая микросхемка, которая умеет только одну вещь — декодировать видео. Детали чипа, к примеру, моего плейера ASUS O!PLAY AIR, под NDA, но из общих соображений и некоторого опыта в этой сфере могу предположить, что там много-много потоковых микроядер, выполняющих декодирование с высокой степенью параллелизма. А теперь покажите мне такие микроядра (причём много микроядер!) в CPU и будем считать вопрос закрытым.
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;
}
Интересующее выделил. Без оптимизации там разные адреса.
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 сложновато, они всегда "чистые" константы, со всеми вытекающими, т.е. спокойно склеиваются при оптимизации.
Здравствуйте, koandrew, Вы писали:
K>Аппаратный декодер — это такая микросхемка, которая умеет только одну вещь — декодировать видео. Детали чипа, к примеру, моего плейера ASUS O!PLAY AIR, под NDA, но из общих соображений и некоторого опыта в этой сфере могу предположить, что там много-много потоковых микроядер, выполняющих декодирование с высокой степенью параллелизма.
Какой вид парралелизма?
K>А теперь покажите мне такие микроядра (причём много микроядер!) в CPU и будем считать вопрос закрытым.
Не угадал с ЦПУ. Т.н. "аппаратный декодер" — это DSP + программа к нему во встроенном ПЗУ. Про микроядра не смеши, современные DSP имеют много вычислительных блоков, но они не представляют из себя независимые ядра, т.е. не в состоянии независимо обрабатывать потоки вычисления. Код DSP — это нечто вроде VLIW, т.е. широкая команда, которая за один такт управляет сразу несколькими вычислительными блоками. В общем, все эти аппаратные декодеры чего бы там ни было — это просто некий популярный DSP + вшитая программа к нему.
Поинт в том, что никто в здравом уме не будет реализовывать никакие более-менее сложные алгоритмы в виде TRUE-автоматов, это всегда будет процессор, общего назначения либо сигнальный, и обычная программа к нему. Некоторые т.н. "аппаратные декодеры" даже имеют возможность эту программу перепрошить.
Re[26]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Один ? Один, какой я ни назови, ты опровергать начнешь. Потому что один — действительно не может иметь большого объема кода. А вот все вместе...
Именно что.
V>>.text около 750k.
PD>И сколько времени писал ? Сколько человеко-часов ушло, считая с версии 0.0 ?
