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

SH>А чего тогда не на ассемблере? Люди же важнее! Действительно, найдём классных программеров, которые напишут нам Янус на асме.
Так, отставить демагогию
Ежу понятно что можно и на брейнфаке.

SH>Да, я опять преувеличиваю. Разница между C++ и C# меньше чем между C++ и ассемблером. Но тем не менее, есть что-то и в языках. И в библиотеках. Библиотеку для работы на асме с SOAP найти очень сложно. На C++ — довольно легко. Но на C# она входит в стандартный комплект — не надо ни искать, ни устанавливать.

Опять таки вопрос в качестве этих библиотек. Не так сложно найти библиотеку — сложно найти качественную библиотеку, которая делает всё, что необходимо проге.

SH>А так же в процессе поддержки, исправления ошибок и добавления фич. И всё это будет верно только если ты это "медленнее" замечаешь. И оно не теряется на фоне ещё более медленного чего-то там. И если переписать на C++ реально по трудоёмкости.
Блин, такое ощущение что программирование на С++ ассоциируется с суровой рукопашной с указателями, копипастом кода и т.п.
Чем так сложны поддержка, отладка и развитие нормально спроектированной и написанной С++ проги от С# проги? А то что то я как то не пойму про какое "медленнее" ты говоришь. В общем случае на С++ можно точно так же "лепить из кубиков" как и на шарпе. Если не брать общий случай то и там и там вылазят разного рода "особенности" которые в равной мере тормозят эти процессы и там и там.

SH>На питоне тоже можно писать интерактивные приложения. Они будут к тому же кроcсплатформенными и исходного кода будет меньше, чем на C++. Я вот недавно писал утилитку на Питоне. 3 месяца писал вдвоём с коллегой.

SH>Я не возьмусь повторить это на C++ в обозримые сроки — очень долго получится.
Теперь давай добавим побольше конкретики: чего именно тебе не хватает чтобы написать на С++.
Причем давай говорить конкретно — не хватает класса строк с блаблабла функционалом.

Как бы не оказалось что не хватает просто фреймворка.

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

CC>Теперь давай добавим побольше конкретики: чего именно тебе не хватает чтобы написать на С++.
CC>Причем давай говорить конкретно — не хватает класса строк с блаблабла функционалом.
CC>Как бы не оказалось что не хватает просто фреймворка.

Свободы
У кого-то в подписи было "ничто так не ограничивает свободу творчества программиста, как компилятор". Вот Питон ограничивает гораздо меньше.

Динамической типизации. А так же генераторов, итераторов и GC. И лямбд. И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта. Это так, навскидку.

Я не могу назвать что-то одно или исчерпывающий список. Я просто рекомендую тебе попробовать Питон.

Ты говорил про "правильно спроектированную библиотеку на C++". Фокус в том, что правильно спроектировать библиотеку на C++ сложнее. Хотя бы — тупой пример — какой класс строк должна использовать эта библиотека? Существует пяток различных, использовать в одном проекте несколько классов строк неудобно, переносимость библиотек падает, народ использует char*. Что тоже неудобно, но хотя бы переносимо.. Пока не всплывает юникод и прочий utf.

Причина — С++ слишком заботится о байтах. О машинном представлении. Даже если это скрыто внутри класса, это всегда приходится держать в уме. Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. И строчки там приличные.

Конечно, Питон работает на порядок медленнее. Зато писать на нём гораздо удобнее — пусть и не на порядок.

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

SH> Фокус в том, что правильно спроектировать библиотеку на C++ сложнее. ...
SH> Причина — С++ слишком заботится о байтах. О машинном представлении ...

Немного разверну.

В качестве "гарантированно переносимого" С++ предоставляет слишком низкоуровневые абстрации. Везде есть int, char, указатели. И, в общем, всё. Т.е., если библиотека хочет, чтобы её "понимали" все, она должна общаться с пользователем на языке, состоящем из int, char, указателей. Иначе это уже не просто библиотека, а, например, MFC-библиотека. Или ATL-библиотека. Или STL-библиотека. STL почти всем хороша, но её неудобно использовать из MFC-приложения..

