Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "KOL";
Текущий архив: 2007.09.23;
Скачать: [xml.tar.bz2];

Вниз

Форт-подобная машина Владимира Кладова   Найти похожие ветки 

 
homm ©   (2007-02-17 14:05) [0]

Итак, завел отдельную ветку :)

для тех, кто все еще в танке:
http://kolmck.net/sf/architecture_contrary_to.zip

Все-же есть вопросы. Правильно ли я понимаю, что мы получаем в распоряжение ровно половину памяти от всего имеющегося объема? Остальная идет на описание правд доступа к первой половине в виде 4-х байтных дескрипторов для каждых 4-х байт в основной памяти. Но у каждого процесса должны быть свои права доступа к памяти, соответсвенно такая таблица нужна для каждого процесса? Или я чего-то не догоняю?


 
Vladimir Kladov   (2007-02-17 16:01) [1]

я так понял, что вы не поняли, что дескрипторы в теневой половине памяти - это не таблица прав доступа, а именно дескрипторы, т.е. числа. Они задают принадлежность 1, 2, 3 или 4 байт из основной памяти тому или иному множеству (остальные 3, 2, 1 или 0 недоступны вообще - так обеспечивается точность защиты до 1 байта). А в таблице прав для каждого процесса задаются для каждого из <= 2**20 дескрипторов соответствующие права, по 2 бита на дескриптор. Дескриптор можно считать неким числом, которое выделяется просто по порядку номеров, или из массива свободных дескрипторов. А вот для множества дескрипторов с 0 по N у процесса должны быть выставлены права в его таблице прав доступа. Проще, наверное, представить по аналогии в винде какой-нибудь общий ресурс типа memory mapped file. Его дескриптор - это просто число. Права на доступ от каждого процесса система хранит у себя, вместе с описанием открытого маппированного "файла". Ну или можно попробовать представить себе процедуру проверки прав доступа. Берем из теневой памяти дескриптор, из таблицы AccessT  текущего процесса смотрим на 2х-битный набор флажков с соответствующим номером, получаем 2 бита прав доступа.


 
homm ©   (2007-02-17 18:18) [2]

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


 
Vladimir Kladov   (2007-02-17 18:53) [3]

да преимущество не в этом. Нет, не медленнее. Кэши нужны в любом случае. Для виртуальной памяти в х86 начиная с 286 - тоже. Нешто вы считаете, что таблицы для виртуализации жрут меньше (памяти и времени)? Даже наверняка больше. Я потому и думаю, чтобы от этого дела хотя бы в простом случае отказаться. В ПЦ механизм виртуализации сохраняется одновременно еще и как средство разделения адресных пространств задач. Собственно, другого механизма разделения адресных пространств у ПЦ (да и у других современных архитекутр) и не предполагается. Я думаю это дело разделить, и просто позволить всем задачам работать в одном адресном пространстве.

Частота не то чтобы растет медленно. Она больше не будет расти скоро, если останутся на той же элементной базе (транзисторы). Дальше возникает противоречие: меньше напряжение - меньше частоты. Больше напряжение - больше тепловыделение. Разве что остается придумать компактный гелиевый охладитель. Для домашнего компа - как-то немножко страшновато.

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

Пропускная способность памяти - это и правда большая проблема. Но если бы это действительно была бы такая большая проблема, то ПЦ не стоило бы даже и пытаться разгонять до 3ГГц, еще и делать многоядерными. Принцип 80/20, знаете? 80% времени в программе работают 20% кода. Из всего массива данных подавляющее время задача работает с 20%, остальные 80% не востребованы. Если бы это было не так, мы и сейчас сидели бы на пне-100, и больше просто не было бы. В общем, приличный размер кэша, причем желательно 2 уровня - это реальный выход по решению проблемы пропускной способности памяти.


 
Vladimir Kladov   (2007-02-17 20:47) [4]

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

1. Разделив стеки (вычислительный и программный) и отделив (отвязав) их от адресумой памяти, тем самым я увеличиваю вдвое пропускную способность автоматически: теперь ядро процессора взаимодействует с этими хранилищами по раздельным шинам, одновременно. Запретив возможность изменения кода (к чему, кстати, пришла, наконец и фирма Майкрософт в своем проекте Сингуларити), я тем самым убираю необходимость отслеживания таких изменений в коде: архитектура остается Фон-Неймановской, но приобретает некоторые черты Гарвардской (раздельное хранение команд и данных - они у меня хранятся в одной памяти, но не пересекаются). В итоге ядро совершенно независимо работает по двум другим шинам с памятью данных - через кэш данных, и с памятью команд - через кэш команд. То же касается и кэша системных таблиц: работа с ним идет через отдельную, пятую шину, так же совершенно независимо и одновременно со всеми прочими кэшами.

