CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

29.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 20.05 - У Центробанка России похитили новую базу данных
  • 20.05 - Домашнюю страницу Google теперь можно персонализировать
  • 20.05 - В новом Netscape обнаружены старые "дыры"
  • 20.05 - Крупнейшие сотовики создали объединенную базу должников
  • 20.05 - Пиратские копии последней серии "Звездных войн" уже "разгуливают" в интернете
  • 20.05 - Русские программисты покорили Америку
  • 20.05 - IP-телевидение "Открытых Технологий"
  • 20.05 - Netscape 8 настроен обороняться от фишеров
  • 20.05 - "Яндекс" выпустил антиспамовый фильтр
  • 20.05 - ИТ-гиганты хотят отобрать Wi-Fi-патенты у Австралии
  • 19.05 - Software-testing.Ru будет развиваться при поддержке Borland
  • 19.05 - Intel прекращает выпуск Pentium M с частотой шины 400 МГц
  • 19.05 - Госсекреты США утекают через Wi-Fi-сети
  • 19.05 - Microsoft выпустила руководство по безопасности
  • 19.05 - Вышла финальная версия браузера Netscape 8.0
  • 19.05 - Intel готовит аппаратную платформу для корпоративных ПК
  • 19.05 - Бесплатные звонки через Yahoo! стали удобнее
  • 19.05 - Google купил два домена за миллион долларов
  • 19.05 - Соколов уверен: Рунет невозможно контролировать
  • 19.05 - В штате Вашингтон принят суровый закон против шпионского ПО
  • 19.05 - Google предложил настольный поисковик для бизнеса
  • 19.05 - Почту на Mail.Ru теперь можно слушать по мобильному телефону
  • 18.05 - Intel и Novell: Linux догоняет Microsoft в Бразилии
  • 18.05 - Gartner: IBM с Geronimo составит конкуренцию JBoss, BEA, Oracle
  • 18.05 - Seiko создала часы на основе "электронных чернил"
  • 18.05 - Японские батарейки работают на человеческой крови
  • 18.05 - PalmOne анонсировал КПК LifeDrive
  • 18.05 - Студенты МГУ будут обучаться на SAP
  • 18.05 - Intel запускает платформу для настольных ПК
  • 18.05 - Безопасность VPN оказалась виртуальной
  • 18.05 - Microsoft и Toshiba договорились об использовании патентов друг друга
  • 18.05 - Вторая версия Free Pascal: код полностью переписан
  • 18.05 - США будут искать террористов в интернете
  • 18.05 - Через пять лет все существующее ПО будет подделываться пиратами
  • 18.05 - Интернет-провайдеры Китая будут следить за пиратами в Сети
  • 18.05 - ЮТК построила мультимедийную МСС
  • 18.05 - "Альфа" подала иск о недействительности устава "Вымпелкома"
  • 18.05 - NTT DoCoMo представила мобильники с системой мобильного кошелька
  • 18.05 - В Байнете появился самообучающийся антиспам
  • 18.05 - AIM и ICQ интегрируют в онлайновые игры

    Архив новостей >>>


  • 2004 г.

    Сравнительный анализ компиляторов С++

    Игорь Тимошенко, "Комиздат"

    К сожалению, выбор компилятора часто обусловлен, опять-таки, идеологией и соображениями вроде "его все используют". Конечно, среда разработки Microsoft Visual C++ несколько более удобна, чем у портированного gcc - но это ведь вовсе не значит, что релиз своего продукта вы должны компилировать с использованием MSVC++. Используйте оболочку, компилируйте промежуточные версии на MSVC++ (кстати, время компиляции у него гораздо меньше, чем у gcc), но релиз можно собрать с использованием другого компилятора, например от Intel. И, в зависимости от компилятора, можно получить прирост в производительности на 10% просто так, на ровном месте. Но какой "правильный" компилятор выбрать, чтобы он сгенерировал максимально быстрый код? К сожалению, однозначного ответа на этот вопрос нет - одни компиляторы лучше оптимизируют виртуальные вызовы, другие - лучше работают с памятью.

    Попробуем определить, кто в чем силен среди компиляторов для платформы Wintel (x86-процессор + Win32 ОС). В забеге принимают участие компиляторы Microsoft Visual C++ 6.0, Intel C++ Compiler 4.5, Borland Builder 6.0, MinGW (портированный gcc) 3.2.

    Порядок тестирования

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

    Вроде все просто - но тут начинают возникать определенные проблемы. Провести тестирование некоторых конструкций (например, обращение к полю объекта) не удастся из-за оптимизации на уровне компилятора: строки типа for (unsigned i=0;i<10000000;i++) dummy = obj->dummyField; все компиляторы просто выбросили из конечного бинарного кода.

    Вторым неприятным моментом является то, что в результаты всех тестов неявно вошло время выполнения самого цикла "for", в котором происходит набор статистики. В некоторых реализациях оно может быть очень даже существенным (например, два такта на одну итерацию пустого for для gcc). Измерить "чистое" время выполнения пустого цикла удалось не для всех компиляторов - VC++ и Intel Compiler выполняют достаточно хорошую "раскрутку" кода и исключают из конечного кода все пустые циклы, inline-вызовы пустых методов и т.д. Даже конструкцию вида for (unsigned i=0;i<16;i++) dummy++; VC++ реализовал как dummy += 16;.

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

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

    Для измерения времени выполнения тестов использовался счетчик машинных тактов, доступный по команде процессора RDTSC, что позволило не только сравнить время выполнения большого количества однотипных операций, но и получить приближенное время выполнения операции в тактах (вторая величина является более показательной и удобной для сравнения). Все тесты проводились на Pentium III (700 МГц), параметры компиляции были установлены в "-O2 -6" (оптимизация по скорости + оптимизация под набор команд Pentium Pro). Кроме того, для Borland Builder была добавлена опция --fast-call - передача параметров через регистры (Intel Compiler, MSVC++ и gcc автоматически используют передачу параметров через регистры при использовании оптимизации по скорости).

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

    Тестирование скорости работы основных конструкций языка

    Первый тест очень даже прост, он заключается в измерении скорости прямого вызова (member call), виртуального вызова (virtual call), вызова статик-метода (данная операция полностью аналогична вызову обыкновенной функции), создания объекта и удаления объекта с виртуальным деструктором (create object), создания/удаления объекта с inline-конструктором и деструктором (create inline object), создание template'ного объекта (create template object). Результаты теста приведены в таблице 1.
    Таблица 1. Результаты тестирования скорости работы основных конструкций языка
    VC++ Intel Compiler Bulder C++ MinGW (gcc)
    virtual call 140 (9) 134 (9) 139 (9) 183 (12)
    member call 124 (8) !34 (9) 103 (7) 154 (10)
    static call 121 (8) 113 (7) 109 (7) 118 (8)
    create object 606 (424) 663 (443) 459 (321) 619 (433)
    create inline object 579 (405) 600 (420) 343 (240) 590 (413)
    create temlate object 580 (405) 599 (419) 349 (244) 579 (405)

    Первая цифра - это полное время, затраченное на тест (в миллисекундах); цифра в скобках - количество тактов на одну команду.

    Результаты получились очень даже интересными: первое место занял Borland Builder, а вот gcc на вызове методов, особенно виртуальных, показал существенное отставание. По всей видимости - из-за бурного развития COM'а, где все вызовы виртуальные, разработчикам "родных" компиляторов под Win32 пришлось максимально оптимизировать эти типы вызовов. Другим интересным фактом является то, что хорошо оптимизировать создание объекта с inline-конструктором и деструктором смог, опять-таки, только Builder.

    Конечно, у MSVC++ также наблюдается небольшой прирост производительности, но объясняется это тем, что MSVC++ очень хорошо "раскручивает" код и все заглушки просто выбрасывает. То есть в тесте с inline-вызовами MSVC++ определил, что вызываемый метод является пустым, и исключил его вызов. После исключения вызова пустого метода у него остался пустой цикл, который компилятор также выбросил.

    Borland же в случае использования inline-конструктора делает inline не только вызов метода "Конструктор", но и выделение памяти под объект. То же самое делает Builder относительно деструктора. Любопытно отметить, что с шаблонами Builder работает точно так же, как с inline-методами, чего совершенно не скажешь о других компиляторах.

    Тестирование STL

    STL, как известно, входит в ISO стандарт C++ и содержит очень много полезного и превосходно реализованного кода, использование которого существенно облегчает жизнь программистам. Конечно, MCVC++, gcc и Builder используют различные реализации STL - и результаты тестирования будут сильно зависеть от эффективности реализации тех или иных алгоритмов, а не от качества самого компилятора. Но, так как STL входит в ISO-стандарт, тестирование этой библиотеки просто неотделимо от тестирования самого компилятора.

    Проводилось тестирование только наиболее часто используемых классов STL: string, vector, map, sort. При тестировании string'а измерялась скорость конкатенации; для vector'а же - время добавления элемента (удаление не тестировалось, так как это просто тестирование realloc'а, которое будет проведено ниже); для map'а измерялось время добавления элемента и скорость поиска необходимого ключа; для sort'а - время сортировки. Так как Microsoft не рекомендует использовать STL в VC++, для сравнения было добавлено тестирование конкатенации строк на основе родного класса VC++ для работы со строками CString и, чтобы уж совсем никого не обидеть, то и родного класса Builder'а - AnsiString. Результаты, опять же, оказались очень даже интересными (см. табл. 2)
    Таблица 2. Результаты тестирования STL
    VC++ Intel Compiler Bulder C++ MinGW (gcc)
    string add 8 (572) 11 (837) 3 (244) 2 (199)
    AnsiString - - 11 (832) -
    Cstring 106 (7476) 104 (7331) - -
    sort 157 (10994) 156 (10943) 387 (27132) 226 (15848)
    vector insert 110 (77) 96 (67) 63 (44) 56 (39)
    map insert 1311 (1836) 1455 (2037) 848 (1148) 448 (627)
    map find 181 (127) 4 (3) 418 (293) 199 (139)

    Согласно результатам, не рекомендованный STL string работает в 12 раз быстрее, чем родной CString Microsoft! Как тут в очередной раз не задуматься о практичности рекомендаций Microsoft... А вот просто потрясающий результат на поиске от Intel Compiler это результат оптимизации "ничего не делающего кода" - поиск как таковой он просто выбросил из конечного бинарного кода. Не менее интересен результат gcc - во всех тестах, связанных с выделением памяти, gcc оказался на первом месте.

    Тестирование менеджера памяти

    Как известно, при выделении памяти malloc редко обращается напрямую к системе - и использует вместо этого свою внутреннюю структуру для динамического выделения памяти и изменения размера уже выделенного блока. Скорость работы этого внутреннего менеджера может весьма существенно влиять на скорость работы всего приложения. Тестирование менеджера памяти было разбито на две части: в первой измерялась скорость работы пары malloc/free, а во второй - malloc/realloc, причем realloc должен был выделить вдвое больший объем памяти, чем malloc.
    Таблица 3. Результаты тестирования менеджера памяти
    VC++ Intel Compiler Bulder C++ MinGW (gcc)
    malloc 905 (6336) 902 (6317) 24 (174) 882 (6178)
    realloc 30 (718) 30 (716) 12 (295) 30 (719)

    И снова быстрее всех был Borland Builder C++. Благодаря такой быстрой реализации malloc'а он находится на первом месте и по скорости создания/удаления объектов - да и на тестах STL, связанных с изменением размера блока памяти, бегает достаточно быстро.

    Разбор ассемблерного кода неких базовых операций

    Для анализа использовался достаточно простой код на С++:

    void dummyFn1(unsigned);
    void dummyFn2(unsigned aa) {
    for (unsigned i=0;i<16;i++) dummyFn1(aa);
    }

    А теперь посмотрим, во что этот кусок кода компилирует MSVC++ (приводится только текст необходимой функции):

    ?dummyFn2@@YAXI@Z PROC NEAR
    push esi
    push edi
    mov edi, DWORD PTR _aa$[esp+4]
    mov esi, 16
    $L271:
    push edi
    call?dummyFn1@@YAXI@Z

    add esp, 4
    dec esi
    jne SHORT $L271
    pop edi
    pop esi
    ret 0
    ?dummyFn@@YAXI@Z ENDP

    Как видно, MSVC++ инвертировал цикл и for (unsigned i=0;i<16;i++) у него превратился в unsigned i=16;while (i--);, что очень правильно с точки зрения оптимизации - мы экономим на одной операции сравнения (см. следующий листинг), которая занимает, как минимум, 5 байт, и нарушает выравнивание. Конечно, компилятор по своему усмотрению поменял порядок изменения переменной i, но в данном примере мы ее используем просто как счетчик цикла, поэтому такая замена вполне допустима.

    А вот что выдал Intel Compiler (вообще-то, он сначала вообще полностью развернул цикл, но после увеличения количества итераций на порядок прекратил заниматься такой самодеятельностью):

    ?dummyFn2@@YAXI@Z PROC NEAR
    $B1$1:
    push ebp
    push ebx
    mov ebp, DWORD PTR [esp+12]
    sub esp, 20
    xor ebx, ebx
    $B1$2:
    mov DWORD PTR [esp], ebp
    call?dummyFn1@@YAXI@Z
    $B1$3:
    inc ebx
    cmp ebx, 16
    jb $B1$2
    $B1$4:
    add esp, 20
    pop ebx
    pop ebp
    ret
    ?dummyFn2@@YAXI@Z ENDP

    Во-первых, используется прямой порядок цикла for, поэтому появилась дополнительная команда сравнения "cmp ebx, 16". А вот и очень интересный момент -перед началом цикла мы выделили на стеке необходимое количество памяти плюс некий запас ("sub esp, 20"), а потом вместо пары push reg;..;add esp, 4;, как это делает MSVC++, использовали одну команду копирования. Кроме того, использование регистра общего назначения ebx для счетчика цикла вместо индексного esi, как в MSVC++, дополнительно уменьшает время выполнения и размер кода.

    Borland Builder сгенерировал следующую конструкцию:

    @@dummyFn2$qui proc near
    ?live16385@0:
    @1:
    push ebp
    mov ebp,esp
    push ebx
    push esi
    mov esi,dword ptr [ebp+8]
    ?live16385@16:
    @2:
    xor ebx,ebx
    @3:
    push esi
    call @@dummyFn1$qui
    pop ecx
    @5:
    inc ebx
    cmp ebx,16
    jb short @3
    ?live16385@32:
    @7:
    pop esi
    pop ebx
    pop ebp
    ret
    @@dummyFn2$qui endp

    Если не считать большего количества подготовительных операций, то блок вызова собственно функции является чем-то средним между MSVC++ и Intel Compiler: цикл используется прямой и передача параметров осуществляется с помощью push reg;. Правда, есть интересный момент: вместо add esp, 4 используется pop ecx; что экономит, как минимум, 4 байта,- правда, из-за дополнительного обращения к памяти команда "pop" может работать медленнее, чем сложение.

    Ну и, наконец, gcc (обратите внимание, gcc для ассемблера использует синтаксис AT&T):

    __Z7dummy2Fnj:
    LFB1:
    pushl %ebp
    LCFI0:
    movl %esp, %ebp
    LCFI1:
    pushl %esi
    LCFI2:
    pushl %ebx
    LCFI3:
    xorl %ebx, %ebx
    movl 8(%ebp), %esi
    .p2align 4,,7
    L6:
    subl $12, %esp
    incl %ebx
    pushl %esi
    LCFI4:
    call __Z2dummyFn1j
    addl $16, %esp
    cmpl $15, %ebx
    jbe L6
    leal -8(%ebp), %esp
    popl %ebx
    popl %esi
    popl %ebp
    ret

    Данный код является самым плохим из всех приведенных выше - gcc использует прямой цикл плюс пару push esi;..;add esp, 4 (это происходит неявно в команде "addl $16, %esp") для передачи параметров; кроме того, резервирует место на стеке прямо в цикле, а не вне его, как это делает Intel Compiler. Кроме того, совершенно непонятно, зачем резервировать место на стеке, а потом использовать команду push reg;. Единственный приятный момент - это явное выравнивание начала цикла по границе, чего не делают остальные компиляторы - поскольку линейка кэша сегмента кода достигает 32-х байт, то метки начала циклов должны быть выровнены по границе 16 байт. На каждый байт, выходящий за пределы кэша, процессор семейства P2 тратит 9-12 тактов.

    Сравнение времени компиляции и размера выполняемого файла

    Для выполнения этого теста использовался все тот же исходный код, из которого были удалены все compiler-specific тесты. Тестирование выполнялось отдельно для компиляции релиза и для отладочной версии, размер бинарного файла указан только для релиза (см. табл. 4). Чтобы исключить влияние файлового кэша, проводились две одинаковые компиляции подряд - время измерялось по второй с помощью команды "date" (исключение составил только Builder - он сам измеряет время компиляции).
    Таблица 4. Результаты сравнения времени компиляции и размера выполняемого файла
    VC++ Intel Compiler Bulder C++ MinGW (gcc)
    release build time, sec 3 5 2.35 6
    release size, Kb 56 72 77 214
    debug build time, sec 3 5 3 7

    Первое место поделили Borland Builder и MSVC++, а вот gcc - опять на последнем месте, как по скорости компиляции, так и по размеру бинарного файла. Интересным моментом является тот факт, что время компиляции отладочной версии у gcc и Builder'а выше времени компиляции релиза. Объясняется это тем, что при компиляции отладочной версии компилятору необходимо добавить отладочную информацию, что существенно увеличивает размер объектного файла - и, как следствие, время работы линковщика.

    Результаты

    Казалось бы, вывод о самом эффективном компиляторе напрашивается сам собой - это Borland Builder C++. Но не стоит спешить. Многие разработчики указывают на ошибки при формировании кода у Borland Builder (в частности, при использовании ссылок его поведение становится непредсказуемым). Кроме того, Borland Builder C++ явно наследует многое от Delphi (один модификатор вызова метода DYNAMIC чего стоит), в результате чего при компилировании абсолютно правильного С++ кода могут возникать ошибки (например, отсутствие множественного наследования для VCL-классов; а все потомки от TObject являются VCL-классами).

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

    MSVC++ или Intel Compiler не имеют явно выраженных недостатков, так что их позиции примерно равны.

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


    SUPERSERVERS.RU - Аренда и Размещение Выделенных серверов! P4 2.6Ghz; 512 RAM; 2x80Gb SATA за 89 у.е./месяц. Бесплатный траффик.


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    19 мая

  • RAID-массивы начального уровня
  • Волокно на весу
  • КрUтой FTP-сервер (о программе Serv-U)
  • Повышенная переносимость (о переносе данных на новый компьютер под управлением Windows XP)

    17 мая

    Большие перемены в разделе Все об Open Source

    Новые статьи:

  • О свободе выбора в чтении документации
  • Linux и языки Восточной Азии. С чего начать начинающему?
  • UNIX 5-th Edition на x86, или не забывайте историю
  • Запись CD-R/RW в BSD-системах
  • DragonFly: монтирование образов CD- и DVD-дисков
  • Монтирование сменных устройств для FreeBSD без прав root'а
  • Монтирование cd (с правами пользователя) в FreeBSD 5.3. Продолжение темы
  • FreeBSD 5.3 для конечного пользователя: три аспекта мультимедиа

    Снова дискуссия:

  • Каждому свое!
  • О сравнении Windows и Linux
  • Еще раз о доблести и злокозненности(А.Федорчук)

    12 мая

  • Материалы конференции "Корпоративные базы данных-2005"
  • Репортаж с Open Source Forum Russia
  • Взаимодействие Microsoft Excel с приложениями .NET. Позднее связывание
  • PC-BSD: вхождение в берклианскую тему

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...