"Компьютер без COBOL'a и Fortran'a похож на
шоколадное пирожное без кетчупа и горчицы"
N210

В этой статье я хочу разобраться с ситуацией на рынке процессоров AMD. От начала до конца. Только процессоров. Что было и что есть. А то я уже стал путаться, где какой сокет, где какой кэш, где уже Thunderbird, а где еще Argon, а где, вообще, Spitfire.

Начну с того момента, когда конкурентом Intel'овских Pentium были AMD K6-2 и K6-III. Кратко данные продублированы в таблице ниже, а подробнее - эти процессоры предназначены для МП под Socket7 и Super7 (Super7 - это тот же Socket7, только для работы с частотой системной шины 100МГц). У K6-III имеется кэш второго уровня, встроенный в ядро и работающий на частоте процессора, а тот что оставался на плате, превращался в кэш третьего уровня (конечно, добавляя свою толику производительности).

Т.е. для Socket7 плат - это вроде как единственный процессор, обладающий своим кэшем второго уровня. С того момента, как Intel начал выпускать PentiumII (Celeron появились позже) в форм-факторе Slot-1, AMD отошел от совместимости по разъему (автоматом и по совместимости по материнским платам). Кроме того, AMD еще и шину ввел EV-6 (Alpha 21264), которая обладает большой пропускной способностью по сравнению с существующими для архитектуры для чипсетов под Intel процессора. Ладно, на шинах останавливаться не будем, тем более, что это хорошо описано на "иХбинБТ" вот здесь.

Новый процессор, который логично изначально называли K7 у AMD принял название Athlon, ну и как водится, собственное кодовое название ядра - Argon. Вместе с микросхемами кэша, Athlon монтировался на плату, все это запаковывалось в коробочку и вставлялось в Slot A. Очень схоже с PentiumII Slot-1. Кэш у Athlon мог быть и 512кб, но вот работал на частоте меньшей, чем частота процессора (максимум - 2/3). Ну, трудно найти микросхемы кэша, которые бы стабильно работали на частоте 350МГц, да и с такими частотами надо уже считаться - даже малые расстояния между чипами начинают играть роль. Athlon на частоте 700МГц уже имел только половинную частоту кэша L2, а с повышением частоты процессора (800, 900 и 1000МГц) - просто изменялся делитель. В общем, 350МГц - это максимум. (зато K7 очень хорошо разгоняются).

Поэтому, логичным было предположить, что кэш опять встроят в ядро - как это было с K6-III и как сейчас есть у Celeron, PIII и у P4. Так и сделали. Обозвали форм-фактор Socket-A, кодовое название ядра - ThunderBird, а более дешевый вариант - где кэша чуть поменьше - SpitFire. Для Thunderbird оставили название Athlon, а вот для Spitfire придумали имя - Duron. Выпускаются они сейча по технологии 0.18мкм. А отказ от платы и картриджа позволяет удешевить производство. И охлаждение можно приделать получше. И самое главное, еще раз повторю, работа кэша второго уровня у Thunderbird и Duron теперь происходит на частоте процессора.

Наверное, стоит считать отклонение на всякие Slot-1 и Slot-A у обоих процессорных гигантов некоторым экспериментом.
Кстати, на сей день Athlon выпускается и в Slot-A, пока еще не произошел полный переход на Socket-A, так что, существуют и слотовые варианты для Thunderbird.

Далее. Чипсеты:
Для Slot-A самый расхожие чипсеты - это AMD750 и KX-133.

А одним из первых Socket-A чипсетов был KТ-133 (VIA Apollo), который был выпущен как раз для Socket-A процессоров, но он не поддерживал работу с системной шиной 266МГц (на самом деле частота 133МГц, но передача данных идет по обоим фронтам сигнала, так что, получается, как бы 266МГц). Чипсет KT-133A уже лишен этого недостатка.

На настоящий момент, чипсет, поддерживающий DDR SDRAM (double data rate) выпущен самой AMD, называется AMD-760. VIA тоже выпустила такой чипсет с поддержкой DDR SDRAM - называется Apollo KX266. И процессоры Thunderbird сильно полюбят этот чипсет. Ну, и покупатели, разумеется, тоже :)

Ниже я подготовил табличку, где постарался свести все основные типы процессоров AMD по настоящее время (разделенные по кодовым названиям ядер начиная с AMD K7).