Всё это усложняет совмещение нескольких библиотек, и/или фреймворков друг с другом. И написание "правильных" библиотек тоже усложняет.

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

CC>>>В C++ для передачи параметров ассемблерной вставке далеко не всегда надо бросать что либо в стек
SH>>Не всегда. Только когда оптимизатору не доступен весь проект. Например, если ты пишешь dll, lib или что-то подобное.
CC>Вызов в DLL гораздо дешевле вызова через COM
CC>lib же влинкуется в проект — оверхэд почти нулевой.
Вообще-то вызов COM-метода внутри apartment'а ничем не отличается от вызова обычной виртуальной функции.

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

IT>> Мне пофиг как оно там внутри работает. Оно работает, решает свою задачу с приемлемой для моих задач производительностью и мне этого достаточно.
CC>Плохо что тебе пофиг. Вот, сейчас ищем как ускорить большой проект, который писали такие же, которым пофиг. И когда проект на реальных данных через некоторое время стал работать кошмарно долго (часы) то
CC>Это скорее к качеству реализации библиотек. Потому как внутри сделано ИМХО через задницу.

У меня серьёзных притензий к качеству используемых мною библиотек нет. А когда они появляются, то я пишу свои, с приемлемым качеством и производительностью.

Но мы здесь не о том. Дворкин известный оптимизатор на пустом месте. Например, для решения задачи вычитывания строки из файла по номеру он начинает открывать map-файлы и наворачивать 25 строк кода там, где достаточно одной. При этом он обосновывает это тем, что это работает аж за 0.015 секунд на 12-ти мегабайтном файле. Но проблема в том, что размер файла для решаемой задачи никогда не превышает, скажем, 10-ти килобайт. И на этих объёмах скорости и с map-файлами и с File.ReadAllText() стремительно стремятся к нулю. Система даже тикнуть не успевает. Так зачем городить огород весь этот огород? Чтобы потом переться от собственной крутости? Было бы от чего. Map-файлы мы прощли ещё 10 лет назад, попёрлись малость от крутости и пошли дальше.

Оптимизация сродни сильнодействующему препарату. Это необходимо в исключительных ситуациях при угрозе жизни или выжимания максимум возможного из существующего. Но никто не есть аспирин или анаболики вместо хлеба и мяса. От этого можно умереть. И сколько приходилось видеть таких программ, умиращих от передозировки оптимизациями. Оптимизации раздувают код, делают его нечетабельным, плохопонемаемым и трудноподдерживаемым. Написать код чуть быстрее, запутав его до предела много ума не надо. Прочитал в книжке Рихтера про map-файлы и готово, лепи их куда попало, обосновывая это тем, что так всегда быстрее. Только зачем?

Есть такой правильный закон — закон Мейера — "Усложнять — просто, упрощать — сложно". Так вот в соответствии с ним наоптимизировать на ровном месте, всё на порядок усложнить и запутать — просто. Найти компромисс, а ещё лучше разумный отказ от бестолковой оптимизации гораздо и гораздо сложнее.

IT>> А вот то что я решаю это всё в одну строку — это огромный плюс, потому что строк у меня таких не одна, а десятки тысяч и увеличение объёма кода в 33 раза, как в твоём случае для меня неприемлемо. Я не из тех, кто любит хвастаться проектами в миллионы бестолковых строк.
CC>А что тебе мешает написать библиотеку для С++. Или просто класс-хелпер в проекте.

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

CC>Если поставить С# и С++ в одинаковое положение просто сравняв возможности библ, которые идут с ними "по умолчанию" то окажется что разница то между ними в колве кода совсем маленькая.

