Здравствуйте, Plutonia Experiment, Вы писали:
PE>Никакой перл, питон, жава и тд не сравнится по быстродействию с бинарным кодом, который получился в результате компиляния С++.
Собственно "да" ... сильное утверждение. Но только:
1. Perl, Python, Java ... а ещё Tcl/Tk, awk ... они ведь не для того ... чтобы сравниваться — они для определённых больших класов задач. Perl, например, "язык системного программирования UNIX" (хотя WEB-писателям показалось, что для них...).
2. Более того, например, LISP или PROLOG — никогда не сравнятся по быстродействию с Perl ... но практически все работы в области искуственного интелекта пишутся на них...
3. Или ... никакой C или C++ "не сравнятся по быстродействию с бинарным кодом, который получился в результате компиляния FORTRAN" (и поверьте это так — из-за структуры синтаксиса). Может все перейдём на FORTRAN?
4. Или так ... никой C или C++ "не сравнятся по быстродействию с бинарным кодом, который получился в результате трансляции ассемблерного кода" — у кого-то есть возражения?
5. Или даже так ...: а какой C++ компилятор имеете в виду? Я сам проверял на большеобъёмных вычислительных задачах (когда зарузка процессора не перемежается с внешними операциями) из области цифровой обработки сигналов (БПФ, авто-регрессионный спектральный анализ etc.):
— один и тот-же код, компилированный (с максимальными оптимизациями) VC 6.0 & Borland Builder 5.2 отличаются по производительности в 3 (!!!) раза (в пользу VC);
— и тот же код, компилированный GCC 2.95.X выигрывает у VC 6.0 — в 1.5 раза...
С кем сравнивать будем?
И о чём это говорит вообще? ... Ни о чём!
PE>Это именно та причина, из за которой все еще приходится писать сервера на С++.
Это "именно не та причина" из-за которой сервера пишутся (и то не всегда — пишутся и на Perl, и ещё как пишутся!) на C++ (иногда). А причина: "надёжность" программного кода и выявление подавляющего количества ошибок на периоде компиляции...
А производительность (кода) для серверов, зачастую — до фени ... какая производительность, если порождение дочернего процесса (копии) для крупного сервера (будь то fork, будь то Win execXX) может занимать на 233MMX (к примеру) до 2.5 сек. — и это системная операция, не зависящая от производительности пользовательского кода... Если OS использует технику COW (copy on write) страниц ... то это тоже просто обман пользователя (то-же, но в красочной упаковке) — те же потери, но "размазанные" по циклу обслуживания...
Вот почему, например, Apache в последних версиях использует технику prefork, которая снижает затраты на 2-3 порядка (!) — но это алгоритмическая техника ... а зачем тогда выигрыш в производительном коде в ... 3-5-10 раз?
Вот об том, как "пишутся сервера" ... вы спрашивайте, спрашивайте... Я расскажу.
PE>Единственный рулящий способ IPC — сокеты. На винде сокеты почти никто для IPC не юзает.
Ню-ню-ню...
В POSIX — больше 2-х десятков принципиально различных механизмов IPC — собственно все, которые описаны в теории ... да-да именно в теории, потому, что "параллелизм — синхронизация" — это хорошо проработанная теория, в университетах (а не в Microsoft, как кто-то мог заключить, читая HELP-ы того же Microsoft) начиная с работ того же Э.Дейкстры, которым весь этот subj, собственно, и создан...
На винде сокеты, действительно, никто для IPC не использует, это правда... Но это исключительно только потому, что на винде они "ни в п...." не годятся!
PE>Дотнет — это другая бинарность. Так можно и результаты компиляния жавы назвать бинарными.
Результаты компиляции Java называют "байт-код" ... всем миром ... но конечно для индивидуального использования (в сортире) его можно называть и бинарным...
PE>Потом появится и вся платформа.
Вообще, с "потом" у MS вообще происходит замечателый альянс:
— сначала Андриан Кинг ("Windows 95 изнутри"), Мэтт Питрек ("Секреты системного программирования в Windows 95"), Эндрю Шульман ("Неофициальная Windows 95") — всё мировые бестселлеры — даже с удивлением для себя (они то — лучшие друзья MS) находят в "защищённой 32-битной" системе огромные куски 16-бит кода... MS сконфуженно сознаются ... и говорят "потом"...
— потом обнаруживается, что DOS загрузчик Linux, запускаясь как рядовое пользовательское приложение ... вытесняет на-фиг "защищённую" систему и грузит Linux вместо неё... MS сконфуженно "строит глазки" ... и говорят "потом"...
— потом те же настырные А.Кинг, М. Питрек, Э.Шульман и другие "доброжилатели" (забава-то становится уже занимательной) ... находят "торчащие уши" 16-бит кода в Win98 ... но этого мало: всё тот же PSP от 16-бит формата EXE задачи... Какой позор ... MS говорят "потом"...
— потом в точности та же история повторяется с WinME ... MS говорят "потом"...
Что там — торчащие из WinXP "ослиные уши" 16-бит кода уже нашли?
PE>>>Не переносимостью единой будет сыт человек. Если в Беларуси 1000000 пользователей компьютеров и среди них только единицы процентов Линукс, то нахрен это нужно.
Да ... совсем плохо ... с Белорусией.
Но ничего — и их как всех ... попустит, н попозже...
V>>ладно, всё сдаюсь.. V>>Белорусский рынок пусть остаётся за MS..
... на некоторое время.
V>>>>Читай выше — даже .NET на 64 бита толком перенести не могут.. PE>>>Пока не могут. Никто же не говорил, что это сразу сделано будет.
Нет, конечно, это будет сделано ... "потом" ...
Правда Linux & QNX давно и без шума спокойно работают на 64-бит ... "вчера" ...
