LINUX.ORG.RU

Ларри говорит: «Не отдам спарки!»

 , ,


0

0

Вопреки прогнозам некоторых мировых аналитиков о том, что Oracle продаст железный бизнес Sun на сторону, Ларри Эллисон заявил, что он никому ничего не продаст и все оставит себе. Oracle собирается инвестировать в спарки, и работать вместе с Fujitsu, с которым ранее работал Sun. Он заявил, что разработка и железа, и софта позволяет создавать более совершенные системы (как это делает IBM), чем просто разработка софта, «вот почему телефоны Apple намного лучше, чем телефоны Microsoft».

Покупка компанией Oracle компании Sun (номера 4 на рынке) сделала их номером 2 на рынке хай-энд серверов. «Sun был очень успешен долгое время, продавая системы на базе спарков и соляриса, теперь мы туда добавим ПО Oracle и выведем эти системы на прежний уровень».

Лора ДиДио (аналитик ITIC) отметила, что Sun всегда разрабатывал отличное железо, но был слабоват в маркетинге, а Ларри великолепный маркетолог.

>>> ZDNet

★★★★★

Проверено: anonymous_incognito ()

Ответ на: комментарий от Led

>>- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

> Нет. С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Так вроде разговор был о загрузке данных из памяти (L1 cache). Или я уже сам потерялся ;).

VIT
()
Ответ на: комментарий от Led

> Мне абсолютно не сложно (ок, не очень сложно:) признаться, если я прогнал и был неправ (что я сделал выше). А вам?:)

А ещё сложнее сначала разобраться, а потом писать. В чём, скажем, мне признаваться в прогоне?

VIT
()
Ответ на: комментарий от Led

> Ссылок на учебники под рукой нет, вот что легко нашлось: http://wasm.ru/article.php?article=1010001

AMD64 Architecture
Programmer’s Manual
Volume 1:
Application Programming
стр 49

3.3.5 Load Effective Address
• LEA—Load Effective Address
The LEA instruction calculates and loads the effective address (offset within a given segment) of a
source operand and places it in a general-purpose register.
LEA is related to MOV, which copies data from a memory location to a register, but LEA takes the
address of the source operand, whereas MOV takes the contents of the memory location specified by
the source operand. In the simplest cases, LEA can be replaced with MOV. For example:
lea eax, [ebx]
has the same effect as:
mov eax, ebx
However, LEA allows software to use any valid addressing mode for the source operand. For example:
lea eax, [ebx+edi]
loads the sum of EBX and EDI registers into the EAX register. This could not be accomplished by a
single MOV instruction.

LEA has a limited capability to perform multiplication of operands in general-purpose registers using
scaled-index addressing. For example:
lea eax, [ebx+ebx*8]
loads the value of the EBX register, multiplied by 9, into the EAX register.
------------------------
вот варианта как регистр + регистр + константа - я не нашел
может вам повезет ?
:)

elipse ★★★
()
Ответ на: комментарий от elipse

>вот варианта как регистр + регистр + константа - я не нашел

>может вам повезет ?

Да вот, как бы уже лет двадцать с таким везет:)

Держите строку, полученную из objdump'а:

8d 84 42 1a 00 00 00 lea 0x1a(%edx,%eax,2),%eax

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>В чём, скажем, мне признаваться в прогоне?

А я вам и не предлагал. Это eclipse прогнал (с кем не бывает?), а вы ему поверили (с кем не бывает):)

Led ★★★☆☆
()
Ответ на: комментарий от Led

Прошу прощения, но я пока не вижу его прогона. Я, честно говоря, вообше но вижу смысла в вашей дискусии. Какая разница, кто правильно написал макроинструкцию? И от того, что будет она выполняться 3 такта что изменится?

Я так понимаю, что кто-то изначально привёл пример этой инструкции как "быстрый load из кэш". В конце-концов выяснили, что инструкция не выполняет load, а работает с регистрами. (Ну чтобы она дольше работала, можно было ещё sin какой-нибудь запросить.) Прогнал тот, кто привёл в контексте разговора некорректную инструкцию, демонстрирующую вообще не то, что хотелось. То есть вы, Led.

VIT
()
Ответ на: комментарий от Led

Что именно я прогнал ?
Вы подменяете тему регистров гнилыми частными трюками x86.
И превращаете все в балаган x86 :))
Вообще ,операция сложения в примере частный случай.

elipse ★★★
()
Ответ на: комментарий от elipse

>Вы подменяете тему регистров гнилыми частными трюками x86.