Если бабушке прикрутить два шара между ног, то она станет дедушкой. Нет, не станет. Сколько плюсам не прикручивай шары, дедушкой они не станут никогда.

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


S>что б те было спокойнее

S>

S>            using (FileStream fs = File.OpenRead("D:\\Пример2.txt"))
S>            {
S>                int read = 0;
S>                byte[] b = new byte[1024];
S>                while ((read = fs.Read(b, 0, b.Length)) > 0)
S>                {
S>                    string str = Encoding.Unicode.GetString(bytes, 0, read);
S>                    int len = str.Length;
S>                    Console.WriteLine(len);
S>                }
S>            } 
S>

PD>>И , кстати, маленький вопрос. Что здесь будет, если длина строки окажется больше 512 символов (1024 байт) ?

S>ниче не будет, программа просто отработает, без всяких ошибок ...

Это точно. Отработала. Дал на вход файл с одной текстовой строкой длиной 534 символа (длина файла 1070 байт). Вот что она печатает

512
23

Это, мягко выражаясь, несколько не соответствует действительности. Там все же одна строка, а не две. И к тому же лишний символ- 0xFEFF в начале эта программа почему-то включила в первую часть строки, хотя его надо было опознать как признак Юникодного файла и в строку не включать .



S>кстати че там у нас со скоростью?

Сначала сделай, чтобы программа работала, потом обсудим

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

CC>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Я тут не раз проводил голосование о том, сколько десктопных приложений на C# установлено на машине. У большинства — до 5 всего лишь.
CC>К примеру у меня кроме йануса можно только MSVC причислить — в нем части на дотнете...

У меня еще на сервере крутится GPMC — Group Policy Management Console. И тормозит.

Кстати, о MSVC. Я до сих пор с тоской вспоминаю MSVC 6.0. Тянул с переходом на новые версии до последнего, оставил ее когда уж совсем было нельзя. Она буквально летала на компьютерах 5-летней давности. А нынешняя только проект открывает 10-15 сек...

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

CC>Потребление ресурсов по мне так важно везде. Потому как если маленькая утилита хавает 30 метров private bytes — это просто не приемлемо. Для большой проги, которая делает много чего и является основной рабочей средой на компе — есть много и думать долго еще можно простить. Но для тула помельче, если к примеру это не АРМ а какой нить утиль типа офиса — потребление ресурсов должно быть оправданным — столько сколько реально необходимо. Потому как мы все пользуемся многозадачными ОС в которой может быть запущено много разных процессов. И когда каждый из них начинает жрать сколько ему вздумается — это уже бардак.

Подпишусь под каждым словом. Вот, кстати, классический пример.

У меня стоит триллиан (клиент ICQ). Вообще-то неплохой, я им доволен, но...

Вот сейчас посмотрел по Task Manager : MemUsage 13 Мб, VM Size 14 Мб.

Когда я впервые с ICQ познакомился, у меня на машине было не то 8, не то 16 Мб. И ICQ пейджер вполне нормально работал, жаль, не посмотрел тогда, сколько он памяти занимал. А пейджер, прямо скажем, остался тем же , каким и был и новых функций в режиме чата у него нет, потому что их быть не может. Все новое, что там появилось — замечательно, но это новое нужно один раз в неделю, вот пусть и сидело бы на диске и когда нужно — подгружалось. Извините, но больше 1 Мб памяти на пейджер я бы не дал — незачем просто.

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


IT>Но мы здесь не о том. Дворкин известный оптимизатор на пустом месте.

Уважаемый коллега, а нельзя ли обойтись в дискуссии без личных выпадов ? Применение подобной аргументации никого не красит.

Все остальные замечания оставляю без ответа, как и обещал.

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

Еще раз извиняюсь за вмешательство не в свой тред.

SH>Библиотеку для работы на асме с SOAP найти очень сложно. На C++ — довольно легко.