Как известно, в Интеловской машине (и в ее АМДшном аналоге) есть только 2 кэша: кэш данных и кэш команд. И при этом процессор еще и вынужден отслеживать возможность записи в память команд. В новых моделях есть так же и отдельные кэши для верхушки стека, иначе вызовы подпрограмм становились бы совершенно неприемлемо долгими, но и здесь процессор вынужден постоянно отслеживать возможность изменения стека, адресуемого как обычная память, командами обычного доступа к памяти (что значительно снижает эффективность такого усовершенствования).

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

В современной Интеловской модели дошло до абсурда: из-за сложной декодировки команд, в процессор встраивается кэш декодированных команд (!). Это ж надо додуматься до такого... Достаточно прикинуть, во что обходится хранение в этом кэше одной декодированной команды, если ее разрядность - несколько десятков байтов.

3. Длина команды Интел, средняя, среди исполняемого потока, колеблется в районе 5-6 байт. У меня - 2 байта в среднем, т.к. больше половины команд - однобайтовые, и подавляющее число остальных - 2 байта. Есть считанное число 3х-байтных и 5-байтных. (Вывод: в кэш команд влезет в 3 раза больше кода, прогон _того_же_количества_байтов _кода(что и в х86) через декодирование даст в 2.5-3 раза больше команд на такт).

Я уже сделал набросок декодировщика команд, и со всей ответственностью заявляю, что реально за такт прогонять через декодировщик 8хN (где N зависит только от объема логики) байтов команд, поставляя за такт те самые 8xN "инструкций" (см. неподробное описание в архиве), в реальности получается в среднем 4хN физических инструкций. Я так же сделал уже и даже частично протестировал хранилище операционных ячеек, и виртуально подтвердилось мое предположение, что реально организовать одновременный доступ к 8хN ячейкам за такт на чтение и на запись - по двум рядам независимых (внутренних) шин данных. И проверил на программной модели придуманный мной механизм распределения номеров операционных ячеек (модель показала, что за такт спокойно может быть выделено 16xN номеров с вероятностью отказа в выделении <<1% - этот знак означает "пренебрежительно меньше", а не просто "меньше"). Наброски очереди инструкций не завершены пока, и без прочих устройств протестировать их нельзя, но мое предположение таково, что и там есть возможность за такт обработать 8хN инструкций, а освободить можно вообще хоть все отработанные четверки инструкций за раз, было бы желание. Итого: 8хN "инструкций" за такт в пиковом режиме, т.е. 4 в среднем. Полагая, что пиковый режим - это 80% времени исполнения, скорость весьма близко приближается к 4*(тактовая частота).

continued...


 
Vladimir Kladov   (2007-02-17 20:48) [5]

continue

4. Интеловские инженеры утверждают, что несмотря на все их исхищрения, из-за проблемы зависимости по данным, средняя скорость работы их процессора составляет 1.2 инструкции за такт. Я полагаю, что проблема здесь - в несовершенстве регистровых архитектур. Несмотря на введение переименования регистров, эти самые регистры + регистр флажков остаются тем самым препятствием, которое ограничивает скорость работы программы. Шутка (не штука) в том, что если бы не регистры, то можно было бы смотреть чуть дальше, чем в пределах нескольких подряд вычисляемых выражений. И вот там-то как раз и происходит развязка большинства зависимостей по данным. В файле "Архитектура - перенос состояний.htm" приводится пара примеров, как это работает, поэтому не буду останавливаться. Это только на первый взгляд кажется, что техника стековых вычислений связывает процессор по рукам и ногам. Стоит применить технику переименования регистров (у меня - в виде массива операционных ячеек), и стековая машина с ее безадресным набором команд превращается в идеальный инструмент для разрешения подобных зависимостей. Кроме того, отказ от регистра флажков (фактически, хранение 2х флажков на 1 операционную ячейку) позволяет часто принимать решения о ветвлении еще до того, как выполнится вычисление анализируемого значения. В итоге, я рассчитываю (на первых порах хотя бы) вообще обойтись без каких-либо хитрых предсказателей ветвлений.