"гнилыми"?

"частными"? да, я привёл пример, любой пример - частный случай:)

>И превращаете все в балаган x86 :))

"балаган"?:)

Мне не нравится архитектура x86. А ещё мне не нравится, когда начинают что бы то ни было хаять, не зная о предмете элементарных вещей из учебника, прикрываясь высокопарными заявлениями о "крутости регистровых окон на спарках":)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>Вообще ,операция сложения в примере частный случай.

Да.

А операция вычитания - это частный случай операции сложения:)

А умножение зачастую можно заменить сдвигом или сдвигом со сложением:)

А сравнение - это частный случай вычитания:)

Что там ещё осталось? Деление? Да здесь воможностей для "манёвра" поменьше:)

Или будем тригонометрию считать на CPU?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Мне не нравится архитектура x86. А ещё мне не нравится, когда >начинают что бы то ни было хаять, не зная о предмете элементарных >вещей из учебника, прикрываясь высокопарными заявлениями о "крутости >регистровых окон на спарках":)

Ага ,ну еще так не изворачивались ...
Крутость регистровых окон легко проверялась на Intel 8051
и Intel 196 KR - это как лет 15 назад еще.
Для обработки прерываний это было идеально и для переключения контекста задач (разумеется ,число задач ограниченно и их не сотни ).

Но ,у Intel все что не x86 дохнет как мухи по непонятным причинам.





elipse ★★★
()
Ответ на: комментарий от Led

>Что там ещё осталось? Деление? Да здесь воможностей для "манёвра" поменьше:)

Ну если , это весь ваш уровень аргументации - вопросов нет тогда.

elipse ★★★
()
Ответ на: комментарий от VIT

>Какая разница, кто правильно написал макроинструкцию?

Это не макроинструкция.

>И от того, что будет она выполняться 3 такта что изменится?

Ну, при 3-х тактах сложнее сказать, что на sparc'ах будет "в 5-6 раз быстрее":)

>Прогнал тот, кто привёл в контексте разговора некорректную инструкцию

Я привёл абсолютно корректную инструкцию

>демонстрирующую вообще не то, что хотелось

Она делает ровно то же, что показывал в своих примерах eclipse: складывает два регистра и константу и результат помещает в третий регистр. Естетсвенно, она не демонстрирует ни "превосходство" x86, ни "превосходство" sparc. Это был стёб, имеющий целью показать, что на таких тупых примерах показывать "превосходство регистроввых окон" над "стековыми операциями" - глупо. А оказалось, что этот стёб выявил (честно, я не хотел:), что критики x86 не знакомы с критикуемым ними объектом даже на уровне "букваря":)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

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

Вот! Я этого уже полсуток жду!:)

Естественно, регистровые окна МОГУТ быть полезны! Но это нишевая полезность и на CPU претендующим на универсальность (без ограничений на количество контекстов) - это в лучшем случае бесполезность, которая только неоправданно усложняет CPU.

Ещё раз: x86 ДАЛЕКО не идеален! Как и SPARC, в том числе из-за атавизмов типа пресловутого "регистрового окна" - ну есть оно, ну и ладно, но какого хрена выдавать его за ГЛАВНЕЙШЕЕ достоинство? Неужели больше нЕчего в ХОРОШИЙ пример привести?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Она делает ровно то же, что показывал в своих примерах eclipse: >складывает два регистра и константу и результат помещает в третий >регистр. Естетсвенно, она не демонстрирует ни "превосходство" x86, ни >"превосходство" sparc. Это был стёб, имеющий целью показать, что на >таких тупых примерах показывать "превосходство регистроввых окон" над >"стековыми операциями" - глупо. А оказалось, что этот стёб выявил >(честно, я не хотел:), что критики x86 не знакомы с критикуемым ними >объектом даже на уровне "букваря":)


Какое радостное щебетание :))
О регистровых окнах c вами и речи еще не было .
Только попробовали смоделировать нехватку регистров и обход через push
и pop - и почалось банальное траханье мозгов .

elipse ★★★
()
Ответ на: комментарий от Led

> Вот! Я этого уже полсуток жду!:)

просто читать тред надо, это уже тут упоминалось

elipse ★★★
()
Ответ на: комментарий от elipse

>Только попробовали смоделировать нехватку регистров и обход через push и pop - и почалось банальное траханье мозгов .

А почему через pushad/popad не попробовали "обход нехватки регистров"?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Естественно, регистровые окна МОГУТ быть полезны! Но это нишевая >полезность и на CPU претендующим на универсальность (без ограничений >на количество контекстов) - это в лучшем случае бесполезность, >которая только неоправданно усложняет CPU.