Классические библиотеки (как статические, так и DLL) не на асме и не на С++. Они были написаны на асме или С++ или на С++ с __asm, или вообще не знаю на чем. Но если они следуют стандартным соглашениям о связях при вызове функций, то использовать их можно хоть из асма, хоть из С++, хоть из Delphi, хоть из Фортрана (кстати, совсем недавно писал модуль стыковки Фортран — С, при том, что я никогда с Фортраном на IBM PC не работал).

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

PD>Классические библиотеки (как статические, так и DLL) не на асме и не на С++. Они были написаны на асме или С++ или на С++ с __asm, или вообще не знаю на чем. Но если они следуют стандартным соглашениям о связях при вызове функций, то использовать их можно хоть из асма, хоть из С++, хоть из Delphi, хоть из Фортрана (кстати, совсем недавно писал модуль стыковки Фортран — С, при том, что я никогда с Фортраном на IBM PC не работал).

Есть небольшая проблемка нет у C++ стандартного ABI, даже на одной платформе. Взять например Win, у разных компиляторов разное искажение имен и даже разная организация таблицы виртуальных классов. Тут только COM может помощь, но он обычно слишком тяжеловесен. Для Си ситуация чуть полегче можно добится совместимости, но и то вылазят иногда тонкости.

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

Внесу предложение на Яве.

    public static void testReader() throws IOException {
        long t = System.currentTimeMillis();
        RandomAccessFile file = null;
        int lineCount = 0;
        try {
            file = new RandomAccessFile("c:\\_\\example.txt", "r");
            final FileChannel channel = file.getChannel();
            final long fl = file.length();
            final CharBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, 0, fl).asCharBuffer();
            for (int i = 2; i < (fl - 3) >> 1; i++)
            {
                if (buffer.get(i) == 0x0D00)
                    lineCount++;
            }
        } finally {
            if (file != null)
                file.close();
        }
        t = System.currentTimeMillis() - t;
        System.out.println(String.format("Time elapsed: %f sec", (float) t / 1000.0));
        System.out.println("Line count = " + lineCount);
    }

Время прошу отмасштабировать к Вашему размеру файла (У меня файл чуть побольше получился). Получилась разница уже в 4 раза.

Time elapsed: 0,063000 sec
Line count = 767555

Кстати, по поводу вопросов к сложности библиотек IO в Яве.
Во-первых, для того, чтобы вывести что-то в консоль, достаточно открыть любой пример программы на Яве для чайников. Там русским по белому написано:

System.out.println("Something to console!");

Никакого знания классов и в помине не нужно.

Что касается набора классов в библиотеке — то его цель следующая: отделить работу с символами или байтами (например, форматирование их в указанной локали) от операций ввода-вывода. А не как в stdlib: printf, fprintf, sprintf, wprintf, ... Которые, что самое смешное, все равно вызывают внутри себя одну и ту же функцию обработки форматной строки и списка параметров.

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

K>Ну дык. Думаю, тот же IT делает анализ применимости. Вася Пупкин, который полгода назад открыл для себя способ рисовать формочки в Делфях такого анализа не делает. Но внимание! Вася Пупкин и в C++ и STL наворотит такого (свинья везде грязь найдёт). Ну так вот: ради профессионалов вроде IT и проектируются фреймворки, чтобы они могли меньше времени тратить на вещи, которые не критичны (предполагается, что как специалисты, они могут выделить такие ситуации). Что же до ВП — всем пофигу, т.к. ВП спасёт не супермощный фреймворк, а супеполезные книжки.