И самое интересное то, что чем больше кратность логики, и чем больше очередь инструкций, тем дальше вперед удается "смотреть", и тем больше зависимостей по данным разрешается. Т.е., на многих задачах скорость действительно будет (я надеюсь) расти линейно увеличению объема логики. Так что приведенные мной цифры 3ГГц тактовой -> 32ГГц виртуальной скорости - это, скорее всего, правда (для случая 8x3, т.е. 12 физических инструкций за такт). К сожалению, в случае FPGA N=1 - это, вероятно, предел нынешних возможностей, но и это дает где-то 3х-4х кратное превышение тактовой (т.е. ~1ГГц, что для FPGA вообще-то из разряда "не быва[е]т"). Я все-таки надеюсь сделать "внешнюю" тактовую не ниже 280-320 МГц, хотя тут тоже много ограничений возникает. (Внешняя в кавычках, потому что многие современные плиски не нуждаются в физически внешней, у них кварц и делители частот встроенные).

Дополнительный фокус с использованием префикса условного выполнения только перед инструкциями, не изменяющими высоты вычислительного стека, позволяет обойтись без малейшей приостановки конвейера-водопровода на некоторых классических задачках, для решения которых в обычной архитектуре (неважно, х86 или ARMx) приходится делать условный переход, со всемы вытекающими. Например x = max(a,b). Интел до команд типа CMOV додумался слишком поздно: их не применяет ни один нормальный компилятор С/С++ (а Паскаля подавно), кроме как по требованию программера, уверенного в том, что его прогу не будут запускать на чем-то ниже пня-4.

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

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


 
homm ©   (2007-02-17 20:51) [6]

> Из всего массива данных подавляющее время задача работает
> с 20%, остальные 80% не востребованы.
О! если бы это было так... :) Я вот время от времени запускаю у себя нынче модную и очень требовательную к железу игру Обливион, дак вот она у меня идет ну просто никак!!! Все потому что оперативы 256. Я видел как она идет на 512. Первые 20 минут вообще ничего не тормазит, дальше не знаю, не видел :) Получается что она требует много больше 50% памяти в малом промежутке времени, от всего требующегося ей объема, который (по крайней мере поначалу) полностью помещается в 512мб ОП. Тоже самое с архиваторами. Вы бы знали, как я страдаю от того что у MTsv DN, который делает архивы на колНмск.ру, 512 (или больше) оперативы. У меня распаковка сильно тормозит. Это я все к тому что программы может и гоняют 20% своего кода одновременно, но этот код может ворочаеть данными, требующими много большего количества памяти в малый промежуток времени.
Хотя может и вправду таблицы для виртуализации не более эффективны, НО
Вы же упомянали о том что возможно когдато появится и механизм виртуальзации в том числе, что тоже не может сказатся положительно на производительности, в частности нагрузке на память. Хотя возможно снизить потребление кэша к минимуму, сделав страницу скажем 64кб, и рассматривая теневую память как нечто неотделимое от основной (физически страница получится 128кб).
Кстати, еще один фактор вспомнил. В настоящее время почти что вся память работает в двухканальном режиме, что позволяет одновременно обращатся к теневой и основной памяти! Не такая уж и мрачная картина значит получается :)


 
Vladimir Kladov   (2007-02-17 21:07) [7]

Ну и насчет названия темы: все-таки к Форт-системе отношение весьма маленькое. Только отделение вычислительного стека от программного - это еще не Форт, а недоступность программного стека для программы кроме как по прямому назначению - это уже не форт. Не говоря уже о том, что у меня есть все-таки регистры A, B, C, D, хотя в основном предназначенные для индексации и адресации. В Форте такого в принципе нет и быть не может. Опыт (Collapse) показывает, что чисто Фортовский подход не совсем удобен для ЯВУ. Иногда очень имеет смысл загрузить Self (this) в регистр и пользоваться им на всем протяжении метода, например.