Бааа , да Вы технолог оказывается еще ? :))

Эти "сложности" есть как стандарт в микроконтроллерах за 1,5$.
А вот кеш ...

>Как и SPARC, в том числе из-за атавизмов типа пресловутого >"регистрового окна"


И где учат этому бреду ?

elipse ★★★
()
Ответ на: комментарий от Led

>>Какая разница, кто правильно написал макроинструкцию? >Это не макроинструкция.

Вы сами доказали, что это макроинструкция с помощью objdump.

>>И от того, что будет она выполняться 3 такта что изменится? >Ну, при 3-х тактах сложнее сказать, что на sparc'ах будет "в 5-6 раз быстрее":)

Я вам несколько раз говорил:"Прежде чем комментировать, читайте контекст". Оценка 5-6 раз относилась к отношению времени обращения в кэш ко времени обращения к регистру. В вашем примере нет обращения к кэш.

По остальному больше не комментирую - у вас какой-то свой странный разговор - люблю одно, не люблю другое. Любить можно женщину. А архитектуру нужно знать. Или не знать.

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

VIT
()
Ответ на: комментарий от Led

> А почему через pushad/popad не попробовали "обход нехватки регистров"?:)

а чем это конкретно лучше push & pop ?

elipse ★★★
()
Ответ на: комментарий от VIT

>Вы сами доказали, что это макроинструкция с помощью objdump.

Это НЕ макроинструкция. objdump выводит в нотации AT&T, а не Intel.

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Это НЕ макроинструкция.

Самому не смешно. У нас разговор постоянно переходит в плоскость "дурак - сам дурак". Если Вас столько раз ловили на неточности и вновь говорят, что что-то не так, так вы, как разумный человек, ну хоть бы взяли и проверили.

Вот Вам ссылка для изучения. Вообще советую внимательно этот документ почитать, а не только страницу 624 (3-576):

http://www.intel.com/Assets/PDF/manual/253666.pdf

где прямо говорится

"Different assemblers may use different algorithms based on the size attribute and symbolic reference of the source operand."

Вообще, если бы я сидел на LOR столько, сколько Вы, я бы пожалуй тоже нихрена ТОЛКОМ не знал. "Меньше сидите в Интернете, читайте больше книг!"

Засим, откланиваюсь. Огромное спасибо всем за приятную беседу!

VIT
()
Ответ на: комментарий от VIT

> Вы сами доказали, что это макроинструкция с помощью objdump.

Тебе уже НЕСКОЛЬКО раз показали, что это не макроинструкция.

Перестань пожалуста бредить, а то получится, что не с кем вообще будет поговорить об архитектуре спарков (что будет грустно).

elispe я уже не беру в расчет, после того, как он обосрался (или обманул) в три раза с SPECint2006/$ на UltraSPARC T2 Plus, и вместо признания своих ошибок (или хотя бы молчания) долго нес маркетоидный бред.

____________________________________________

У тебя есть идеи насчет способа замера время_доступа_к_закэшированной_памяти / время_доступа_к_регистру на тестовой программе на х86?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Led

Led,

мне бы хотелось померять время_доступа_к_закэшированной_памяти / время_доступа_к_регистру на тестовой программе на х86. Думаю, там будет не 5-6/1, и не 1/1.

И еще вариант с popad. И может еще один вариант, который предложите.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> no-dashi, у тебя реально терабайты данных или куча винтов стоит для ускорения доступа?

Данных у меня не терабайты, но вследствие врожденной болезни 32-битныых архитектур, серевер вынужден активно продираться по диску. И да, чередование с зеркалированием по четырем блинам рулит так что пыль столбом стоит.

no-dashi ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>И еще вариант с popad.

Этот вариант имеет смысл только для 32-битного режима. В 64-битном PUSHA*/POPA* упразднены. Хоть и короче инструкция полочается (в байтах), но не даёт "гибкости", да и время выполнения незначительно меньше, чем несколько последовательных PUSH и POP в коде, которые всё равно выполняются параллельно.

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Я привёл абсолютно корректную инструкцию
ага , вот это ?
4. lea a,[a+b+$5]

коректные инструкции для x86 выглядят хотя бы так:

lea a,5[a+b]
в квдратных скобках содержатся ТОЛЬКО индексные регистры
и их не более чем ПАРА для любых режимов.