AMD-K6-2 до 550МГц		Super7совместим с Intel Socket7 процессорами. (L2 кэша нет - он на плате :).
AMD-K6-III, 350-475МГц		256kb L2 кэша на чипе на частоте проццесора. Кэш на плате получается, уже как L3 (100МГц). Super7совместим с Intel Socket7 процессорами
AMD K7, Athlon (Argon) 500МГц - 1000МГц		чипсет AMD750, KX133, Slot-A
AMD Athlon 700МГц - 1.2ГГц (ThunderBird), 256-512кб - кэш L2, 128 - кэш L1.		чипсеты KT-133, KT-133A, AMD760 - поддержка Double Data Rate (DDR), Socket-A
AMD Duron 600МГц (SpitFire) 700-800МГц, 192kb - общий кэш

консультировал Andy

[an error occurred while processing this directive]

Очень мне понравился охладитель (кулер, то бишь) от японской фирмы KENDON.

На самом сайте Kendon'a все только на японском, поэтому что-то вычитать очень трудно. Но судя по внешнему виду и схемам установки, можно с большой достоверностью утверждать, что во-первых, используется элемент Пельтье, во-второх, для пущего охлаждения, как и в обычном автомобильном радиаторе, используется жидкость - вода, например. И вентилятор, разумеется, необходим, как всегда. Из рисунков видно, что трубочки с жидкостью составляют замкнутый резервуар и никаких компрессоров не подразумевается. Т.е. - самотоком. Для настоящего оверклокера.
Кстати, что происходит у оверклокера без чувства меры - картинка в конце выпуска :)

ссылку прислал S. Antropov

Tanzwut "Tanzwut" (3.0Mb, 3.52 min) 128kbps, 16bit, stereo, 44.1kHz, Liquid Audio From album "Labirinth der Sinne" (2000)

Стиль - Folk+Industrial (Metal).

Только для любителей игры "Heroes of Might & Magic": на сервере fcenter.ru выложена 24-я часть повествования "Как я стал полководцем Эрафии". Напомню, что это - художественное описание тактики игры HMM3.

На известном сайте "PalmQ online" появилась интересная страничка, рассказывающая о недокументированных возможностях PDA различных моделей - TRGPro, Visor, Palm различных модификаций. Как то: отладочный режим, Backdoors, альтернативная перезагрузка и огромная куча "пасхальных яиц".
А вообще, в Интернете есть место, посвященное только "пасхальным яйцам" для Palm - Palmlife (самая крупная коллекция).

Недавно один из читателей в письме выдал:
"...Знаю, что компилятор для перла есть под Win32, а под Linux?"

Наводит на размышления... ;)

Хочу поместить достаточно интересную статью, которую я попросил написать Максима Пензина (г.Иркутск) специально для моего журнала. Потом я ее немного подправил и причесал.
Я думаю, стоит разобрать, как видится целеполагание для всяких FastCGI, Zope и пр. примочек к программированию для Web - проще говоря, а зачем их придумали?

"Задачи динамической обработки гипертекстовых документов"

Разбираясь с программированием веб серверов, с многочисленными скриптами и HTML'ями полезно немного вспомнить историю этого дела.

Вообще, сам по себе WorldWideWeb зародился сравнительно недавно, но, несмотря на это, сама технология довольно сильно изменилась с самого начала. Как таковой, HTML появился в научной среде, и являл собой достаточно простой способ представления текстовых документов без особых излишеств и ссылок между ними - так называемый гипертекст. Интересно, что способ доступа к этим документам (Hyper Text Transfer Protocol) отличался от общепринятого, например от telnet или ftp, отсутствием понятия сессии или постоянного соединения, то есть клиент просто говорил серверу "а подать мне вон тот документик", назывался URL (Unuiversal Resource Locator), на что сервер вываливал соответствующий файл и тут же закрывал соединение и забывал о запросе. В обязанности клиента входило отобразить материал, разобраться где гиперлинки, а где картинки. И если начитавшемуся пользователю хотелось еще текстов и зрелищ, то клиент формировал следующий запрос по выбранной ссылке.