Хотя начал я все-таки (для себя) с удобств программирования/отладки и повышенной надежности. Быстродействие тоже очень важно, ибо кому нужен сверхнадежный тугодумный проц. А то, что памяти вдвое меньше получается... солить ее, что ли, память эту. 8 Гб (т.е. фактически 4Гб) - это достаточно близко к современным верхним границам. Даже на 64-разрядные пока что еще не ставят больше - просто платы не рассчитаны. Мои изыскания направлены в некоторое (хотя и не очень отдаленное) будущее. Мой прогноз таков, что через 2-4 года (если не раньше) FPGA догонят по быстродействию современные пни-4/3.2ГГц, память уменьшится по физическому размеру и увеличится по компактности примерно на порядок, а винчестеры через 3 года перестанут выпускать: перейдут на флэшки (уже сейчас 128Гиг по $1000 за штуку - реально приобрести в магазине даже у нас в глухой Сибири). Так что есть реальный шанс, что когда я завершу эту свою разработку, у меня будет куда ее запихнуть, и она придется очень даже кстати...


 
homm ©   (2007-02-17 21:11) [8]

> [4] Vladimir Kladov   (17.02.07 20:47)
> [5] Vladimir Kladov   (17.02.07 20:48)
Когда писал [6], этого еще не видел :) Просто класс!!! Аплодисменты стоя :)

> к чему, кстати, пришла, наконец и фирма Майкрософт в своем
> проекте Сингуларити
Представить страшно, что будет (хорошего надеюсь) если Майкрософт заинтерисуется в вашей разработке, как в платформе для своей операционной системе.

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

Остается только один вопрос: собственно что это? :) Я имею ввиду что должно получится в окончательном виде? Четко сформулированое описание этой платформы, опятные образцы, или все-же ожидается выпускать это в промышленных масштабах, хотя-бы как встрамые решения поначалу?

ЗЫ Не обижусь, если Вы не ответите на мой вопрос, сославшись на кммерчискую тайну.


 
Vladimir Kladov   (2007-02-17 21:12) [9]

Насет мультимедийных игр - там ситуация такова, что в видюху не влазят все текстуры, и на каждом кадре проц качает туда через AGP оченно много данных. Ессно из ОЗУ. Но ведь ему еще в ОЗУ надо и других данных кучи держать. И вовсе не факт, что он обращается при этом ко всей памяти постоянно. Все просто: пусть у вас есть таблица A[10000][65536], и вы на кадре делаете проход по всем 10000 элементам, но обращаетесь из каждых 64К байтов только к одному. В итоге, системе понадобится присутствие за кадр всех 10000 64Кбайтных страниц, хотя из них нужен только 1 байт. Возникает жуткий своп. Вот такие пироги.


 
Vladimir Kladov   (2007-02-17 21:19) [10]

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

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

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


 
homm ©   (2007-02-17 21:22) [11]

> [10] Vladimir Kladov   (17.02.07 21:19)
Владимир, не заставляете будущим поколения россиян доказывать будущим поколения буржуев, что архетектура современных (для них) компьютеров придама Кладовым, а не Марконни :)))


 
Galkov ©   (2007-02-17 21:28) [12]


> для тех, кто все еще в танке:
> http://kolmck.net/sf/architecture_contrary_to.zip

Извините за вмешательство в происходящее...
А нельзя ли уточнить с чего начинать чтение, и в какой последовательности.
Что ни взгляну (пока не долго, правда) - оно вроде ПРОДОЛЖЕНИЕ чего-то...


 
homm ©   (2007-02-17 21:29) [13]

Наверное правильнее гачать с "Архитектура вразрез2.htm"


 
Vladimir Kladov   (2007-02-17 21:31) [14]

Вы знаете, и я знаю, что радио первым изобрел Попов. И что первый самолет (взлетавший с рельсов), и первая подводная лодка - были сделаны в России. И никакое патентное право не может этого отменить. Есть авторское право, а оно выше. А само патентное право я считаю самым ретроградским изобретением, какое только можно было изобрести для тормоза прогресса. Именно "благодаря" этому патентному праву мы до сих пор ездим на вонючих машинах с бензиновым двигателем, например, а не летаем на бесшумных летающих тарелках...


 
homm ©   (2007-02-17 21:37) [15]

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

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

Я к тому что нелюбить можно, а непризнавать эти бюро - чревато.


 
Galkov ©   (2007-02-17 23:16) [16]


> homm ©   (17.02.07 21:29) [13]
> Наверное правильнее гачать с "Архитектура вразрез2.htm