см.
Intel Architecture Software Developer’s Manual Volume 2:
Instruction Set Reference
2.5. DISPLACEMENT AND IMMEDIATE BYTES




elipse ★★★
()
Ответ на: комментарий от www_linux_org_ru

> elispe я уже не беру в расчет, после того,

я вам буду очень признателен за это :))

> как он обосрался (или обманул)


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

elipse ★★★
()
Ответ на: комментарий от elipse

>lea a,5[a+b]

> в квдратных скобках содержатся ТОЛЬКО индексные регистры

> и их не более чем ПАРА для любых режимов.

Мне искренне жаль вас :(

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Мне искренне жаль вас :(

И мне вас тоже :)) Придется и это пережить ...

elipse ★★★
()
Ответ на: комментарий от ZFSych

> Вы бы сходили, какой-нибудь SPECjbb или SPECjAppServer посмотрели. Более приближенные к жизни спеки все-таки

И кто тебя за язык тянул?

SPECjbb2005, одна и та же операционка, один и тот же производитель железа, одни и те же условия - количество JVM, количество ядер. Даже операционка одинаковая (Solaris):

Sun SPARC T5120 (UltraSPARC T2): SPECjbb bops=170153 => http://www.spec.org/jbb2005/results/res2007q4/jbb2005-20071009-00387.html
Sun Fire X4150 (Xeon X5460): SPECjbb bops=277585 => http://www.spec.org/jbb2005/results/res2008q1/jbb2005-20080208-00451.html

Это даже не смешно.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>> Вы бы сходили, какой-нибудь SPECjbb или SPECjAppServer посмотрели. Более приближенные к жизни спеки все-таки

>И кто тебя за язык тянул?

На брудершафт вроде не пили...

> SPECjbb2005, одна и та же операционка, один и тот же производитель железа, одни и те же условия - количество JVM, количество ядер. Даже операционка одинаковая (Solaris):

> Sun SPARC T5120 (UltraSPARC T2): SPECjbb bops=170153 => http://www.spec.org/jbb2005/results/res2007q4/jbb2005-20071009-00387.html > Sun Fire X4150 (Xeon X5460): SPECjbb bops=277585 => http://www.spec.org/jbb2005/results/res2008q1/jbb2005-20080208-00451.html

> Это даже не смешно.

Смешной вы, ей богу.

Во-первых, мне хотелось донести до вас мысль, что есть более приближенные к жизни бенчмарки, нежели SPECint. Похоже, что получилось.

Во-вторых, не забывайте, что у сравниваемых систем частота процессора отличается более чем в 2 раза; количество процессоров тоже отличается в два раза, и что? Разница в итоговом результате чуть более полутора раз. Результат двухпроцессорного 5240 лучше... А вы все ядра считаете... Вы можете выбрать, сколько ядер использовать в конфигурации - 5 или 13? Нет. Все определяется количеством сокетов для процессоров на системной плате. Вот их и нужно считать. А ядра считать и производительность на ядро - это любимая фишка IBM'а.

А что будет с Интелом, если количество Warehouse'ов довести до 128 как на SPARC'е? Как думаете?

Во-третьих, помимо SPECjbb2005 есть еще и SPECjAppServer. Туда не заглядывали?

И сколько там максимум МБ/с AES128/256 на Интеле можно получить? Ась? На сколько он будет при этом загружен? Сможет ли делать что-то еще?

Так что не так все смешно, как вам кажется. Где-то лучше одни, где-то другие. И это нормально. Просто нужно отдавать себе в этом отчет, а не считать, что Интел заруливает всех всегда и везде на основании превосходства в SPECint2006 и собственного опыта использования для маленьких баз данных, которым даже 32-битного адресного пространства хватает.

ZFSych
()
Ответ на: комментарий от ZFSych

> Не забывайте, что у сравниваемых систем частота процессора отличается более чем в 2 раза

ЕСЛИ ультраспарк Т2 заработает на частоте интела, ТОГДА и приходите с цифрами.

> количество процессоров тоже отличается в два раза, и что?

Вот только спарк восьмиядерник, с 8 тредами на ядро, а два интела четырехядерники. То есть имеется 8 "полноценных" ядер в обеих конфигурациях. Это SMP а не NUMA, для SMP это вполне корректное сравнение.

> А что будет с Интелом, если количество Warehouse'ов довести до 128 как на SPARC'е? Как думаете?

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

Кстати, если ты начал про "а что если" и "а вот тут не так", то можно вспомнить, что в свежих ксеонах вернулся HT в новой реинкарнации, так что перспективы спарков еще более закутываются туманом.

