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

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

Нет уж, увольте ... даже если это такой прелестный FORTRAN как MS & Visual... :D

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

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

Ничего не "умирает" — там, где это уместно, это — нужно,
что происходит там ... "под вынь" — мне неинтересно, не знаю,
но на вынь, и даже на Intel x86 — свет клином не сошёлся ... и в этом
"свете" есть место всему, и ассемблеру, в частности.

O>>- один и тот-же код, компилированный (с максимальными оптимизациями) VC 6.0 & Borland Builder 5.2 отличаются по производительности в 3 (!!!) раза (в пользу VC);
O>>- и тот же код, компилированный GCC 2.95.X выигрывает у VC 6.0 — в 1.5 раза...

PE>Ну не надо такой дезы. Посмотри результаты тестирования на этом сайте.

В отношении "дезы": мне неинтересно что тестировали "на этом сайте", я даже не знаю, понимает ли кто в тестировании ... "на этом сайте": методики, программа тестирования etc. — прсто цифири посмотреть — это ещё не тестирование... Но это и не важно — У МЕНЯ, НА МОЁМ классе задач (DSP) — получены именно эти цифры, а я своим рукам верю больше, чем не только "этому сайту" ... но и всем сайтам взятым вместе! На других классах задач могут быть совсем другие результаты — кто понимает в "тестировании", тот и меня поймёт.


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

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

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

Нет, и ещё раз — "нет".

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

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

Какое эти алгоритмы имеют отношение к "серверам"?

PE>На особо быстродействующих серверах никто не форкает.

Вот "особо быстродействующий" сервер Apache именно так и делает...

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

А по части thread на обслуживании (вместо fork) — так там своих новых проблемм, покруче прежних будет ... это только в предисловиях к учебникам "используется поточность"...

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

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

Может быть и поэтому... Не интересуюсь.

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

ВСЕ. Я уже писал. Это — общеизвестные (в мире TCP/IP) вещи. Не место эти вещи детально расписывать в форумном трёпе... Примите на веру!

PE>Эта система нужны быда для совместимости со старой 3.11

Да? А все сочли — что по неспособности ... и спешке.

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

Я не "думаю", я знаю — WinNT 32-разрядная система, вся, но ... (!) потому ЧТО ДЕЛАЛАСЬ С НАЧАЛА ДО КОНЦА другими руками: DEC группа системных разработчиков VAX/VMS.

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

Когда? С какой системы — "имя в студию"!?

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

Для работы 16-разрядных приложений АБСОЛЮТНО необязательно иметь 16-разрядный код в ядре! Это всё оправдательная и рекламная болтовня MS.

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

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

OS/2 — это что ... тоже Microsoft? Или это Windows ... В контексте темы...?

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

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

"На базе..." — это что, из рекламных листков MS?
XP никак не является логическим продолжением линейки 3.51 — 4.0 — 2000.

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

Пусть даже так ... и сколько лет пришлось обездоленным юзерам (о которых у вас так сердце кровью обливается) ждать ЧЕСТНЫХ 32-бит, постулированных как данность в 1995-м? 7 лет? ... 8 лет?... а если из XP полезут 16-разрядные уши?

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

Да я, в общем, никого и ничего не боюсь... Отбоялся уже.
Но было-бы приятно... (не 64-бит, а вот это "издыхать": "собаке собачья смерть"(с)).