А если еще раньше ???
Или только для избранных ???


 
homm ©   (2007-02-17 23:22) [17]

> А если еще раньше ???
> Или только для избранных ???
Избраный здесь лишь один, и "раньше" только у него в голове, как я понимаю :)
Это же не книжка по физики за 6-й класс, где все разжовано..
"Таблица команд (MODE 64)" для общего представления в том документе не нужна, а дальше можеш взятся за
"Архитектура - проект FPGA (ХХХ).htm" Потом без разницы наверное, я сам нечаяно наткнулся на эти документы, незнаю почему Владимир не афишировал здесь.


 
Vladimir Kladov   (2007-02-18 08:49) [18]

Ну наверное потому что это не совсем про программирование. Я нечаянно в конце прошлого года полез узнавать про HDL, много чего узнал, и просек, что теперь можно пробовать делать железо, не хватаясь за паяльник, и не разбираясь в номенклатурах множетсва мелких микросхем. Для меня стало откровением, что железо спокойно описывается языком, весьма похожим на С или Аду, просто параллельным. В общем, мне сразу понравился Verilog, я заказал софт (синтез, моделирование), и стал вспоминать свои давние идеи. Куда раньше-то? То, что было в 94-98, я уже в точности и не вспомню. Помню, что было очень похоже, но не было индексно-адресных регистров. Это уже по следам недавних экспериментов и в результате тесной работы с объектным программированием пришло. Да и трансляторов/компиляторов в купе с эмуляторами за прошедшие годы пришлось написать немало (даже для основной работы).

Мне бы, конечно, не помешала какая-то помощь. Проблема в том, где искать единомышленников в этой области. Нужно ведь или знание, или желание познакомиться с Verilog HDL, например. Там, где люди уже что-то на нем делают, мало желающих подхватывать чужую идею, и куда-то ее тащить. Но я думаю, что и для одного эта задача все еще выполнима. Опыта только не хватает. Все-таки, тут есть вещи, написать которые можно весьма по-разному, и надо, чтобы все работало быстро, а проверить сразу не удается. Та же очередь инструкций. Без взаимодействующих устройств синтезатор после полчаса компиляции просто создает пустую схему из 0 логических элементов - если засунуть внутрь CPU. А если не засовывать, то как отдельное устройство эта очередь просто не влазит в чип - не хватает ножек (надо > 1000). Очень много независимых шин в разные стороны потому что.


 
AndreyRus   (2007-02-18 14:31) [19]


>  Интел до команд типа CMOV додумался слишком поздно: их
> не применяет ни один нормальный компилятор С/С++ (а Паскаля
> подавно), кроме как по требованию программера, уверенного
> в том, что его прогу не будут запускать на чем-то ниже пня-
> 4.

Команда CMOV появилась в Pentium II, вернее даже раньше в "Pentium Pro" и компиляторы ее поддерживают, в том числе и Pascal"я ("Free Pascal").


 
Vladimir Kladov   (2007-02-18 14:38) [20]

У меня комп какой-то из 2х старых не захотел запускать. Правда, я сейчас не могу сказать точно, какой именно, пень100 или II/450.
Ну да, в асм-вставках можно хоть что закодировать и на Delphi. Имеется в виду, что компилятор сам эту команду не применяет, когда сам код из ЯВУ синтезирует.


 
Sapersky   (2007-02-19 12:30) [21]

Относительно FPGA/Verilog:

http://www.elphel.com/index_rus.html

"Исходные тексты для FPGA и программного обеспечения всех продуктов доступны согласно лицензии GNU GPL".

Хотя это совсем не CPU общего назначения, а весьма узкоспециализированная разработка, но может чем-то поможет.



Страницы: 1 вся ветка

Форум: "KOL";
Текущий архив: 2007.09.23;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.72 MB
Время: 0.137 c
15-1187936776
palva
2007-08-24 10:26
2007.09.23
Конференция Начинающим


15-1187157030
Alien1769
2007-08-15 09:50
2007.09.23
КМП-2007


15-1187761907
fisher
2007-08-22 09:51
2007.09.23
Что читают программисты на работе(и не только)


15-1188071825
Turbouser
2007-08-25 23:57
2007.09.23
DM клиент


11-1171710316
homm
2007-02-17 14:05
2007.09.23
Форт-подобная машина Владимира Кладова





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский