Здравствуйте, AndrewVK, Вы писали:
AVK>Итак — есть у нас некий сервер. Функционал у него такой — клиент к нему обращается первый раз, модифицирует состояние на сервере, потом еще раз модифицирует. Ну и в итоге через какое то, довольно продолжительное время отключается. Стандартный вобщем то сценарий. Пишем программу — состояние между вызовами храним в памяти, прикручиваем механику управления жизнью сессии (стандартно, по таймауту с последнего обращения). Пусть даже, для контраста, мы написали собственный менеджер состояний, который работает с ними неимоверно быстро, писан на ассемблере, да еще и ввиде драйвера, чтобы не было тормозов на пересечении колец защиты. Запускаем. Работает. AVK>Но клиентов становится больше. Отлично, берем 2килобакса (условно) — докупаем память, ставим два процессора. Эффект есть, работает.
[...skipped...] AVK>А клиентов тем временем ... правильно, становится больше. Ну и что дальше — тратить уже сотни килобаксов на мейнфрейм с продвинутой архитектурой в надежде получить прирост хотя бы на 10%?
[...skipped...] AVK>Это очень характерный пример того как эффективный код при том является плохо масштабируемым.
Мне кажется, что с приведенным вами примером можно поспорить. Увеличение производительности системы путем добавления новых процессоров в SMP систему изначально является тупиковым вариантом, т.к. давно известно, что удобавление новых процессоров не дает линейного роста производительности. А при достижения некоторого их числа производительность практически перестает увеличиваться.
Более перспективный путь -- построение класстера. Т.е. вы, условно, тратите 2килобакса не на дополнительную память, а на еще одну машину. И устанавливаете балансировщик нагрузки, которые разводит клиентов поочередно на каждый из узлов кластера. Когда этого перестает хватать -- покупаете еще один компьютер и т.п. Hewlet-Packard со своим очень дорогим решением NonStop декларирует, что масштабирование прикладной задачи таким образом приводит к линейному росту производительности. По аналогичному пути пошел и Google, только они используют дешевые персоналки массового производства.
Я это к тому, что написанный эффективный код все же может оставаться актуальным, а задача может хорошо масштабироваться.
AVK>Вот такой вот парадокс. То же самое и с GC и JIT. Далеко не факт что узким местом в системе является процессор и вполне возможно что их применение в итоге общую производительность увеличит. А может и уменьшит. Все зависит от задачи.
По поводу GC согласен. Хочу также привести свой пример, когда GC обеспечит выигрыш в производительности. Существует такая стратегия обработки запросов клиентов как process-per-client (или даже process-per-request). Самый простой пример -- CGI на стороне Web-сервера. Но такая стратегия может применяться не только для CGI, но и для Web-сервисов и других задач. Так вот, предположим, что для обработки запроса запускается небольшое С++ приложение, которое активно использует new в начале своей работы, затем использует уже выделеную память, а в конце очищает всю память через delete. А теперь представим, что приложение не делает явных delete в конце. Т.е. вся выделенная процессу память очищается одним большим куском. Что обеспечивает совершено незначительный прирост производительности. Например, приложение работает всего на одну десятую секунды быстрее. Но пусть сервер должен обрабатывает за сутки 100000 запросов. Это означает, что новое приложение будет выигрывать 10000 секунд в день, т.е. более 2 часов (это конечно не так однозначно, т.к. в большинстве случаев запросы клиентов обрабатываются параллельно, но выигрыш все равно будет ощутимым).
По поводу JIT мне недавно попалась статья, где пытались оценить, как JIT увеличивает производительность Java-вского Swing-приложения. Оказалось, что никак. И дело было в том, что при использовании Swing цепочки вызовов были такими длинными, а дерево возможных переходов таким развесистым, что JIT просто был не в состоянии собрать необходимой статистики для выбора участков кода для компиляции.
Но, может быть, со временем ситуация с JIT улучшится.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Более перспективный путь -- построение класстера. Т.е. вы, условно, тратите 2килобакса не на дополнительную память, а на еще одну машину. И устанавливаете балансировщик нагрузки, которые разводит клиентов поочередно на каждый из узлов кластера.
У класетра есть свои узкие места. В частности у него медленное межузловое взаимодействие с крайне высокой латентностью (особенно у дешевых кластеров на gigabit ethernet). Поэтому задачи, требующие интенсивного обмена данными между узлами на кластере работают очень плохо, хуже даже нежели на SMP. Гибридные решения вроде NUMA или сановских коммутаторов отчасти спасают, но лишь отчасти и очень задорого.
E> Когда этого перестает хватать -- покупаете еще один компьютер и т.п. Hewlet-Packard со своим очень дорогим решением NonStop декларирует, что масштабирование прикладной задачи таким образом приводит к линейному росту производительности.
Для любой задачи? Не смешите мои тапочки.
E>Я это к тому, что написанный эффективный код все же может оставаться актуальным,
Не может. Для кластеров требуются специализированные решения со специализированной архитектурой (если конечно речь не идет о вычислительных задачах).
E>По поводу JIT мне недавно попалась статья, где пытались оценить, как JIT увеличивает производительность Java-вского Swing-приложения. Оказалось, что никак. И дело было в том, что при использовании Swing цепочки вызовов были такими длинными, а дерево возможных переходов таким развесистым, что JIT просто был не в состоянии собрать необходимой статистики для выбора участков кода для компиляции.
Здравствуйте, AndrewVK, Вы писали:
AVK>У класетра есть свои узкие места. В частности у него медленное межузловое взаимодействие с крайне высокой латентностью (особенно у дешевых кластеров на gigabit ethernet). Поэтому задачи, требующие интенсивного обмена данными между узлами на кластере работают очень плохо, хуже даже нежели на SMP. Гибридные решения вроде NUMA или сановских коммутаторов отчасти спасают, но лишь отчасти и очень задорого.
Если интенсивного обмена, то да.
А если у кластера есть один front-end, который выполняет роль балансировщика нагрузки, а за ним стоят узлы, которые обрабатывают перенаправленные на них запросы самостоятельно, без обмена с другими узлами, то не так уж все и плохо.
E>> Когда этого перестает хватать -- покупаете еще один компьютер и т.п. Hewlet-Packard со своим очень дорогим решением NonStop декларирует, что масштабирование прикладной задачи таким образом приводит к линейному росту производительности.
AVK>Для любой задачи? Не смешите мои тапочки.
Нет, про любые задачи я не говорил. NonStop -- это система адаптированная для on-line обработки транзакций. Например, когда обработку сотен тысяч on-line запросов клиентов можно развести на 100 машин и достичь действительно линейного роста производительности всей системы.
Просто я подумал, что приведенный вами пример как раз подходит под категорию on-line транзакций.
E>>Я это к тому, что написанный эффективный код все же может оставаться актуальным,
AVK>Не может. Для кластеров требуются специализированные решения со специализированной архитектурой (если конечно речь не идет о вычислительных задачах).
Не согласен с такой категоричностью. Если речь идет о вычислительных задачах, типа сложных и больших научных расчетов, то вы правы. Но если речь идет о web-сервере, который через cgi-генерирует контент для клиентов, или о web-сервисе, который через cgi обрабатывает SOAP-запросы, то прикладной код cgi для адаптации к кластеру может не потребовать никаких модификаций. Потребуется только web-сервер, который умеет балансировать нагрузку на рабочие узлы кластера.
AVK>Это уже не JIT, это Hotspot.
Боюсь, что для меня, замшелого C++ программиста, такие тонкости уже не различимы.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если интенсивного обмена, то да. E>А если у кластера есть один front-end, который выполняет роль балансировщика нагрузки, а за ним стоят узлы, которые обрабатывают перенаправленные на них запросы самостоятельно, без обмена с другими узлами, то не так уж все и плохо.
Если задача идеально параллелится, то да, кластер подходит. Но есть тут одна засада — такие задачи нечасто встречаются. Чаще же, даже если собственно алгоритмы параллелятся, все равно все в итоге стекается в единую БД и в нее же упирается. А вот для распараллеливания БД на кластеры приходится придумывать весьма хитрые схемы. Впрочем это уже совсем дургой разговор.
AVK>>Для любой задачи? Не смешите мои тапочки. E>Нет, про любые задачи я не говорил. NonStop -- это система адаптированная для on-line обработки транзакций.
А транзакции где? Не в БД ли? Тогда см. выше .
E> Например, когда обработку сотен тысяч on-line запросов клиентов можно развести на 100 машин и достичь действительно линейного роста производительности всей системы.
Если источник данных редко модифицируется и on-line актуальность не требуется, тогда можно достичь не линейной конечно масштабируемости, но очень высокой, путем ленивой репликации этого самого источника данных по узлам кластера. А вот если источник подвержен частым и сильным изменениям, то малой кровью уже не обойтись.
E>Просто я подумал, что приведенный вами пример как раз подходит под категорию on-line транзакций.
Приведенный мной пример вобще не подходит ни под какую категорию, поскольку в нем не указано ничего, что бы могло помочь предположить о его распараллеливаемости. И не указано по одной простой причине — пример не иллюстрировал возможность разведения приложения по кластеру, там о другом была речь.
AVK>>Не может. Для кластеров требуются специализированные решения со специализированной архитектурой (если конечно речь не идет о вычислительных задачах).
E>Не согласен с такой категоричностью. Если речь идет о вычислительных задачах, типа сложных и больших научных расчетов, то вы правы.
Пальцем в небо. Как раз такие задачи очень часто распарралеливаются идеально и считаются большей частью на кластерах. В ту же кассу задачи рендеринга.
E> Но если речь идет о web-сервере, который через cgi-генерирует контент для клиентов, или о web-сервисе, который через cgi обрабатывает SOAP-запросы, то прикладной код cgi для адаптации к кластеру может не потребовать никаких модификаций. Потребуется только web-сервер, который умеет балансировать нагрузку на рабочие узлы кластера.
Если речь только о том чтобы показать html-страничку то да, только на таких задачах обычно особой проблемы с производительностью нет. Вот только чаще всего эти странички связаны с БД, о чем смотри выше
AVK>>Это уже не JIT, это Hotspot.
E>Боюсь, что для меня, замшелого C++ программиста, такие тонкости уже не различимы.
Какая уж тут тонкость. Hotspot тем и отличается от JIT, что принимает решение о компиляции, либо интерпретации кода. А в дотнете, к примеру, промежуточный код компилируется всегда.
Здравствуйте, AndrewVK, Вы писали:
AVK>Если задача идеально параллелится, то да, кластер подходит. Но есть тут одна засада — такие задачи нечасто встречаются.
Ну, это сильно зависит от предметной области. Например, в web-приложениях такое сплошь и рядом
E>>Просто я подумал, что приведенный вами пример как раз подходит под категорию on-line транзакций.
AVK>Приведенный мной пример вобще не подходит ни под какую категорию, поскольку в нем не указано ничего, что бы могло помочь предположить о его распараллеливаемости. И не указано по одной простой причине — пример не иллюстрировал возможность разведения приложения по кластеру, там о другом была речь.
Ну как же не подходит , вот же:
Итак — есть у нас некий сервер. Функционал у него такой — клиент к нему обращается первый раз, модифицирует состояние на сервере, потом еще раз модифицирует. Ну и в итоге через какое то, довольно продолжительное время отключается.
Ну прям как обычный web-сервер описывается . Например, для обслуживания халявных почтовых ящиков. Или поисковик. А такие задачи хорошо решаются с помошью кластеров, google это доказал.
AVK>Пальцем в небо. Как раз такие задачи очень часто распарралеливаются идеально и считаются большей частью на кластерах. В ту же кассу задачи рендеринга.
А если добавить сюда еще и необходимость расчетов в реальном времени (как в радиолокации, например) то получится, что и кластер должен наполовину состоять из спецвычислителей, и для коммуникации специальные каналы связи должны использоваться.
Хотя мы уже в какие-то дебри стали углубляться. Тех же кластерных решений сейчас уйма и под разные задачи ориентированы. И востребованы.
E>> Но если речь идет о web-сервере, который через cgi-генерирует контент для клиентов, или о web-сервисе, который через cgi обрабатывает SOAP-запросы, то прикладной код cgi для адаптации к кластеру может не потребовать никаких модификаций. Потребуется только web-сервер, который умеет балансировать нагрузку на рабочие узлы кластера.
AVK>Если речь только о том чтобы показать html-страничку то да, только на таких задачах обычно особой проблемы с производительностью нет. Вот только чаще всего эти странички связаны с БД, о чем смотри выше
Как раз такие проблемы при росте числа клиентов быстро появляются. Особенно если речь идет о web-сервисах, которые какие-то услуги предоставляют, а не простой html отдают. И для соединений SSL используется. Если приходится по тысяче запросов в секунду обрабатывать, то здесь даже парсинг/генерация XML-я в SOAP-е сказываться начинает. И доступ к БД здесь может быть не так критичен. Особенно, если делать запросы в разные БД: в одну для получения статуса и провайла клиента, в другую для выполнения запроса, в третью для логирования операции. Но это уже опять совсем другая история.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Если задача идеально параллелится, то да, кластер подходит. Но есть тут одна засада — такие задачи нечасто встречаются.
E>Ну, это сильно зависит от предметной области. Например, в web-приложениях такое сплошь и рядом
Не сплошь и не рядом. Те веб-приложения, которые требуют кластера, как правило под собой имеют БД. О которой я уже писал, но ты все поскипал.
E>Ну как же не подходит , вот же: E>
E>Итак — есть у нас некий сервер. Функционал у него такой — клиент к нему обращается первый раз, модифицирует состояние на сервере, потом еще раз модифицирует. Ну и в итоге через какое то, довольно продолжительное время отключается.
E>Ну прям как обычный web-сервер описывается .
Я вобще то имел ввиду не веб-приложение, а классический сервер бизнес-логики. И сценарий этот описывает практически любое клиент-серверное приложение с сессией.
E> Например, для обслуживания халявных почтовых ящиков. Или поисковик. А такие задачи хорошо решаются с помошью кластеров, google это доказал.
У google как раз тот самый случай, когда имеется редко меняющееся хранилище, которое легко реплицировать на узлы кластера. Кроме того google специально под кластер затачивался.
AVK>>Если речь только о том чтобы показать html-страничку то да, только на таких задачах обычно особой проблемы с производительностью нет. Вот только чаще всего эти странички связаны с БД, о чем смотри выше
E>Как раз такие проблемы при росте числа клиентов быстро появляются.
У тебя живой пример перед глазами — rsdn. Нагрузки, создаваемые asp.net приложениями просто таки ничто по сравнению с нагрузками, создаваемыми сиквелом. Так что если все сделать по примитивной схеме, без переписывания кода, раскидывание его по кластерам с LB ничего не даст.
E> Особенно если речь идет о web-сервисах, которые какие-то услуги предоставляют,
И веб сервисы тоже у нас есть. И там картина еще более разительная — все ресурсы жрет сиквел.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Если задача идеально параллелится, то да, кластер подходит. Но есть тут одна засада — такие задачи нечасто встречаются.
E>>Ну, это сильно зависит от предметной области. Например, в web-приложениях такое сплошь и рядом
AVK>Не сплошь и не рядом. Те веб-приложения, которые требуют кластера, как правило под собой имеют БД. О которой я уже писал, но ты все поскипал.
Поскипал, потому, что по поводу БД согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
[]
MS>В те времена профессия Ситемный Программист — было неимоверно круто. Инсталляция операционной системы ОС-ЕС (на самом деле IBM OS/360) занимала пару недель (!) напряженной работы
Зачем так молодежь то пугать? От силы сутки, и то, если надо было что-то нетрадиционное ваять — типа режима RT (Real Time) в MVT6. А так, перегенерация системы по готовому плану + довключение новых фичей, а его после генерации ни кто не убивал, занимал часы.
Мемуары мои вызывали определенный интерес, судя по оценкам. Решил написать еще немного.
Речь пойдет о моих мытарствах в освоении вывода текста на русском языке...
Когда я только начинал свой путь в программировании, никакой проблемы русского языка не было вообще. Потому что и проблемы языка тоже не было. М-220 успешно печатала нормализованные десятичные числа, и этого считалось вполне достаточным. Что же касается текстов, хоть английских, хоть русских, то те, кто умел заставить ее хоть что-то напечатать, считались гуру непревзойденного уровня, и мне до них было очень далеко.
Так что вопрос кодировки не стоял перед нами вообще. И о том, что один символ — это один байт, мы тоже не знали, так как и байтов тоже никаких еще не было. Были 45-разрядные ячейки (слово "бит" точно существовало, но говорили "разряд" — не иначе как тяжелые последствия борьбы с низкопоклонством перед Западом . Сколько символов в этой ячейке хранилось и как они там кодировались — я и до сих пор не знаю.
Зато другое знать обязаны были все. Необходимо было уметь читать перфокарты. О, это было не такое простое искусство. Во-первых, на 80-колоночной перфокарте почему-то использовались только 45 колонок. Во-вторых, набивка была не поколоночная, а построчная, по 7 бит ("разрядов" на символ.
45 на 7 как-то не очень хорошо делится, как легко заметить. И действительно, на перфокарте некоторые столбцы никогда не пробивались. Разобраться в таких условиях, где один символ заканчивается, а другой начинается — так просто не получится. Нужна полностью пробитая перфокарта ("читалка") . Эта читалка разграфлялась шариковой авторучкой вертикальными линиями , а потом столбцы, принадлежащие данному символу, закрашивались тушью или акварелью. Наложишь ее на свою перфокарту, посмотришь на просвет, свернешь в уме двоичное число в восьмеричное — и все дела!
Кстати, коль уж о перфокартах речь зашла, не могу не рассказать и о том, как я впервые ее исправлял. В общем, один из символов был не тот, что нужно. Новые дырки прорезались без труда с помощью бритвенного лезвия, а как быть с ненужными дырками ? Спросил кого-то, говорят — заклей. Я собрался было клей искать и думать, как ее правильно заклеивать, но все оказалось намного проще. Просто надо было кусочек конфетти вставить в дырку и слегка пригладить. Хотите верьте, хотите — нет, а держалось как влитое! Правда, все же мы обычно после таких действий перфокарту все же дублировали. Устройство для дублирования носило неофициальное название "крокодил" и шум от него был очень хороший.
В общем, освоил я это чтение по дырочкам, а тут и пора пришла машину менять. Перешел я на БЭСМ-6. Тут уже символы набивались поколонно, при этом использовались все 80 колонок и читалки исчезли из употребления. Правда, строк на перфокарте было 12, так что тогдашний байт содержал 12 битов . Это, впрочем, нас мало волновало, так как байтов на этой машине все равно не было.
Но я отвлекся. Я ведь обещал про русский язык написать. На БЭСМ-6 с ним проблем никаких не было. Просто на перфокарте пробивались дырочки, а поскольку их было максимум 12, то хватило бы места и для грузинского с армянским, если бы понадобилось . Так что нас ничего не беспокоило, и о том, что 1 символ == 1 байт, мы по-прежнему не знали.
Пришла, наконец, пора, познакомиться с байтами. Впервые о их существовании я узнал, когда перешел на ЕС ЭВМ. Вот тут уж байты были, и символы занимали ровно один байт. Хотя 12-битные байты перфокарт никуда не делись, пришлось все же познакомиться и с хранением символов в ОП.
Так я впервые узнал о кодировке. Называлась она EBCDIC, в отечественном варианте ДКОИ-8 в нее добавили русские буквы. Тому, кто их туда добавил, надо бы при жизни памятник поставить, настолько простое и элегантное решение он нашел. Тем русским буквам, которые не имеют аналогичных по начертанию латинских (Б,Ц,И...) были присвоены свои коды. Что же касается тех букв, у которых есть аналогичная по начертанию латинская (А,М,Р) — решили просто — и так сойдет, зачем еще какие-то коды им добавлять ? Таким образом, были буквы русские, латинские и русско-латинские — универсальные, так сказать . Хочешь — думай. что это русская "В" (ве), а хочешь — что латинская "B" (бэ).
Как в таких условиях люди писали программы обработки текста — для меня до стх пор загадка. Я их не писал, а занимался расчетами, поэтому максимум, что мне требовалось — уметь выводить на печать текстовые строки. Это труда не составляло, а посему ДКОИ-8 никаких возражений у меня не вызывала.
Пришла пора пересесть на СМ ЭВМ. Здесь, слава богу, ДКОИ-8 не было. Здесь я познакомился с КОИ-7, и нельзя сказать, что это знакомство не оказало влияния на мою психику .
Но по порядку. На СМ-4 работала операционная система ОС РВ, урожденная RSX-11. В ходе ее преобразования в ОС РВ ASCII-7 был заменен на КОИ-7, и вот как это было сделано.
Понятно, что в 7 бит (кто и зачем это придумал — до сих пор не знаю) уложить можно либо англиский строчный и заглавный, либо английский и русский, но только одного регистра. В RSX-11 были английские буквы обоих регистров — о локалах тогда и речи не было. При переделке ее в ОС РВ латинские строчные буквы переделали в русские заглавные, упорядочив их, естественно, по латинскому алфавиту (АБЦДЕ...) и добавив лишние буквы в конце. Проще говоря, на экране дисплея символ с соответствующим кодом изображался как русское "Б", а не латинское "b". Изображения символов в те времена вшивались в дисплей намертво, аппаратно, об их изменении и речи не могло быть.
Прекрасно все работало! Просто замечательно! И русский язык, и английский — в полном порядке. Один регистр, правда, ну да ладно, нечего с жиру беситься. Скажи спасибо, что хоть перфокарт здесь нет и можно читалки не пробивать!
В общем, все было прекрасно, пока однажды не понадобилось мне загрузить вместо ОС РВ оригинальную RSX-11. Загрузил, и тут же увидел на своем дисплее странное сообщение
ФИЛЕ НОТ ФОУНД
RSX-11 просто решила вывести это сообщение строчными буквами. Не знаю, почему, видимо, ей так лучше показалось. Но советский дисплей вместо презренных латинских строчных букв вывел добротные русские заглавные, вот и все!
Разобравшись с этим ФИЛЕ и малость попривыкнув к нему, я уже совершенно спокойно воспринял следующее сообщение
ДЕЖИЦЕ НОТ РЕАДЫ
и тут же вызвал инженера, который этот ДЕЖИЦЕ и начал чинить.
Пришла пора IBM PC. Не все, наверное , знают, что на заре его существования (случайно совпавшим с концом советской власти у нас пытались делать его клоны — ЕС-1840, 1841, Искра-1030. Лучше, конечно, их бы не делали вообще, но к счастью, это не долго продолжалось. Все же десяток Искр-1030 попал в наш университет, и мне пришлось с одной из них иметь дело. Здесь с русским языком дело обстояло еще интереснее.
КОИ-7 (а также КОИ-8, с которым я имел дело на Ямахе) имел русские буквы, упорядоченные по латинскому алфавиту. Писать программы текстовой обработки при таких условиях, сами понимаете, радость небольшая, и вот на Искре-1030 решено было этому положить конец!
Какие-то деятели разработали кодировку, в которой все было замечательно. Все 32 русские заглавные и 32 строчные буквы в ней были, упорядочены они были по русскому алфафвиту, без дырок, и за буквой 'Я' сразу следовало 'a'. В общем, жить бы и радоваться. По-видимому, от радости они свою кодировку даже оформили как ГОСТ, а в те времена с ГОСТами не шутили. Не уверен, что этот ГОСТ отменен, так что, возможно, мы и сейчас все его нарушаем.
Все было хорошо, одно только маленькое "но" было. Чтобы впихнуть эти 64 символа, да еще подряд, авторы кодировки ГОСТ затронули область, принадлежащую символам псевдографики. После того, как на этой Искре-1030 я первым делом стер русскую пародию на MS-DOS, поставил нормальную MS-DOS 3.3 и запустил Нортон Командер (предшественник FAR'а), он немедленно изобразил мне свои панели с рамочкой из букв "щ" или "ы", не помню уж точно. Впрочем, в углах этой рамочки были, естественно, другие буквы. Зрелище не для слабонервных, я вам скажу. А программ без псевдографики тогда практически не было, надо же как-то оформлять экран. В общем, кодировка ГОСТ быстро канула в небытие.
Остальное большинству известно. На смену пришла 866 кодировка (кстати, ее называли альтернативной — кодировке ГОСТ, естественно). И лишь с появлением Windows и кодировки 1251 стало возможным как-то перевести дух. Впрочем, как сказать. Помню, как я пытался строчную букву "я" запихнуть в меню в программе для Windows 3.1. Что ни делал — general protection fault (по-нынешнему — access violation). Причина простая — ее код 255 . Так и не смог ее туда вставить, пока на Windows 95 не перешел.
А потом... Потом появился Интернет, и, казалось бы, давно ушедшая КОИ-8 вернулась обратно со всеми своими проблемами. А потом появился Юникод. Впрочем, это всем и так хорошо известно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мемуары мои вызывали определенный интерес, судя по оценкам. Решил написать еще немного.
PD>Речь пойдет о моих мытарствах в освоении вывода текста на русском языке...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Остальное большинству известно. На смену пришла 866 кодировка (кстати, ее называли альтернативной — кодировке ГОСТ, естественно). И лишь с появлением Windows и кодировки 1251 стало возможным как-то перевести дух. Впрочем, как сказать. Помню, как я пытался строчную букву "я" запихнуть в меню в программе для Windows 3.1. Что ни делал — general protection fault (по-нынешнему — access violation). Причина простая — ее код 255 . Так и не смог ее туда вставить, пока на Windows 95 не перешел.
Кстати, буржуйская программа Neverwinter Nights от вида русской буквы "я" падает до сих пор...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Помню, как я пытался строчную букву "я" запихнуть в меню в программе для Windows 3.1. Что ни делал — general protection fault (по-нынешнему — access violation). Причина простая — ее код 255 .
А я "победил" — ее нужно было восьмеричным кодом задавать. Для ресурсов это по крайней мере работало (проверял на MS и Борланде).
[ posted via RSDN@Home 1.1.4 beta 7 r501, accompanied by Metallica — Hero Of The Day ]
PD>Пришла пора IBM PC. Не все, наверное , знают, что на заре его существования (случайно совпавшим с концом советской власти у нас пытались делать его клоны — ЕС-1840, 1841, Искра-1030. Лучше, конечно, их бы не делали вообще...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А потом... Потом появился Интернет, и, казалось бы, давно ушедшая КОИ-8 вернулась обратно со всеми своими проблемами. А потом появился Юникод. Впрочем, это всем и так хорошо известно.
Прокомментирую спустя полгода
Учитывая, что кроме русского и английского языка есть ещё куча других и с разными подвариантами и т.д. и т.п. алфавитный порядок в таблице шрифтов, вообще говоря, совершенно лишняя сущность, даже вредная, провоцирующая к нправильному стилю написания программ. Насколько мне известно, правильно держать специальную таблицу для алфавитной сортировки на каждую локаль, потому что более, в сущности, ни для чего алфавитный порядок не нужен. Это я к вопросу о проблемах КОИ-8.
I>Прокомментирую спустя полгода
I>Учитывая, что кроме русского и английского языка есть ещё куча других и с разными подвариантами и т.д. и т.п. алфавитный порядок в таблице шрифтов, вообще говоря, совершенно лишняя сущность, даже вредная, провоцирующая к нправильному стилю написания программ. Насколько мне известно, правильно держать специальную таблицу для алфавитной сортировки на каждую локаль, потому что более, в сущности, ни для чего алфавитный порядок не нужен. Это я к вопросу о проблемах КОИ-8.
Отвечу на комментарий
При таком подходе сравнение символов (и строк, следовательно) вместо
a < b
превращается в
table[a] < table[b]
что означает лишние обращения к памяти (пусть даже кеш). Учитывая то, что эта операция стоит внутри вложенных циклов, такое изменение не есть хорошее дело.
bool b; // вынес сюда, чтобы оптимизатор не выкинул код
int main(int argc, char* argv[])
{
char* p1 = "abcde";
char* p2 = "abcde";
int i, j;
DWORD dwTime1 = GetTickCount();
for ( i = 0; i < 100000000; i++)
for ( j = 0; j < 5; j++)
b = p1[j] == p2[j]; // специально сравниваю посимвольно
DWORD dwTime2 = GetTickCount();
printf("%d\n",dwTime2 - dwTime1);
return 0;
}
Время в релизе — 922 мсек.
А теперь так
char* p1 = "abcde";
char* p2 = "abcde";
char pos[256];
pos['a'] = 0;
pos['b']= 1;
pos['c']= 2;
pos['d']= 3;
pos['e']= 4;
int i, j;
DWORD dwTime1 = GetTickCount();
for ( i = 0; i < 100000000; i++)
for ( j = 0; j < 5; j++)
b = pos[p1[j]] == pos[p2[j]];
DWORD dwTime2 = GetTickCount();
printf("%d\n",dwTime2 - dwTime1);
return 0;
и имеем 2594 мсек, т.е почти трехкратное замедление.
.
От силы сутки, и то, если надо было что-то нетрадиционное ваять — типа режима RT (Real Time) в MVT6. А так, перегенерация системы по готовому плану + довключение новых фичей, а его после генерации ни кто не убивал, занимал часы.
на символ.