Мля.... А кто такой профессионал? Это тот же Вася Пупкин в прошлом! Профессионалом он начнет становится когда САМ (я еще раз говорю — САМ!) начнем смотрет по сторонам и думать. Когда глядя на свой код он скажет: "А вот здесь можно сделать вот так и это будет гораздо лучше, потому что....".
А что касается преподаваталей, которые дают втык студентов — видел я за пять лет парочку таких МУДАКОВ (и я от этого определения не откажусь!).
Проблема нашей системы образования в том, что она абсолютно не подталкивает Пупкиных к таким выводам — она подталкивает их получиением росписей в зачетке (впрочем это недостаток всех формальных систем — подмена сути), но на самом деле проблема еще хуже — наша система образования (в ее реальном текущем состоянии) НЕ СПОСОБНА проконтролировать качество обучения: максимум что можно проконтролировать на сессии это тупое заучивание материала.

Результат виден когда человек приходит работать — учиться он УЖЕ не умеет (чтобы там не говорили, про "учим учиться"), дейсвтительно, а за чем? У него уже есть диплом (то есть бумажка), зато они замечтально могут поддакивать и смотреть умными глазами.

Кто-то из уважаемых преподавателей приводил пример с классом комплексных чисел — вы наивно думаете, что если студент правильно вам ответит, то он все понял и знает.... Какая наивность — понимать он начнем только тогда когда набьет себе шишек (и будет так или иначе набивать их всю жизнь), а этом он сделает (если конечно захочет) и без вашей сиятельной персоны. По собственному опыту объяснения Пупкиным (хотя я вообще не преподаватель, у меня даже образование с IT не связано, к тому же я в основном объяснял прекрасной половине челевечества, которая обучалась на соотвествующих специальностях) могу сказать, что самый лучший способ это свободное обсуждение того что было написано c попытками подтолкнуть к желанию что-то улучшить — без втыков, без репрессивных мер и без немерянного самомнения (я препод — ты дурак) — поверьте мне, где-нибудь на нашем голубом шарике есть спецы по сравнению с которыми почти любой препод (а тем более в нашей стране и по IT'шной специальности) — ПОЛНЫЙ ЛОХ. Будьте проще! Если пытаться объянсять таким образом сначла будет дикое непонимание, зато потом человек начинает понимать, что ты просто справочник и со своим кодом он может экспериментировать как хочет (и что самое главное ему за то НИЧЕГО не будет) — это тот путь превращаения Пупкиных который прошел я.

Теперь по поводу жабы — абсолютно все равно какой язык изучать (кроме брейнфака, хотя он замечательно иллюстрирует машину тьюринга в самом примитивном виде). Я напимер, читая SICP, многие примеры делал на Scala.

P.S. Я как раз типичный представитель семйства Пупкиных. Мой путь: Pascal(1 год), ASM(1 год)->C(3 года)/C++(1 год), Perl(3 года)->Java(3 года, и по сей день), Scala(1 год, и по сей день), Haskell(только начал), C#/Nemerle(если будет время), 1C (придется, провинция...). И ниче! И книжку по конечным автоматам сам себе купил, и по антипаттернам, и по проектированию, и SICP щас по второму разу читать буду. И заметьте — я сэкономил огромное количество нервов на общении с разного рода му... А вот бумажки по IT'шной специальности у меня нет и уже не будет (см. выше про сэкономленные нервы).

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

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

CC>>>>В C++ для передачи параметров ассемблерной вставке далеко не всегда надо бросать что либо в стек
SH>>>Не всегда. Только когда оптимизатору не доступен весь проект. Например, если ты пишешь dll, lib или что-то подобное.
CC>>Вызов в DLL гораздо дешевле вызова через COM
CC>>lib же влинкуется в проект — оверхэд почти нулевой.

SC>Вообще-то вызов COM-метода внутри apartment'а ничем не отличается от вызова обычной виртуальной функции.
Вызов COM метода из managed кода == вызову виртуальной функции?
Мы про юзание асм кода из управляемого кода говорим.

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

PD>Кстати, о MSVC. Я до сих пор с тоской вспоминаю MSVC 6.0.
Аналогично.

PD> Тянул с переходом на новые версии до последнего, оставил ее когда уж совсем было нельзя.
Я сейчас так тяну с 2003-й. Благо компилер юзаю интеловский — его отдельно от вижуалки можно обновлять. Я то и с 6.0 слез только когда интел ее поддерживать перестал.
Вот с ужасом жду когда 2003ю перестанут

PD> Она буквально летала на компьютерах 5-летней давности. А нынешняя только проект открывает 10-15 сек...
А то и дольше...

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

SH>Свободы
SH>У кого-то в подписи было "ничто так не ограничивает свободу творчества программиста, как компилятор". Вот Питон ограничивает гораздо меньше.
Слишком абстрактно

SH>Динамической типизации.
Для чего?

SH>А так же генераторов
см http://en.wikipedia.org/wiki/Generator_%28computer_science%29 раздел С++

SH> итераторов
Уже есть в плюсах

SH> и GC.
GC — зло в общем случае. + плохо сочетается с ручным управлением памятью.

SH>И лямбд.
Ну, вот чего нет так нет
Насколько я понимаю, без GC они кривовато реализуются...

SH>И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта.
ИМХО реализуемо и в С++. Разумеется не так прозрачно
SH> Это так, навскидку.

SH>Я не могу назвать что-то одно или исчерпывающий список. Я просто рекомендую тебе попробовать Питон.
Пробовал. Дописывал функционал в готовой проге когда то давно... В проекте часть функционала вынесена в питоновские скрипты. Причем солидный такой кусок.
Что могу сказать — скриптовый язык он и есть скриптовый...

SH>Ты говорил про "правильно спроектированную библиотеку на C++". Фокус в том, что правильно спроектировать библиотеку на C++ сложнее.
Никто не говорил что будет легко.

SH> Хотя бы — тупой пример — какой класс строк должна использовать эта библиотека?
std::wstring

SH> Существует пяток различных, использовать в одном проекте несколько классов строк неудобно, переносимость библиотек падает, народ использует char*. Что тоже неудобно, но хотя бы переносимо.. Пока не всплывает юникод и прочий utf.
про ANSI строки я уже давно забыл. впрочем если надо — std::string

SH>Причина — С++ слишком заботится о байтах. О машинном представлении. Даже если это скрыто внутри класса, это всегда приходится держать в уме.
Т.е. думать надо о том, что получится перед тем как писать?

SH>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется.
угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить?

SH> И строчки там приличные.
В чем приличие?

SH>Конечно, Питон работает на порядок медленнее.
Боюсь в общем случае все таки больше чем на один порядок.

SH>Зато писать на нём гораздо удобнее — пусть и не на порядок.
Смотря что писать. Наблюдал как то библиотеку длинной арифметики с RSA написанную на скриптовом языке (уже толком не помню на каком) — обнять и плакать...
Мелочь писать на нем и всякие управляющие скрипты — можно. То, что не требует особой скорости — тоже. Но блин, почему как только человек открывает для себя новый язык он тут же стремится писать на нем все подряд?!

Ладно, господа. Меня тут уже обвинили в том, что я оптимизацией на пустом месте занимаюсь. Я как раз именно сейчас ей и занимаюсь — а вот на пустом месте или нет — предлагаю оценить, и если кто может, помочь.

Программа на Яве.

Программа делает вот что. Есть пары машин, которые гонят друг другу TCP трафик (в действительности сообщения некоторого протокола уровня приложения, протокол мне известен). На моей машине сидит сниффер, который этот трафик ловит, восстанавливает эти "сообщения" и пишет их в БД. Как он восстанавливает — несущественно сейчас.

2 потока, один ловит трафик, восстанавливает и пишет в очередь. Другой из очереди берет и в БД пишет.В качестве очереди использовал java.util.concurrent.LinkedBlockingQueue.

Про первый поток речи не будет, разговор пойдет о втором.

Вопрос — будет это тормозить или нет. Запустил профайлер.

Сделал две пары обменивающихся машин. YourKit Profiler утверждает , что на LinkedBlockingQueue.poll (взятие из очереди) уходит 16% суммарного времени (или 57% времени потока) при том, что на запись в БД — 12% (или 43% времени потока), итого 28% от общего времени . При одной паре машин на LinkedBlockingQueue.poll уходит в 2 раза меньше.

Это мне совсем не понравилось. Если так дальше пойдет, то и до 100% недалеко. В реальной обстановке таких пар машин будет много.

Запустил на всякий случай другой профайлер — JProfiler. Этот утверждает, что на поток записи вообще уходит всего лишь 5% от общего времени, про LinkedBlockingQueue.poll молчит как партизан, по-видимому, оценив затраты времени его как пренебрежимо малые, зато про запись в БД говорит, что на него уходит половина от этих 5%, а вторая половина — на мой код, о котором в свою очередь YourKit Profiler выдал 0.0%

Кому верить и что делать ?

Полез в имплементацию LinkedBlockingQueue.poll. Все, как положено, запутано до предела (черт возьми, умеют же писать сложным способом простые вещи). С десяток классов, интерфейсы, какие-то псевдобесконечные циклы. Долго ковырялся, и , в общем, без толка, понял лишь, что в конечном счете для блокировки вызывается

Unsafe java.util.concurrent.locks.AbstractQueuedSynchronizer.unsafe
Setup to support compareAndSet. We need to natively implement this here

Вот теперь сижу и думаю. Виновен этот LinkedBlockingQueue.poll или ни в чем не виновен ? Был бы C++ — послал бы этот LinkedBlockingQueue в RecycledBin, взял бы очередь из STL (а скорее всего и ее бы не стал брать, у меня своя реализация есть, примитивна, как лапоть), окружил бы все это Enter/LeaveCriticalSection и перестал бы об этом думать, зная. что быстрее под Windows невозможно.

Хоть свой собственный профайлер пиши...

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

PD>> Она буквально летала на компьютерах 5-летней давности. А нынешняя только проект открывает 10-15 сек...
CC>А то и дольше...

Меня тут sndanil свои вариантом чтения из файла донимает, все надеется 0.015 сек получить, пока что работать не хочет. Ну вот я проект и создал на шарпе, консольное шарп приложение с одним .cs файлом из 30 строчек. Его и открываю 10-15 сек

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

FR>Есть небольшая проблемка нет у C++ стандартного ABI, даже на одной платформе. Взять например Win, у разных компиляторов разное искажение имен и даже разная организация таблицы виртуальных классов. Тут только COM может помощь, но он обычно слишком тяжеловесен. Для Си ситуация чуть полегче можно добится совместимости, но и то вылазят иногда тонкости.

Да, верно. Увы. К сожалению (моему по крайней мере) это не было внесено в стандарт. Я ожнажды пытался скрестить классы от Borland C++ с программой на MSVC. Больше не буду

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

PD>Сделал две пары обменивающихся машин. YourKit Profiler утверждает , что на LinkedBlockingQueue.poll (взятие из очереди) уходит 16% суммарного времени (или 57% времени потока) при том, что на запись в БД — 12% (или 43% времени потока), итого 28% от общего времени . При одной паре машин на LinkedBlockingQueue.poll уходит в 2 раза меньше.

PD>Это мне совсем не понравилось. Если так дальше пойдет, то и до 100% недалеко. В реальной обстановке таких пар машин будет много.

Ну то, что при росте траффика до 100% от одного процессора доберетесь — это, думаю, очевидно. Ну это лирика.
Какой процент от общего времени уходит на поток записи — это тоже лирика. Кстати, кто мешает сделать несколько потоков записи?
А вот про одну пару машин ничего не ясно. Можете привести такие же 4 цифры, какие приводили для двух пар машин? Тогда и станет ясно, где узкое место с ростом траффика будет.