Здравствуйте, Olej, Вы писали:

O>Собственно "да" ... сильное утверждение. Но только:

O>1. Perl, Python, Java ... а ещё Tcl/Tk, awk ... они ведь не для того ... чтобы сравниваться — они для определённых больших класов задач. Perl, например, "язык системного программирования UNIX" (хотя WEB-писателям показалось, что для них...).

O>2. Более того, например, LISP или PROLOG — никогда не сравнятся по быстродействию с Perl ... но практически все работы в области искуственного интелекта пишутся на них...

В этих языких иные принципы программирования и ИИ на Перле писать — это можно повеситься.

O>3. Или ... никакой C или C++ "не сравнятся по быстродействию с бинарным кодом, который получился в результате компиляния FORTRAN" (и поверьте это так — из-за структуры синтаксиса). Может все перейдём на FORTRAN?

Потому Микрософт выпускает Visual Fortran.

O>4. Или так ... никой C или C++ "не сравнятся по быстродействию с бинарным кодом, который получился в результате трансляции ассемблерного кода" — у кого-то есть возражения?

Потому ассемблер не умирает. Я знаю две организации, которые пишут на С + Asm под вынь.


O>5. Или даже так ...: а какой C++ компилятор имеете в виду? Я сам проверял на большеобъёмных вычислительных задачах (когда зарузка процессора не перемежается с внешними операциями) из области цифровой обработки сигналов (БПФ, авто-регрессионный спектральный анализ etc.):
O>- один и тот-же код, компилированный (с максимальными оптимизациями) VC 6.0 & Borland Builder 5.2 отличаются по производительности в 3 (!!!) раза (в пользу VC);
O>- и тот же код, компилированный GCC 2.95.X выигрывает у VC 6.0 — в 1.5 раза...
Ну не надо такой дезы. Посмотри результаты тестирования на этом сайте.

А по существу — средний комилер основательно обставляет Жаву, Шарп и VB.

PE>>Это именно та причина, из за которой все еще приходится писать сервера на С++.

O>Это "именно не та причина" из-за которой сервера пишутся (и то не всегда — пишутся и на Perl, и ещё как пишутся!) на C++ (иногда). А причина: "надёжность" программного кода и выявление подавляющего количества ошибок на периоде компиляции...

Я же тебе говорю, когда основной фактор — быстродействие, то пишут на С++ и даже на АСМ.

O>А производительность (кода) для серверов, зачастую — до фени ... какая производительность, если порождение дочернего процесса (копии) для крупного сервера (будь то fork, будь то Win execXX) может занимать на 233MMX (к примеру) до 2.5 сек. — и это системная операция, не зависящая от производительности пользовательского кода... Если OS использует технику COW (copy on write) страниц ... то это тоже просто обман пользователя (то-же, но в красочной упаковке) — те же потери, но "размазанные" по циклу обслуживания...

А почему ты эти крайности взял ? Возьми алгоритм какой — БПФ например, маршрутизацию, трассировку, алгоритм для графа и сравни.
Если алгоритм работает неделю !!! то у извини, нахрен он нужет рядовому пользователю.

Перловый сервер не сможет обеспечит того быстродействия, какой можно достич на С++.
Слишком много издержек и вовсе не на форках и тд.
На особо быстродействующих серверах никто не форкает.
Делается конечный автомат и много потоков дл обслуживания клиентов.
Ну форкнешь ты 100 раз. А если тебе нужно 10000 раз ? Да издохнет любая система.
Тут используется поточность и конечные автоматы.

O>Вот почему, например, Apache в последних версиях использует технику prefork, которая снижает затраты на 2-3 порядка (!) — но это алгоритмическая техника ... а зачем тогда выигрыш в производительном коде в ... 3-5-10 раз?

O>Вот об том, как "пишутся сервера" ... вы спрашивайте, спрашивайте... Я расскажу.

PE>>Единственный рулящий способ IPC — сокеты. На винде сокеты почти никто для IPC не юзает.

O>Ню-ню-ню...
O>В POSIX — больше 2-х десятков принципиально различных механизмов IPC — собственно все, которые описаны в теории ... да-да именно в теории, потому, что "параллелизм — синхронизация" — это хорошо проработанная теория, в университетах (а не в Microsoft, как кто-то мог заключить, читая HELP-ы того же Microsoft) начиная с работ того же Э.Дейкстры, которым весь этот subj, собственно, и создан...

O>На винде сокеты, действительно, никто для IPC не использует, это правда... Но это исключительно только потому, что на винде они "ни в п...." не годятся!

О да. А не потому ли, что есть объектно ориентированные средства IPC ?

И почему сокеты виндовые не годятся ? И какие из них ?

O>- сначала Андриан Кинг ("Windows 95 изнутри"), Мэтт Питрек ("Секреты системного программирования в Windows 95"), Эндрю Шульман ("Неофициальная Windows 95") — всё мировые бестселлеры — даже с удивлением для себя (они то — лучшие друзья MS) находят в "защищённой 32-битной" системе огромные куски 16-бит кода... MS сконфуженно сознаются ... и говорят "потом"...

Про то, чт 95 — полностью 32 разрядная система никто не говорил.
В MSDN так и написано — модули USER, GDI и тд — 16 разрядные.
Эта система нужны быда для совместимости со старой 3.11

Надуюсь ты не думаешь, что WinNT — 16 разрядов ?

O>- потом те же настырные А.Кинг, М. Питрек, Э.Шульман и другие "доброжилатели" (забава-то становится уже занимательной) ... находят "торчащие уши" 16-бит кода в Win98 ... но этого мало: всё тот же PSP от 16-бит формата EXE задачи... Какой позор ... MS говорят "потом"...

Не говорили они такго никогда. В планах было свести 2 линейки в одну. Это и получилось, но попозже.

На NT не работают многие16разрядные аппликации. А вот в 95х — запросто. Для этого и нужны были эти системы.

O>- потом в точности та же история повторяется с WinME ... MS говорят "потом"...

95/98/Me — это одна система, которая уже почила. Она наполовину 16 разрядная.
Не знаю, какие ты источники читал, но я всегда это знал и юзал NT и OS2.


O>Что там — торчащие из WinXP "ослиные уши" 16-бит кода уже нашли?

Не гони. XP — на базе 2000 которая на базе NT40 которая на базе NT3.51, которая унаследовала от 3.11 только !!! интерфейс.
NT всегда была 32 разряда.

Исходный код XP компилится и в 32 и в 64 бита.
Нет теперь линеек разных, линейка 9х/Me закрыта.

V>>>>>Читай выше — даже .NET на 64 бита толком перенести не могут..
PE>>>>Пока не могут. Никто же не говорил, что это сразу сделано будет.

O>Нет, конечно, это будет сделано ... "потом" ...

Не бойся, Микрософт не собирается издыхать. 64 разряда будут к концу года.