> Во-третьих, помимо SPECjbb2005 есть еще и SPECjAppServer

jAppServer со страшной силой зависит от бакэнда, и для объективного сравнения бакэнд должен быть одним и тем же.

> и собственного опыта использования для маленьких баз данных, которым даже 32-битного адресного пространства хватает.

Понятно. Начался переход на личности, поскольку объективных циферок ты привести не можешь.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> jAppServer со страшной силой зависит от бакэнда, и для объективного сравнения бакэнд должен быть одним и тем же.

Зависит, главным образом если этот бэкенд слаб, чтобы не дать АппСерверу разогнаться до максимальной скорости. Наверно те, кто измеряет АппСервер, об этом догадываются и используют правильный бэкенд.

> Понятно. Начался переход на личности, поскольку объективных циферок ты привести не можешь.

Да какие личности. Даже на ты не переходили, так какие переходы на личности.

Впрочем, признать, что по крипто Интел сливает духу так и не хватило... В объективности вы не заинтересованы. Ладно, смысла тратить на вас время больше нет. Пойду чем-нибудь более полезным для общества позанимаюсь.

ZFSych
()
Ответ на: комментарий от ZFSych

Раз уж тут про СПАРКи говорили вот есть еще такой:

http://gizmodo.com/5253814/fujitsu-venus-claims-worlds-fastest-processor-titl...

http://news.softpedia.com/news/Fujitsu-Working-on-the-Development-of-039-Venu...

Не кислого такого размерчика SPARC получился )) Не для всех правда, но что ж...

ZFSych
()
Ответ на: комментарий от ZFSych

> Впрочем, признать, что по крипто Интел сливает духу так и не хватило...

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

приводил уже. но тут по ссылкам ходить не принято.

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

И да, еще раз повторяю - на брудершафт не пили...

ZFSych
()
Ответ на: комментарий от ZFSych

> одним компилятором - это как? бэкенд-то кодогенерирующий у них по-любому разный будет.

Берется один и тот же компилятор (например gcc, или sun studio) и им собирается один и тот же исходник под обе архитектуры. Потом делается тест и смотрится результат. В крайнем случае, можно собрать один и тот же код разными компиляторами, но тогда это будет не сравнение процессоров, а сравнение компиляторов.

Когда я приводил ссылки на spec.org, я специально из всех тестов подбирал идентичные версии софта, JVM и так далее, хотя мог бы брать куда более эффектные результаты с другими версиями JRE и СУБД.

> насчет одинакового количества потоков - вы потоки сравниваете или все-таки процессоры?

Мне вообще безразлично какой процессор в компе и сколько их. И если одночиповый сервер с ниагарой выполняет 128 заданий в параллели за 9000 секунд, а двухчиповый сервер с интелом делает 16 заданий в параллели за 700 секунд, то если мне надо сделать 256 заданий, на спарке я затрачу 18000 секунд, а на интеле 11200. Вот только производительность на самом деле не единственный фактор, есть еще стоимость, с которой у интела значительно лучше.

И все, спаркам остался крайне специфический и узкий рынок задач, в которых по постановке есть множество одновременно считающихся долго выполняющихся заданий, причем обсчет этих заданий не кластеризуется и не подлежит постановке в очередь. Это не сервера приложений (кластеризуются), не web (кластеризуется), не OLAP (в OLAP возможна постановка заданий в очереди). И что остается? Штучные OLTP, написанные во времена, когда сервер приложений считали интеллигентским бредом, и за рефакторинг которых противно браться, посокльку внутри там г..но вместо структуры данных и кода.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>Берется один и тот же компилятор (например gcc, или sun studio) и им собирается один и тот же исходник под обе архитектуры. Потом делается тест и смотрится результат. В крайнем случае, можно собрать один и тот же код разными компиляторами, но тогда это будет не сравнение процессоров, а сравнение компиляторов.

Ок, так и запишем - результаты SPECint, которые вы тут приводили, сравнивают компиляторы gcc и SunStudio. Вы бы как то уже определились со своей позицией, а то она у вас переменчивая, как девица на выданьи...

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

Странные у вас все-таки представления о задачах, которые с успехом решаются на СПАРКах. Ну да ладно, продолжайте заблуждаться дальше.

> Это не сервера приложений (кластеризуются), не web (кластеризуется),

А мужики то и не знают. Вебсерверы (в особенности с поддержкой SSL) на Ниагарах получаются отличные. Ну да ладно. Продолжайте стоять на своем ))

ZFSych
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.