Это все просто, красиво, легко реализуется, быстро работает, но... как водится, неугомонным программистам, да и простым пользователям, захотелось новых возможностей. В результате чего эти возможности и были реализованы. Но так как изначально это не было заложено в концепцию, всякте фенечки прикрутили сбоку на скорую руку. Просто сказали, что вот по такому-то запросу сервер будет отдавать не просто обычный файл, а запустит сначала программку и выдаст результат ее работы, т.е. попросту то, что печатает сишный printf или шелловское echo в поток вывода (stdout). Чтобы как-то универсализировать параметры, передаваемые этой самой "просто программе", придумали спецификацию и назвали ее Common Gateway Interface (CGI).

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

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

Нельзя сказать, что подобная ситуация раньше всегда всех устраивала. Мне известен по крайней мере один интересный вариант вебсервера, который написал Mike Cowlishaw (если я правильно помню, это очень продвинутый английский дядька, долгое время работающий в исследовательском центре IBM, в частности он чуть ли не основной идеолог языка REXX). Этот сервер был сделан еще во времена браузера Mosaic (вот откуда взялось слово Mozilla) и Netscape 1.0, и представлял собой достаточно компактную и быструю программку под OS/2, которая обрабатывала входящие соединения, но всю логику в ней реализовывал REXX скрипт. На нем без труда можно было реализовать различную обработку, скажем, для разных видов файлов, был вариант реализации тего же CGI интерфейса для внешних программ, красивых индексов, шапок/сносок и многое другое. Прекомпилированный скрипт, находящийся в памяти, позволяет всему хозяйству работать достаточно шустро.

Не смотря на всеми эти прелести от чистой науки, CGI технология достаточно уверенно пробила себе дорогу в светлое будушее Веба при помощи Netscape, NCSA сервера и Another Patch'а к нему (не напоминают эти слова имя одного из лидирующих ныне серверов ?).

Хоть всем и видны недостатки используемых методов создания динамического контента, от них не так-то просто отойти, ото всей кучи наработанного софта и запущенных (и поддерживаемых) инсталляций. Как обычно, в таких случаях был придуман еще один "хак" - FastCGI. Это способ использовать старые проверенные cgi программы с минимальными доделками, но не пускать их каждый раз, а как бы держать в памяти запущенную копию и просто отдавать туда на обработку поступающие запросы. Особенно это удобно для работы со всякими СУБД, коннект к которым занимает порой целую вечность. Тут важно не забывать, что в этом случае даже за маленьким скриптом тянется вагон кода библиотек для оргинизации взаимодействия с сервером базы данных.

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

Для таких вещей были придуманы скрипты, встроенные прямо в HTML страницу. В сервера Apache есть различные модули для обработки таких страниц. По сути, скажем, mod_perl просто разбирает нужную страницу на html код и код на Perl, который компилируется на лету, а html фрагменты потом как бы вставляются в соответствующих местах получившейся программы. Весь этот процесс происходит "на территории" сервера, при этом не запускаются внешние процессы, есть возможность не открывать каждый раз новое соединение с сервером базы данных и, вообще, сохранять какие-либо параметры о клиенте от запроса до запроса. Все эти возможности позволяют значительно улучшить систему, как с точки зрения экономии ресурсов, так и с точки зрения возможностей программирования. Со встроенными скриптами появляется возможность управлять самой HTTP сессией, например, встревать в процесс авторизации.

Большое распространение из скриптовых веб-языков получил PHP. Это направление получилось, как водится, из небольшого набора средств для формирования HTML, которое потом вылилось в полноценный язык программирования со множеством функций. Такая история происхождения отрицательно сказывается на самом языке. Многие вещи в нем притянуты за уши, а многих не хватает. Но популярность свою PHP завоевал именно простотой и легкостью освоения, скажем так, не очень сведущими в программировании людьми. Так же, большим плюсом является наличие большого числа встроенных функций, начиная от простой арифметики, заканчивая графикой и интерфейсом с СУБД.

Вышеупомянутые Perl, PHP или Python совсем не обязательно должны встраиваться в html страницы. Нередко их используют прямо через CGI интерфейс, а то и вообще, без вебсервера. А то и на них самих пишут сервера.

(продолжение следует)

(C) Maxim Penzin, 2000
специально для cooler-online.com

В разделе "Рубрикатор" я выложил первые две части статьи "Платы ввода/вывода и компрессии изображения" И.Витиорца (специалист по нелинейному видеомонтажу и разработчик плат обработки видео Olkhon, Olkhon-II, Tungus). Статья была написана еще в 1997 году, но абсолютно не потеряла привлекательности из-за описания основ построения плат для обработки видео вводе/выода.

Последствия оверклокинга :)