Re[7]: Интенсивные расчёты на С, а остальное на Яве? Нет, не - Компьютерные священные войны

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

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

N>Занимается, занимается. В частности, на этом примере мне надо было распознавать текст на видео. Я нашёл библиотеки для разных классификаторов, все обучил, выбрал наиболее подходящий мне по точности работы. А потом допилил его до предъявляемых требований по быстродействию. И такой пример в моей практике не один. Всё обыденно.
Распознавание текста делается другими средствами гораздо быстрее и проще.
Например надергал бы символов с обучающих выборок, а потом тупо сопоставлял бы их с символами на видео. Процент угадывания около 100 и не зависит от эзотерических факторов, как в нейронных сетях.

N>Я надеюсь, ты понимаешь, что в этом топике обсуждаются тяжёлые вычислительные задачи. Для них быстродействие и оптимизация — это будни программистов.
Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.

N>Так что жду ответа по профайлеру.
По профайлеру ниче не скажу, ты ошибся уровнем выше. Выбрал совсем не тот алгоритм.

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

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

G>>А ты что использовал?

N>Свёрточные нейросети. Распознавать надо было всевозможный текст на вагонах и цистернах. А он пишется разными шрифтами, криво, разного размера, разным цветом краски, зачастую затёрт, размазан, залит нефтью, всегда разная освещённость, различные погодные условия, разные камеры, сферическая дисторсия, шум от кодека и т.п. и т.д. Поэтому однозначно был нужен классификатор, способный обобщать знания, а не привязываться к конкретному шрифту и конкретным символам.
Обучающая выборка это уже конкретные символы и конкретные шрифты.

I>>>>>А когда все это уже есть, что дальше надо делать ?
G>>>>Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.
N>>>Ты не поверишь, но пользователям пофиг на правильную архитектуру и правильные алгоритмы. Им надо, чтобы не тормозило.
G>>Да ты че? И как коррелирует пользовательское "не тормозило" и время работы?

N>Нафиг GUI.
GUI это единственное что видит пользователь. И единственное по чему он может сделать оценку что "не тормозит".

N>Если конкуренты способны анализировать 16 видеоканалов 25 кадров в секунду, а ты только 8 — это отстой.
А если пользователям только два надо, но вполне нормально.

N>Если ты тоже 16, но видео хоть иногда притормаживат — это отстой. Если увеличить разрешение кадра вдвое, то площадь его увеличится вчетверо; остаётся 4 видеоканала — отстой. Сейчас с появлением сетевых мегапиксельных видеокамер аналитика в глубокой Ж: надо декодировать кадр, проанализировать и вывести на экран. На больших объектах по 200 камер, даже мощных процессоров не хватает. Или ставить кучу серверов, или мало но по полмиллиона рублей каждый, или пользоваться встроенной в камеры видеоаналитикой (а она отстой). А кто-то вообще хочет всё это запускать на бюджетный компах: Atom + встроенное интеловское видео. Как ни крути — оптимизировать надо.
Поставил проц с удвоенным ко-вом ядер, увеличил вдвое память и уже не отстой. А это только малая часть твоей ЗП за месяц. Или ты бесплатно оптимизировать будешь?

N>Я уже не говорю про по-настоящему большие задачи, для которых кластеры собирают. Там лишний десяток процентов производительности будет очень быстро окуплен той же электроэнергией.
И много ты таких видел?

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

N>Это практически идеальный и радостный случай: нашли бутылочное горлышко и давай его расширять. Настоящие проблемы начинаются, когда программа работает медленно, а горлышка-то и нет. Самая медленная функция отжирает процентов 7-8 общего времени. Вот и приходится лазать по всей программе с низкоуровневыми оптимизациями. Такой сценарий как раз очень характерен для больших и сложных систем.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

За что мы, сишники, так не угодили джавистам ? Что мы им сделали ?
Вот у меня, например, компилятор С++, который генерирует самый быстрый для платформы Intel код.
И что ? Сижу тихо, молчу в тряпочку...

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

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

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

A>>Суперпроизводительные шахматные программы теперь нужны только нердам, вроде тебя.

M>Просто пример интенсивных расчетов.
Знаем мы ваши расчеты. Из всех сложностей только битовые операции, которые многими платформами не поддерживаются. Ибо универсальность.

M>Вообще, лично мне такие задачи очень некомфортно решать в терминах Java и других управляемых языков. Ибо вся задача у меня сводится к такому: у меня есть 1 Gb памяти. Например, получен с внешнего устройства (несжатое видео). Его надо обработать. И в терминах указателей это делать оказывается очень удобно.

Весь гиг разом ты обрабатывать не будешь, будешь это делать по кадрам. Сам по себе в памяти этот гиг не появится, его нужно будет прочитать из внешнего устройства (даже тупо с диска).

Вот тут управляемые платформы помогут тебе организовать асинхронное чтение и параллельную обработку данных, тогда у тебя и не будет ограничения на объем данных. На C\C++ такое писать в разы геморройнее.

N>Для свёрточных нейросетей признаки — это само изображение (яркость). Для Adaboost прогонял классификатором из OpenCV, не смотрел сколько там признаков.

Парни, здесь серьёзный форум и люди приходят сюда ~~посраться~~ обсудить тенденции в ИТ и их влияние на нашу жизнь. Шли бы вы со своими нейросетями в "Алгоритмы"

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

G>А ты что использовал?

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

I>>>>А когда все это уже есть, что дальше надо делать ?
G>>>Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.
N>>Ты не поверишь, но пользователям пофиг на правильную архитектуру и правильные алгоритмы. Им надо, чтобы не тормозило.
G>Да ты че? И как коррелирует пользовательское "не тормозило" и время работы?

Нафиг GUI. Если конкуренты способны анализировать 16 видеоканалов 25 кадров в секунду, а ты только 8 — это отстой. Если ты тоже 16, но видео хоть иногда притормаживат — это отстой. Если увеличить разрешение кадра вдвое, то площадь его увеличится вчетверо; остаётся 4 видеоканала — отстой. Сейчас с появлением сетевых мегапиксельных видеокамер аналитика в глубокой Ж: надо декодировать кадр, проанализировать и вывести на экран. На больших объектах по 200 камер, даже мощных процессоров не хватает. Или ставить кучу серверов, или мало но по полмиллиона рублей каждый, или пользоваться встроенной в камеры видеоаналитикой (а она отстой). А кто-то вообще хочет всё это запускать на бюджетный компах: Atom + встроенное интеловское видео. Как ни крути — оптимизировать надо.

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

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

G>Вот тут управляемые платформы помогут тебе организовать асинхронное чтение и параллельную обработку данных, тогда у тебя и не будет ограничения на объем данных. На C\C++ такое писать в разы геморройнее.
С чего бы вдруг?
Писал подобное, в асинхронке, что то геморроя не заметил.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>Ошибаюсь, но нахожу и исправляю ошибки. Самое коварные из них, это ошибке в алгоритме. Когда ты разработал и реализовал алгоритм, он работает как надо. Но при разработке ты не учел один нюанс, который все портит. Если бы тут Java помогала

Как раз на Яве можно писать алгоритм, а на С++ начинают алгоритм смешивать с битовой и тактовой оптимизацией, из-за чего поддерживать потом будет не просто.

M>Ну а в целом, как будет выглядеть в Java такое?

Да так же и будет, только вместо unsigned char* line будет byte [].

Хотя, конечно, тут ещё надо помнить, что в Яве нет unsigned и надо кастовать к инту

acc += = (0x000000FF & ((int)line[i]));

Но ЖИТ этот шлак соптимизирует ( я надеюсь)

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

O>За что мы, сишники, так не угодили джавистам ? Что мы им сделали ?
O>Вот у меня, например, компилятор С++, который генерирует самый быстрый для платформы Intel код.
O>И что ? Сижу тихо, молчу в тряпочку...

А у них его нет, вот им и завидно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>>Распознавание текста делается другими средствами гораздо быстрее и проще.
G>>Например надергал бы символов с обучающих выборок, а потом тупо сопоставлял бы их с символами на видео. Процент угадывания около 100 и не зависит от эзотерических факторов, как в нейронных сетях.

I>Если есть точно такие же, то может и 100, а если другого размера, наклонены, повернуты, замазаны и тд и тд и тд и тд — сильно вряд ли.
Тогда и нейронные сети не справятся

А вообще начинай курить отсюда: http://bik-top.livejournal.com/37060.html
Капчи так и ломают.

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

G>>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
G>>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.
I>А когда все это уже есть, что дальше надо делать ?
Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.

HA>Конечно, именно из С++ и пришел такой подход

Честно говоря, 90% использования потоков в С++ — это описание их возможностей в учебниках, а остальные 10% — это вывод в файловый лог. И только в Яве потоки используются на полную катушку.

http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

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

A>Я понимаю, что конкретно тебя это не касается, потому что ты никогда ~~не пьянеешь~~ не ошибаешься, но есть и другие программисты, поплоше

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

А те ошибки, от которых страхует Java, мне не кажутся критическими.

Ну а в целом, как будет выглядеть в Java такое?

uint32_t process_line(unsigned char* line, size_t line_len)
{
  uint32_t acc;
  for(size_t i=0; i<line_len; ++i)
    acc += line[i];
  return acc;
}

unsigned char* data;
process_line(data + offset, some_value);

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

O>>За что мы, сишники, так не угодили джавистам ? Что мы им сделали ?

PD>Все очень просто. Чистая психология. Нувориши всегда завидуют аристократам. И больше всего хотят в глубине своей души — чтообы аристократы их признали равными себе. А те не только равными не признают, но и вообще не воспринимают как равных. Вот это нуворишей и бесит.

Известная фабула — нищие но гордые аристократы желают порододниться с безродными но богатми нуворишами которые в свою очередь хотят заполучить титул за деньги.

Так бывает в жизни. А в ИТ это примерно так — набежали молодые волки и порвали-сожрали всё стадо породистых баранов

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

PD>Все очень просто. Чистая психология. Нувориши всегда завидуют аристократам. И больше всего хотят в глубине своей души — чтообы аристократы их признали равными себе. А те не только равными не признают, но и вообще не воспринимают как равных. Вот это нуворишей и бесит.
Какие феерические комплексы...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Интенсивные расчеты уже лет 5 как массово считаются на GPU.

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

A>>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html
R>Интенсивные расчеты уже лет 5 как массово считаются на GPU.
Ну не пять и не массово.
Более менее серьёзные SDK для масс появились года два назад.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

N>Но мне пришлось перелопатить практически весь код, навводить кучу typedef, оттюнинговать практически все циклы в программе.

Чувак, если бы разработчки этой х-рнёй занимались во время разработки библиотеки, то её могло вообще не случиться, было бы быстрое глючное гуано, на доводку которого пожалели бы тратить время.

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

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Кажется вам под душ , сюда
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Жду сильный шахматный движок на Java

A>>Суперпроизводительные шахматные программы теперь нужны только нердам, вроде тебя.

M>Просто пример интенсивных расчетов. Ок, из игр можно взять го. Сеги в крайнем случае.
M>Вообще, лично мне такие задачи очень некомфортно решать в терминах Java и других управляемых языков.
Если задача типовая, то для Java и управляемых языков зачастую можно найти библиотеки, которых нет на си. скажем, я сам столкнулся, что для решения моих задач есть библиотеки на Java и даже Питоне с Руби, которые делают все, что нужно, а на Си и плюсах -- их нету и там это только предстоит написать.

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

A>На середину не выйдет, а оно так уж надо? Создай класс с массивом и текущим смещением, и таскай его за собой.

A>

A>public class Buffer {
A> byte [] buffer;
A> int offset;
A>}
A>

Лишний код, лишние ошибки. Лишняя головная боль оптимизатору. Лишние проверки при индексации.

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

I>>В Го переборы не работают, т.к. вычислительная сложность несравнимо выше чем в шахматной.
I>>Потому основной метод усиления это всякие монте-карликовые симуляции. Здесь не надо ссылок друг на друга, колец и тд.

M>Если играть с компом, то компьютер как раз превосходит игрока в вычислительном плане.

Да нихрена он не превосходит

>Монте-Карло это больше стратегическая симуляция. А считать жизнь/смерть группы все равно на отдельном участке все равно надо. И смотря на партию 9p против компа на 9 камнях форы как раз видно, что человек пару раз просчитался в определении жизни/смерти (считал, что ход сенте против черной группы, а оказалось, что это готэ).

Не умеет комп вычислять жызнь и смэрть

I>>Не такой там и бюджет большой, что бы переписывать с нуля достаточно сложную программу.
M>Взять какой-нить IvanHoe за основу и тупо перевести на Java? Там не так уж много кода

Было бы желание.

А что из этого получится ?

Тупой перевод нативного кода в менеджед еще никогда не давал хороших результатов

Менеджед ценен тем что можно высокоуровневые оптимизации забабахать просто на раз — взял и готово.

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

E__>Оптимизировать нужно, но только тогда, когда понимаешь, что вот этот кусок кода работает часто и отжирает 99% ресурсов, и этих ресурсов не хватает.

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

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

N>>Но мне пришлось перелопатить практически весь код, навводить кучу typedef, оттюнинговать практически все циклы в программе.

A>Чувак, если бы разработчки этой х-рнёй занимались во время разработки библиотеки, то её могло вообще не случиться, было бы быстрое глючное гуано, на доводку которого пожалели бы тратить время.

Возможно. Но моя мысль была немного о другом: С++ позволяет быстро писать как в довольно высокоуровневом стиле, так и проводить самые низкоуровневые оптимизации. С Java такого уже не получится.
Тоже самое с другим фронтом высокопроизводительных вычислений — GPGPU. К той же CUDA есть обёртки на разных языках, не только родной кудовский С/С++. Но как на этиз языках оптимизировать? Скажем, ядро использует 18 регистров, а надо не больше 16-ти. Тут уже без всякого рода низкоуровневого шаманства не обойтись.
ИМХО, язык должен позволять работать на разных уровнях абстракции: и вверх, и вниз.

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

A>Ну и мой первый пост был о другом — интенсинвные вычисления можно и уже делают на Яве.
Да хоть на PHP — см серверную часть BOINC (seti@home и ко).

Главное — чтобы руки были.

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

M>>Ну так я получаю от драйвера указатель на память. Которую затем надо обработать. Драйвером я не занимался.
A>Твой аргуменнт "всегда надо на С, потому что у нас есть драйвер, с которым нельзя взаимодействовать из Явы"

Почему нельзя? Все можно. Но это лишняя работа.

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

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

G>>Вот тут управляемые платформы помогут тебе организовать асинхронное чтение и параллельную обработку данных, тогда у тебя и не будет ограничения на объем данных. На C\C++ такое писать в разы геморройнее.
CC>С чего бы вдруг?
CC>Писал подобное, в асинхронке, что то геморроя не заметил.
Ну если взять C# async за образец безгеморройной асинронной работы, то что есть в C++ аналогичного?

ЗЫ. Ты снова не показатель. Большинство программистов C++ не осилят асинхронное чтение из файла.

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

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

O>>За что мы, сишники, так не угодили джавистам ? Что мы им сделали ?

PD>Все очень просто. Чистая психология. Нувориши всегда завидуют аристократам. И больше всего хотят в глубине своей души — чтообы аристократы их признали равными себе. А те не только равными не признают, но и вообще не воспринимают как равных. Вот это нуворишей и бесит.

Есть такой анекдот: 2 манагера в курилке:
— Джонни, ты такой рафинированный интеллигент, с тобой на приемах даже здоровается английская королева, что надо сделать, чтобы стать таким же?
— Надо закончить Кембридж.
— Так я же закончил?
— Не тебе, дурак, а твоему дедушке.

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

G>Распознавание текста делается другими средствами гораздо быстрее и проще.
G>Например надергал бы символов с обучающих выборок, а потом тупо сопоставлял бы их с символами на видео. Процент угадывания около 100 и не зависит от эзотерических факторов, как в нейронных сетях.

Ага, конечно. Отличный алгоритм! А мужики-то не знают.

G>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
G>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.

Ты прикинь, бывают в жизни случаи, когда надо! А ты не знал?

G>По профайлеру ниче не скажу, ты ошибся уровнем выше. Выбрал совсем не тот алгоритм.

Слив засчитан.

PD>Все очень просто. Чистая психология. Нувориши всегда завидуют аристократам. И больше всего хотят в глубине своей души — чтообы аристократы их признали равными себе. А те не только равными не признают, но и вообще не воспринимают как равных. Вот это нуворишей и бесит.

Хороший пример нам передёргивание понятий

Может, объяснишь, каким образом осуществляется классификация С++-аристократы, Ява-нувориши? Почему не наоборот? Или почему не Лисп-аристократы, С++/Ява — нувориши?

Если твои выводы нельзя перепроверить (научный метод, ага), то они являются чепухой на постном масле. Или ты думал, что ты тут перед студентами выступаешь, которые в любой твой бред поверят и перескажут, чтобы зачёт получить?

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

A>Если твои выводы нельзя перепроверить (научный метод, ага), то они являются чепухой на постном масле. Или ты думал, что ты тут перед студентами выступаешь, которые в любой твой бред поверят и перескажут, чтобы зачёт получить?

Когда у человека нет чувства юмора — это надолго.

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

I>>Судя по твоим 100% ты про разспознавание знаешь по таким вот букварям.
G>Ты видимо вообще не знаешь. Зачем тогда пишешь?

I>>Такой подход как раз дает низкий процент угадывания.
G>Ага, 0.9

0.9 да на определенной капче — это и не смешно.

I>>Сам подумай — поменял чуток капчу и ломалки капчи отваливаются

G>А думаешь нейронные сети сами угадают? Их тоже переобучать надо, так и алгоритм на основе сравнения изображений тоже "обучать" нужно. Только в нейронных сетях ты понятия не имеешь что и как она определяет.

Я тебе ссылку давал, сходил бы та просветился.

I>>Представь — было бы 100%, как ты выдумал, капча вообще работать не будет

Ты думаешь есть алгоритм, способный взомать произвольную капчу?
G>Пишется код для слома определенной капчи.

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

Потому может используется нейронная сеть, например, как классификатор

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

I> I>> Это значит, что разница как раз в порядок

I> H>Ничего подобного. Можно писать код с указателями, читать который будет так же просто, как обычный. Сайд-эффекты штука конечно малоприятная, но на порядок не тянет никак.

I> Это когда ты освоил все эти техники и поварился в этом хотя бы пару лет, то только в этом случае читать будет просто.

Так для низкоуровневых оптимизаций вообще подготовка требуется

avalon 1.0rc3 rev 368, zlib 1.2.3

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

R>Интенсивные расчеты уже лет 5 как массово считаются на GPU.

За всех-то говорить не стоит. Надо хотя бы дописать "причем только те из них, которые допускают распараллеливание".
И немного подумав,
"причем распараллеливание под GPU, с характерными существенными ограничениями."

HA>2 переменных всегда лучше, чем одна?

Чувак, нельзя обойтись одной переменной там, где требуется две.

Если у тебя есть буфер и смещение внутри него, то это ВСЕГДА две переменные. То, что в ф-цию передаётся только одна из них, не значит, что второй не существует.

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

B>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

A>ИЛ-2-Штурмовик в своё время написали

Там вроде для рендеринга и отрисовки С++ использовался, а java была только для high level скриптования. Не?

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

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Так им и надо, упёртым сиплюсникам

O>Вот у меня, например, компилятор С++, который генерирует самый быстрый для платформы Intel код.

Ну этот код ещё написать надо

M>Жду сильный шахматный движок на Java

http://www.theserverside.com/discussions/thread.tss?thread_id=61390

Ява идёт туда, где деньги лежат.

In just the past year, we converted a plant (seed) genetic analysis system from C to Java (speeding it up immensely!),

we've seen some big Java projects at CERN,

we've moved several pharma HPC systems to Java (drug and genetic analysis work),

and helped some insurance companies both build out Java-based HPC infrastructure and encapsulate their legacy mainframe systems within a(n) SOA.

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

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

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

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

A>Суперпроизводительные шахматные программы теперь нужны только нердам, вроде тебя.

Просто пример интенсивных расчетов. Ок, из игр можно взять го. Сеги в крайнем случае.

Вообще, лично мне такие задачи очень некомфортно решать в терминах Java и других управляемых языков. Ибо вся задача у меня сводится к такому: у меня есть 1 Gb памяти. Например, получен с внешнего устройства (несжатое видео). Его надо обработать. И в терминах указателей это делать оказывается очень удобно.

A>http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Похжую тему я относительно недавно, вроде, поднимал. Только в контексте баз данных HBase/Cassandra/Neo4j. То есть в том плане, что народ совсем не боится даже базы данных на Java писать — значит с производительностью все в порядке.

M>Вообще, лично мне такие задачи очень некомфортно решать в терминах Java и других управляемых языков. Ибо вся задача у меня сводится к такому: у меня есть 1 Gb памяти. Например, получен с внешнего устройства (несжатое видео). Его надо обработать. И в терминах указателей это делать оказывается очень удобно.

Ходить просто по смещению туда/сюда можно и в Яве. Делать типизированное смещение (например, на размер структуры или поля) — ну это нельзя. Ну так в статье и про это было, что большие возможности дают лазейку большому кол-ву ошибок. Я понимаю, что конкретно тебя это не касается, потому что ты никогда ~~не пьянеешь~~ не ошибаешься, но есть и другие программисты, поплоше

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

M>Просто пример интенсивных расчетов. Ок, из игр можно взять го. Сеги в крайнем случае.

Думаешь здесь много пользы от с++ ?

Высокоуровневая оптимизация супротив низкоуровневой

M>Вообще, лично мне такие задачи очень некомфортно решать в терминах Java и других управляемых языков.

Это не "такие" задачи. Например Го нынче вместо пересчета всякой дряни в основном монте-карликами усиливается. Тут по моему языки с GC-должны просто рвать всякие плюсы в хлам.

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

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

I>Высокоуровневая оптимизация супротив низкоуровневой

I>Это не "такие" задачи. Например Го нынче вместо пересчета всякой дряни в основном монте-карликами усиливается. Тут по моему языки с GC-должны просто рвать всякие плюсы в хлам.

Вот в этом не уверен. В чем тут сила GC? У нас, допустим, 1 гигабайт хэша. Который при переборе заполнится на первых секундах. Потом идет задача поиска ненужных узлов и их удаления. На C++ освобождение узла это два присваивания. А в случае с GC у меня такой уверенности нет, потому как деревья получаются там со ссылками друг на друга, часто образующие кольца, ... Так что хотелось бы посмотреть. Хотя бы на просто генератор шахматных ходов на Java.

В целом алгоритмы многих сильнейших шахматных движков после появления движка IPPOLIT сейчас известны, исходники открыты. Потребность в сильнейших шахматных прогах есть у гроссов, особенно ведущих. Топалов перед матчем с Анандов арендовал у Васика 200-ядерный рыбий кластер за $100k за пару недель. Казалось бы, перепиши на Java, получи сильнейший в мире шахматный движок, потешь свое самолюбие, да еще и у проекта есть коммерческая прибыльность. Но тихо все.

M>На C++ освобождение узла это два присваивания.

+ вызов delete

(про который ты умолчал)

А если освобождение узла не ведёт к освобождению памяти, то причем тут ГЦ?

M>Казалось бы, перепиши на Java, получи сильнейший в мире шахматный движок, потешь свое самолюбие, да еще и у проекта есть коммерческая прибыльность. Но тихо все.

И жди, когда Топалов ещё 100К накопит, ага.

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

A>Как раз на Яве можно писать алгоритм, а на С++ начинают алгоритм смешивать с битовой и тактовой оптимизацией, из-за чего поддерживать потом будет не просто.
Обратной стороной проблемы является тот факт, что если на задумываться об оптимизации вначале, то часто код можно будет только переписать заново.

M>>Ну а в целом, как будет выглядеть в Java такое?
A>Да так же и будет, только вместо unsigned char* line будет byte [].
Я больше про передачу параметров. Как передать указатель в процедуры на середину byte[]

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

I>>Это не "такие" задачи. Например Го нынче вместо пересчета всякой дряни в основном монте-карликами усиливается. Тут по моему языки с GC-должны просто рвать всякие плюсы в хлам.

M>Вот в этом не уверен. В чем тут сила GC? У нас, допустим, 1 гигабайт хэша. Который при переборе заполнится на первых секундах. Потом идет задача поиска ненужных узлов и их удаления. На C++ освобождение узла это два присваивания. А в случае с GC у меня такой уверенности нет, потому как деревья получаются там со ссылками друг на друга, часто образующие кольца, ... Так что хотелось бы посмотреть. Хотя бы на просто генератор шахматных ходов на Java.

В Го переборы не работают, т.к. вычислительная сложность несравнимо выше чем в шахматной.

Потому основной метод усиления это всякие монте-карликовые симуляции. Здесь не надо ссылок друг на друга, колец и тд.

M>В целом алгоритмы многих сильнейших шахматных движков после появления движка IPPOLIT сейчас известны, исходники открыты. Потребность в сильнейших шахматных прогах есть у гроссов, особенно ведущих. Топалов перед матчем с Анандов арендовал у Васика 200-ядерный рыбий кластер за $100k за пару недель. Казалось бы, перепиши на Java, получи сильнейший в мире шахматный движок, потешь свое самолюбие, да еще и у проекта есть коммерческая прибыльность. Но тихо все.

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

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

M>>На C++ освобождение узла это два присваивания.
A>+ вызов delete

(про который ты умолчал)
А зачем delete? Все узлы имеют одинаковый размер. Получаем

struct free_node_t
{
  struct free_node_t* next;
};

free_node_t* free_nodes

node_t* alloc_node()
{
  node_t* ret_value = reinterpret_cast<node_t*>(free_nodes);
  if (free_nodes) free_nodes = free_nodes->next;
  return ret_value;
}

void free_node(node_t* node)
{
  free_node_t* free_node = reinterpret_cast<free_node_t*>(node);
  free_node->next = free_nodes;
  free_nodes = free_node;
}

M>>Казалось бы, перепиши на Java, получи сильнейший в мире шахматный движок, потешь свое самолюбие, да еще и у проекта есть коммерческая прибыльность. Но тихо все.
A>И жди, когда Топалов ещё 100К накопит, ага.
У TOP-игроков есть спонсоры. Плюс есть прослойка адвансеров.

M>А зачем delete? Все узлы имеют одинаковый размер. Получаем

Ну так Ява со списками тоже умеет, в чём проблема?

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

I>В Го переборы не работают, т.к. вычислительная сложность несравнимо выше чем в шахматной.
I>Потому основной метод усиления это всякие монте-карликовые симуляции. Здесь не надо ссылок друг на друга, колец и тд.

Если играть с компом, то компьютер как раз превосходит игрока в вычислительном плане. Монте-Карло это больше стратегическая симуляция. А считать жизнь/смерть группы все равно на отдельном участке все равно надо. И смотря на партию 9p против компа на 9 камнях форы как раз видно, что человек пару раз просчитался в определении жизни/смерти (считал, что ход сенте против черной группы, а оказалось, что это готэ).

I>Не такой там и бюджет большой, что бы переписывать с нуля достаточно сложную программу.
Взять какой-нить IvanHoe за основу и тупо перевести на Java? Там не так уж много кода

Было бы желание.

На середину не выйдет, а оно так уж надо? Создай класс с массивом и текущим смещением, и таскай его за собой.

public class Buffer {
 byte [] buffer;
 int offset;
}

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

M>>А зачем delete? Все узлы имеют одинаковый размер. Получаем

A>Ну так Ява со списками тоже умеет, в чём проблема?

Как минимум оверхид на такой список. Вряд ли компилятор догадается все преобразовать к сишному виду. Если node_t занимает 128 байт, то простой список это минимум 8 байт на элемент (указатель), что есть 6%. Неприятная мелочь. Во-вторых, нивелирование преимуществ GC (все равно надо руками следить).

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

I>Не умеет комп вычислять жызнь и смэрть

Какая у тебя сила игры?

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

I>>Не умеет комп вычислять жызнь и смэрть

M>Какая у тебя сила игры?

Хрен его знает, 2д на оро, на кгс давно не играл

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

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

I>>>Не умеет комп вычислять жызнь и смэрть

M>>Какая у тебя сила игры?

I>Хрен его знает, 2д на оро, на кгс давно не играл

Тогда может оценишь эту партию? Kim Myungwan (8p) — MoGo

В частности 149 ход черных (T11). Ну и вначале в правом нижнем углу

Здравствуйте, мыщъх, Вы писали:

М>Если задача типовая, то для Java и управляемых языков зачастую можно найти библиотеки, которых нет на си. скажем, я сам столкнулся, что для решения моих задач есть библиотеки на Java и даже Питоне с Руби, которые делают все, что нужно, а на Си и плюсах -- их нету и там это только предстоит написать.

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

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

E__>Здравствуйте, мыщъх, Вы писали:

E__>Ну дык логично — писать-то на управляемых языках проще. Та же ждава по количеству и качеству написанных либ оставляет далеко позади все другие существующие технологии. Что, само по себе, только ускоряет процесс разработки. Да и портирование с С++ на джаву дело несложное, хоть и рутинное. А вот обратное, да особенно если в коде используется динамическая сериализация и прочие рефлекшены — тот еще геморрой.
угу. тут встретился явовый код. внешне вполне себе приплюснутый, но при его разборе оказалось, что проще написать это дело по спецификации на алгоритм, чем портировать с явы на си.

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

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

M>Ну а в целом, как будет выглядеть в Java такое?

M>

M>uint32_t process_line(unsigned char* line, size_t line_len)
M>{
M>  uint32_t acc;
M>  for(size_t i=0; i<line_len; ++i)
M>    acc += line[i];
M>  return acc;
M>}

M>unsigned char* data;
M>process_line(data + offset, some_value);
M>

И как понять, что это за хитрый хак? Подсчет суммы каких-то неясных данных, отстоящих на offset от случайного значения??

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

R>Интенсивные расчеты уже лет 5 как массово считаются на GPU.

Тссс! Пусть детишки порадуются.

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

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

A>>Как раз на Яве можно писать алгоритм, а на С++ начинают алгоритм смешивать с битовой и тактовой оптимизацией, из-за чего поддерживать потом будет не просто.
M>Обратной стороной проблемы является тот факт, что если на задумываться об оптимизации вначале, то часто код можно будет только переписать заново.

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

M>>>Ну а в целом, как будет выглядеть в Java такое?
A>>Да так же и будет, только вместо unsigned char* line будет byte [].
M>Я больше про передачу параметров. Как передать указатель в процедуры на середину byte[]

Ммм, добавить параметр "int start" в функцию? Ну а если мы говорим про строки(я в исходном варианте видел char) — то сделать str.substring() — оно создает строку со ссылкой на тот же буфер, что и исходная, просто начало будет сдвинуто. Вобщем, как-то так:

long process_line(String line, long line_len)
{
  long acc;
  for(long i=0; i<line_len; ++i)
    acc += line.charAt(i) && 0x00FF;
  return acc;
}

String data;
data = <some code>
process_line(data.subString(<offset>)/*эта операция копеечная, О(1) на любой строке*/, <some_value>);

Правда, смысла в таком коде мало — анализировать только младший байт char в строке. Приведи более реальную задачу, чем этот не совсем понятный код, будет более осмысленное решение. Задачу — словами, а не кодом, пожалуйста.

Кстати, а что будет, если <some_value> превысит размер массива? А джаве полетит исключение. В С++ — посчитается значение случайного блока памяти, безопасники такие штуки просто обажают.

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

A>>На середину не выйдет, а оно так уж надо? Создай класс с массивом и текущим смещением, и таскай его за собой.

A>>

A>>public class Buffer {
A>> byte [] buffer;
A>> int offset;
A>>}
A>>

M>Лишний код, лишние ошибки. Лишняя головная боль оптимизатору. Лишние проверки при индексации.

Сценарий появления ошибки от создания такого класса в студию. В нативе аго придумать можно. В яве — с трудом.

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

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

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

E__>А нижно ли задумываться над оптимизацией всегда и везде? А то пока все оптимизируешь, конкуренты на джаве напишут втрое превышающий функционал. Оптимизировать нужно, но только тогда, когда
вот-вот. сейчас мы начинаем деплоить наш сканер, который работает ~30 sec, а я пока допиливаю "слегка" оптимизированный прототип, который работает < 30 ms. т.е. в тысячу раз оптимизация, но... интереса у руководства нет. скорость -- не самое главное. в заданные рамки вписываемся и ладно.

Здравствуйте, мыщъх, Вы писали:

E__>>Ну дык логично — писать-то на управляемых языках проще. Та же ждава по количеству и качеству написанных либ оставляет далеко позади все другие существующие технологии. Что, само по себе, только ускоряет процесс разработки. Да и портирование с С++ на джаву дело несложное, хоть и рутинное. А вот обратное, да особенно если в коде используется динамическая сериализация и прочие рефлекшены — тот еще геморрой.
М>угу. тут встретился явовый код. внешне вполне себе приплюснутый, но при его разборе оказалось, что проще написать это дело по спецификации на алгоритм, чем портировать с явы на си.

А вот обратное портирование без проблем. В чей огород это скорее камень?

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

А почему, собственно? И да, кто они по основной специализации?

Здравствуйте, мыщъх, Вы писали:

E__>>А нижно ли задумываться над оптимизацией всегда и везде? А то пока все оптимизируешь, конкуренты на джаве напишут втрое превышающий функционал. Оптимизировать нужно, но только тогда, когда
М>вот-вот. сейчас мы начинаем деплоить наш сканер, который работает ~30 sec, а я пока допиливаю "слегка" оптимизированный прототип, который работает < 30 ms. т.е. в тысячу раз оптимизация, но... интереса у руководства нет. скорость -- не самое главное. в заданные рамки вписываемся и ладно.

Эх, я понимаю таки тебя. Была у меня задачка. Чисто визуального плана(но с хитрыми прибамбасами), из условий — линух, джава, флеш, но никаких графических либ вроде GTK или QT(кроме Х11). Задачка вообще не совсем моя, но от основной задачи уже мозги плавятся, решил взяться, подвязал тикет на себя(разгрузить одним вечером мозг). Можно было бы решить высокоуровневыми способами, но там пришлось бы использовать особую "магию". А я тупо написал на сях штуку под Х11, два часа ушло(при том, что я не имел представления об Х11 до этого, но оказалось, что это как более продуманная версия винапи, аж ностальгия накатила). Получилось нечто, отлично решающее задачу, минимального размера, и вообще не потребляющее ресурсы по современным меркам(несколько килобайт, проц даже не мерял). Хотя если бы вышла штука, жрущая для той же плевой задачи 50 метров, всем было бы пофигу... Правда, Шеридан бы, будь он полностью беспристрастен, посчитал бы, что я использовал неправильную технологию для решения задачи, но получилось быстро и эффективно, так что я бы его проигнорил.

Ну и тут сыграло то, что на высоком уровне было бы больше геморроя, по крайней мере для меня, ну и разобраться с Х11 было интересно. А я вообще по жизни странными вещами занимаюсь — уже впору в резюме писать "специалист по скрещиванию ежей с ужами и прочими представителями <вставить свое>".

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

O>>Вот у меня, например, компилятор С++, который генерирует самый быстрый для платформы Intel код.
A>Ну этот код ещё написать надо

А на жабе код пишет кто, не люди разве?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>Здравствуйте, мыщъх, Вы писали:

М>>угу. тут встретился явовый код. внешне вполне себе приплюснутый, но при его разборе оказалось, что проще написать это дело по спецификации на алгоритм, чем портировать с явы на си.
E__>А вот обратное портирование без проблем. В чей огород это скорее камень?
давайте вы портируете мой си-код на жабу? а ведь он вообще-то ANSI С. и без проблем компилиться как минимум студей под вынь и гнусем под линь и мак (из того, что компилим регулярно), и так же был легко портирован на Micro-C (подмножество си). вот только на жабу его, боюсь, ни за что не перенести. там идут жуткие игры с указателями и нецензурный кастинг. нецензурный в том смысле, что аргумент у нас один, и функция сама понимает то ли это индекс, то ли указатель. (проверка sizeof(t) не меньше sizeof(*t) там есть с выбором мак. -- так что все законно, это даже как бы не хак)).

М>>но отношение к жабе у моих знакомых программистов в целом негативное. даже если брать серверные проложения, где она традиционно сильна.
E__>А почему, собственно? И да, кто они по основной специализации?
коллеги специализируются в сервных приложениях для энтерпрайза, причем приложения установлены более, чем на одном сервере и общаются меж собой. и им для этой цели нравится рубин больше жабы потому, что он упрощает управление. и сейчас рубин очень популярен. девелоперы расхватываются как горячие пирожки.

M>Лишний код, лишние ошибки.

А просто указатель туда-сюда таскать — это, конечно, предотвращает появление ошибок

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

E__>JIT подтянется — он тоже поймет, что именно этот кусок нужно в нативу скомпилить.
Не стоит так в него верить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>Здравствуйте, мыщъх, Вы писали:

E__>>>А нижно ли задумываться над оптимизацией всегда и везде? А то пока все оптимизируешь, конкуренты на джаве напишут втрое превышающий функционал. Оптимизировать нужно, но только тогда, когда
М>>вот-вот. сейчас мы начинаем деплоить наш сканер, который работает ~30 sec, а я пока допиливаю "слегка" оптимизированный прототип, который работает < 30 ms. т.е. в тысячу раз оптимизация, но... интереса у руководства нет. скорость -- не самое главное. в заданные рамки вписываемся и ладно.

E__>Эх, я понимаю таки тебя. Была у меня задачка. Чисто визуального плана
...
E__>современным меркам(несколько килобайт, проц даже не мерял). Хотя если бы вышла штука,
E__>жрущая для той же плевой задачи 50 метров, всем было бы пофигу...
все так же и у меня. только наоборот. пока отлынивал от работы и уехал в самовольный загран, в отеле на ноуте соорудил workaround из того, что было под руками на супер высоком уровне абстрации, где моих только пара сотен строк на си. короче frond-end к уже существующему back-end.

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

руководство грит -- ну вот, видишь, ты же и сам все понимаешь. вот сейчас ты выиграл 30 сек скорости. и то латентности. пропускная способность наращивается хоть до бесконечности. клиенты же понимают два режима: реалтайм и не реал-тайм. 30 ms это не реал-тайм, следовательно _качественной_ разницы между 30 сек и 30 мсек нет. а вот _качественная_ разница в невозможности настройки оптимизированного варианта под вечного меняющиеся требования (а они и правда меняются) это уже _качественная_ потеря части рынка.

типа выиграл 30 сек, а проиграл 30 дней работы. и действительно -- очень редко бывает, чтобы оптимизация давалась задаром. всегда что-то страдает. пускай хотя бы требования к квалифиации программиста, который будет саппортить этот код...

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

M>Ну а в целом, как будет выглядеть в Java такое?

M>

M>uint32_t process_line(unsigned char* line, size_t line_len)
M>{
M>  uint32_t acc;
M>  for(size_t i=0; i<line_len; ++i)
M>    acc += line[i];
M>  return acc;
M>}

M>unsigned char* data;
M>process_line(data + offset, some_value);
M>

К счастью на java такого не напишут никогда.

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

E__>>Оптимизировать нужно, но только тогда, когда понимаешь, что вот этот кусок кода работает часто и отжирает 99% ресурсов, и этих ресурсов не хватает.

N>Это практически идеальный и радостный случай: нашли бутылочное горлышко и давай его расширять. Настоящие проблемы начинаются, когда программа работает медленно, а горлышка-то и нет. Самая медленная функция отжирает процентов 7-8 общего времени. Вот и приходится лазать по всей программе с низкоуровневыми оптимизациями. Такой сценарий как раз очень характерен для больших и сложных систем.

Отвечу, когда буду трезвее. Мысли есть, но я сейчас задолбаюсь их высказывать.

И да, всех с пятницей!

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

G>Весь гиг разом ты обрабатывать не будешь, будешь это делать по кадрам. Сам по себе в памяти этот гиг не появится, его нужно будет прочитать из внешнего устройства (даже тупо с диска).

Если брать тот случай, что я имел в виду, то специфика задачи такая, что не катит. На входе поступает видеоинформация по кадрам, а обрабатывать надо отдельно каждый пиксель по времени. Так что пока я не получу последний кадр, у меня связаны руки.

G>Вот тут управляемые платформы помогут тебе организовать асинхронное чтение и параллельную обработку данных, тогда у тебя и не будет ограничения на объем данных. На C\C++ такое писать в разы геморройнее.

Управляемая платформа даже позволит написать драйвер к нашему устройству?

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

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

G>>Весь гиг разом ты обрабатывать не будешь, будешь это делать по кадрам. Сам по себе в памяти этот гиг не появится, его нужно будет прочитать из внешнего устройства (даже тупо с диска).

M>Если брать тот случай, что я имел в виду, то специфика задачи такая, что не катит. На входе поступает видеоинформация по кадрам, а обрабатывать надо отдельно каждый пиксель по времени. Так что пока я не получу последний кадр, у меня связаны руки.
Не понял связи.

G>>Вот тут управляемые платформы помогут тебе организовать асинхронное чтение и параллельную обработку данных, тогда у тебя и не будет ограничения на объем данных. На C\C++ такое писать в разы геморройнее.

M>Управляемая платформа даже позволит написать драйвер к нашему устройству?

А устройство как подключается?

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

N>>Это практически идеальный и радостный случай: нашли бутылочное горлышко и давай его расширять. Настоящие проблемы начинаются, когда программа работает медленно, а горлышка-то и нет. Самая медленная функция отжирает процентов 7-8 общего времени. Вот и приходится лазать по всей программе с низкоуровневыми оптимизациями. Такой сценарий как раз очень характерен для больших и сложных систем.
G>Такой сценарий характерен если вы не умеете профайлером нормально пользоваться.

Поясни.

А вообще я могу привести маленький пример из практики. Попала как-то ко мне небольшая библиотека для работы с нейросетями. Хорошая, но медленная. Так вот, профайлер (VTune интеловский) говорит, что ничего больше 10% процентов процессорного времени не выполняется. Что я делаю:
1. где-то вручную разворачиваю циклы;
2. где-то меняю индексы на итераторы, где-то наоборот;
3. меняю типы стандартных контейнеров;
4. меняю float на double;
5. в некоторых местах заменяю 2-3 обращения по одинаковому индексу на одно — присваиваю значение локальной переменной, а после работаю с ним;
6. перебираю опции компилятора;
7. ещё что-то было.

И что в результате? Ускорилось примерно вдвое. Но мне пришлось перелопатить практически весь код, навводить кучу typedef, оттюнинговать практически все циклы в программе. Да, расскажи как это делается в управляемых языках, без дизассемблера и профайлера, который умеет показывать в ассемблерном коде время выполнения каждой инструкции.

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

I>Известная фабула — нищие но гордые аристократы желают порододниться с безродными но богатми нуворишами которые в свою очередь хотят заполучить титул за деньги.

Получить-то за деньги можно, да только после этого надо себя признать членом их рода, а не наоборот. Джейн Смит может выйти замуж за сына герцога Мальборо, но после этого ей надо быть герцогиней Мальборо, а не ее мужу — герцогом Смитом

. А если дочь герцога Мальборо выйдет за Джона Смита, то Джон Смит очень захочет стать герцогом Мальборо, но у него из этого вряд ли что выйдет.

M>Управляемая платформа даже позволит написать драйвер к нашему устройству?

Товарищ, не спрыгивайте с темы! Драйвера (и саму ВМ) пишите на С, а здесь речь идёт про научные вычисления

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

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

I>>Известная фабула — нищие но гордые аристократы желают порододниться с безродными но богатми нуворишами которые в свою очередь хотят заполучить титул за деньги.

PD>Получить-то за деньги можно, да только после этого надо себя признать членом их рода, а не наоборот. Джейн Смит может выйти замуж за сына герцога Мальборо, но после этого ей надо быть герцогиней Мальборо, а не ее мужу — герцогом Смитом

. А если дочь герцога Мальборо выйдет за Джона Смита, то Джон Смит очень захочет стать герцогом Мальборо, но у него из этого вряд ли что выйдет.

Это что то меняет в содержании фабулы ?

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

I>>Хрен его знает, 2д на оро, на кгс давно не играл

M>Тогда может оценишь эту партию? Kim Myungwan (8p) — MoGo

M>В частности 149 ход черных (T11). Ну и вначале в правом нижнем углу

Здесь играли 800 ядер МоГо, да еще и на огромной форе, что уже как бы намекает

Комп где то на порядок мощнее известного Deep Blue кстати говоря.

Проф, во первых, какой то странный, в проф турнирах не замечен последнее время. Во вторых, играет он как пулемёт — потратил 15 минут против 55. Т.е. в среднем на ход тратил по 4 секунды

На счет оценки, партию вроде как все кому не лень было, оценили.

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

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

M>>Управляемая платформа даже позволит написать драйвер к нашему устройству?

G>А устройство как подключается?

USB 2.0 Устройство примерно тако. Но меня все это мало волновало, потому что точка входа была такой: вот тебе указатель на данные, вот указатель куда надо записать выход в таком-то формате.

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

M>>Управляемая платформа даже позволит написать драйвер к нашему устройству?

A>Товарищ, не спрыгивайте с темы! Драйвера (и саму ВМ) пишите на С, а здесь речь идёт про научные вычисления

Ну так я получаю от драйвера указатель на память. Которую затем надо обработать. Драйвером я не занимался.

N>Возможно. Но моя мысль была немного о другом:

Ну и мой первый пост был о другом — интенсинвные вычисления можно и уже делают на Яве.

N>С++ позволяет быстро писать как в довольно высокоуровневом стиле,

Собственно ни один человек и не ставил под сомнение мощность языка С++

M>Ну так я получаю от драйвера указатель на память. Которую затем надо обработать. Драйвером я не занимался.

Ну да, это проблема. Но ведь сравнение шло для научных вычислений, которые можно делать и на Яве и на С.

Твой аргуменнт "всегда надо на С, потому что у нас есть драйвер, с которым нельзя взаимодействовать из Явы"

А какое отношение твой аргумент имеет отношение к задачам, которые можно решать на обоих языках. НИКАКОГО.

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

N>>Возможно. Но моя мысль была немного о другом:
A>Ну и мой первый пост был о другом — интенсинвные вычисления можно и уже делают на Яве.

Вот целесообразность этого я и ставлю под сомнение своим примером. Когда скорости будет недостаточно, а узких мест нет, то на С/С++ можно получить зачастую значительное ускорение за счёт низкоуровневых оптимизаций, а на Яве нельзя. К тому же, как тут многие говорят, перенос кода с Явы на С очень непрост. Стоит ли рисковать?

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

PD>>Получить-то за деньги можно, да только после этого надо себя признать членом их рода, а не наоборот. Джейн Смит может выйти замуж за сына герцога Мальборо, но после этого ей надо быть герцогиней Мальборо, а не ее мужу — герцогом Смитом

. А если дочь герцога Мальборо выйдет за Джона Смита, то Джон Смит очень захочет стать герцогом Мальборо, но у него из этого вряд ли что выйдет.

I>Это что то меняет в содержании фабулы ?

Конечно. Вам же хочется, чтобы вас признали герцогом и ввели в число пэров, но при этом остаться Джоном Смитом

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

PD>>>Получить-то за деньги можно, да только после этого надо себя признать членом их рода, а не наоборот. Джейн Смит может выйти замуж за сына герцога Мальборо, но после этого ей надо быть герцогиней Мальборо, а не ее мужу — герцогом Смитом

. А если дочь герцога Мальборо выйдет за Джона Смита, то Джон Смит очень захочет стать герцогом Мальборо, но у него из этого вряд ли что выйдет.

I>>Это что то меняет в содержании фабулы ?

PD>Конечно. Вам же хочется, чтобы вас признали герцогом и ввели в число пэров, но при этом остаться Джоном Смитом

Мне хочется оставаться самим собой. Я начинал с турбопаскаля, потом был ассемблер, си, си++ и только три последних года я не программирую на С++.

Вот и кто я по твоему, Герцог Мальборо или Джон Смит ?

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

I>Мне хочется оставаться самим собой. Я начинал с турбопаскаля, потом был ассемблер, си, си++ и только три последних года я не программирую на С++.

I>Вот и кто я по твоему, Герцог Мальборо или Джон Смит ?

Лорд Дэвид Дерри-Мойр, который и впрямь решил стать Том-Джим-Джеком . В. Гюго, "Человек, который смеется".

http://fictionbook.ru/author/gyugo_viktor/chelovek_kotoriyyi_smeetsya/?sid=44f1cd75c79e030e89b3f39c7a82cea1

А впрочем, кто тебя знает, что у тебя в душе...

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

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

N>>>Это практически идеальный и радостный случай: нашли бутылочное горлышко и давай его расширять. Настоящие проблемы начинаются, когда программа работает медленно, а горлышка-то и нет. Самая медленная функция отжирает процентов 7-8 общего времени. Вот и приходится лазать по всей программе с низкоуровневыми оптимизациями. Такой сценарий как раз очень характерен для больших и сложных систем.
G>>Такой сценарий характерен если вы не умеете профайлером нормально пользоваться.

N>Поясни.

N>А вообще я могу привести маленький пример из практики. Попала как-то ко мне небольшая библиотека для работы с нейросетями. Хорошая, но медленная. Так вот, профайлер (VTune интеловский) говорит, что ничего больше 10% процентов процессорного времени не выполняется. Что я делаю:
N>1. где-то вручную разворачиваю циклы;
N>2. где-то меняю индексы на итераторы, где-то наоборот;
N>3. меняю типы стандартных контейнеров;
N>4. меняю float на double;
N>5. в некоторых местах заменяю 2-3 обращения по одинаковому индексу на одно — присваиваю значение локальной переменной, а после работаю с ним;
N>6. перебираю опции компилятора;
N>7. ещё что-то было.

Хм. А я вот беру java код запуская профайл и налету вижу — вот у меня время выполнения каджой функции, как и вообще, так и за вычитом каждой внутренней функции, вот количество аллокейшеном в реалтайме, вот количество объектов в памяти, вот их размеры. А вот разница между предыдушем билдом и текущим.

И да, вы когда эти изменение делали вы держали в уме что вот под этим процессором это ускорит, а вот под этим замедлит. А вот тут у нас есть float аппаратный, а вот тут эмуляция, а вот тут у нас цена доступа к памяти такая, а вот тут такая, а вот тут вообще два типа памяти и данные между ними могут перемещатся, а вот тут у нас в режиме пониженного энерго потребления такая скорость, а в нормальном такая. А вот тут вообще такая конструкция роняет единственный компилятор под данную платформу в internal error, а вот тут под одним компилятором будет фукция инлайнится, а вот тут не смотря на явное указание нет. А вот под другим компилятором наоборот будет всегда инлайнится не смотря ни на что. А вот это изменение приведет к увеличение размера результируещго кода на 30% под одним компилятором, и на 200% под другим.

Ой, у вас одна платформа — хорошо вам.

N>И что в результате? Ускорилось примерно вдвое. Но мне пришлось перелопатить практически весь код, навводить кучу typedef, оттюнинговать практически все циклы в программе. Да, расскажи как это делается в управляемых языках, без дизассемблера и профайлера, который умеет показывать в ассемблерном коде время выполнения каждой инструкции.

Никак. Увы никак. Но вот я могу сказать на примере j2me vs brew — я наверно написал почти два десятка игр под обе платформы.
Т.е. одна и так же игра делалась под обе платформы — иногда изначально на java, иногда изначально на c++ и потом порт, иногда паралельно. И в среднем — c++ версия на _такой же_ аппаратной платформе давала прирост дай бог 10%. При большем времени разработки.

Но время разработки ладно — там тоже 10-15 процентов. А вот в предсказуемости, в укладывании в сроки явские проекты как-то получше результаты показывали.

Да, в c++ проектах иногда, под некоторые модели телефоном можно было себе позволить плюшки, которые не возможно было в принципе сделать на java — типа там full screen anti aliasing из-за прямого доступа к памяти. Только вот если судить по результирующим деньгам эти плюшки иногда приводили к такому жесткому дебагу, что их необходимость вызывала очень существенные вопросы.

И сейчас вот у меня есть опыт разработки под android — как и чисто ява игр, так и 99% кода на c++ (ndk), так и микса.

Пока практика показывает — если взять чужой c++ код, то шансы наступить там грабли столь велики, что просто тупое переписывание кода на java сравнимо в результате с тем чтобы просто его собрать и разбиратся с этим граблями.

Уы и ах, это безусловно говорит о не очень хорошем коде. Только вот почему-то при портирование java->с++ таких проблем практически нет.

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

Y>Уы и ах, это безусловно говорит о не очень хорошем коде. Только вот почему-то при портирование java->с++ таких проблем практически нет.

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

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

N>>Поясни.
Где же разъяснение про неумение пользоваться профайлером?

N>>А вообще я могу привести маленький пример из практики. Попала как-то ко мне небольшая библиотека для работы с нейросетями. Хорошая, но медленная.
G>А что ты имеешь ввиду под словом "медленная"?
Работает недостаточно быстро для возможности реального применения. Это же очевидно.

N>>И что в результате? Ускорилось примерно вдвое. Но мне пришлось перелопатить практически весь код, навводить кучу typedef, оттюнинговать практически все циклы в программе.
G>А сколько строк кода было? Важен порядок.
G>То что ты рассказываешь реально сделать для 1000 строк, когда за 10 перевалит — замучаешься такое делать.

Да, там было всего пара тысяч строк. И я потратил на них ровно один день. И получился работоспособный продукт. Было бы 10 тысяч строк, тоже бы справился — опыт есть.

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

Занимается, занимается. В частности, на этом примере мне надо было распознавать текст на видео. Я нашёл библиотеки для разных классификаторов, все обучил, выбрал наиболее подходящий мне по точности работы. А потом допилил его до предъявляемых требований по быстродействию. И такой пример в моей практике не один. Всё обыденно.

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

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

G>Распознавание текста делается другими средствами гораздо быстрее и проще.
G>Например надергал бы символов с обучающих выборок, а потом тупо сопоставлял бы их с символами на видео. Процент угадывания около 100 и не зависит от эзотерических факторов, как в нейронных сетях.

Если есть точно такие же, то может и 100, а если другого размера, наклонены, повернуты, замазаны и тд и тд и тд и тд — сильно вряд ли.

G>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
G>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.

А когда все это уже есть, что дальше надо делать ?

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

I> G>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
I> G>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.

I> А когда все это уже есть, что дальше надо делать ?

Дык переписать на сях

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>> G>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
I>> G>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.

I>> А когда все это уже есть, что дальше надо делать ?

H>Дык переписать на сях

На сях как раз не обязательно. При этом код может получиться на порядок сложнее.

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

I> I>> А когда все это уже есть, что дальше надо делать ?

I> H>Дык переписать на сях

I> На сях как раз не обязательно. При этом код может получиться на порядок сложнее.

Коли остались только низкоуровневые оптимизации то и инструмент нужен соответствующий.

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>> H>Дык переписать на сях

I>> На сях как раз не обязательно. При этом код может получиться на порядок сложнее.

H>Коли остались только низкоуровневые оптимизации то и инструмент нужен соответствующий.

Цитирую себя "код может получиться на порядок сложнее."

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

I>>Если есть точно такие же, то может и 100, а если другого размера, наклонены, повернуты, замазаны и тд и тд и тд и тд — сильно вряд ли.
G>Тогда и нейронные сети не справятся

Справляются.

G>А вообще начинай курить отсюда: http://bik-top.livejournal.com/37060.html

Ты всерьез решил что кого то можешь удивить этим букварём ?

G>>>Отлично понимаю, мне удавалось оптимизировать тяжелые вычислительные задачи без пидарасинья тактов.
G>>>Зачастую выбор правильного алгоритма + архитектурные оптимизации (предварительные вычисления) + параллелизм и больше ниче делать не надо.
I>>А когда все это уже есть, что дальше надо делать ?
G>Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.

Это по малолетству так кажется

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

Ops>Есть такой анекдот: 2 манагера в курилке:
Ops>- Джонни, ты такой рафинированный интеллигент, с тобой на приемах даже здоровается английская королева, что надо сделать, чтобы стать таким же?
Ops>- Надо закончить Кембридж.
Ops>- Так я же закончил?
Ops>- Не тебе, дурак, а твоему дедушке.

А еще можно вспомнить про то, что требуется, чтобы сделать газон , как в Англии. Совсем немного — аккуратно поливать и подстригать на протяжении 300 лет

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

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

I>>>Если есть точно такие же, то может и 100, а если другого размера, наклонены, повернуты, замазаны и тд и тд и тд и тд — сильно вряд ли.
G>>Тогда и нейронные сети не справятся

I>Справляются.
Да ну? Приведи ссылку на реализацию нейронной сети, которая на картинке определяет букву независимо от того как её исказили.

G>>А вообще начинай курить отсюда: http://bik-top.livejournal.com/37060.html
I>Ты всерьез решил что кого то можешь удивить этим букварём ?
Ну ты видимо и его не знаешь раз для тебя представляют проблемы поворот, наклон, шум итп.

Ты, видимо, кроме перцептронов из школьного учебника ничего больше не знаешь. Зачем же быть таким агрессивным в своём невежестве?

I>>А когда все это уже есть, что дальше надо делать ?
G>Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.

Ты не поверишь, но пользователям пофиг на правильную архитектуру и правильные алгоритмы. Им надо, чтобы не тормозило.

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

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

I>>>Если есть точно такие же, то может и 100, а если другого размера, наклонены, повернуты, замазаны и тд и тд и тд и тд — сильно вряд ли.
G>>Тогда и нейронные сети не справятся

N>Ты, видимо, кроме перцептронов из школьного учебника ничего больше не знаешь. Зачем же быть таким агрессивным в своём невежестве?
Ну конечно.
А ты что использовал?

I>>>А когда все это уже есть, что дальше надо делать ?
G>>Когда все это есть, то пользователи уже счастливы и больше ничего делать не надо.
N>Ты не поверишь, но пользователям пофиг на правильную архитектуру и правильные алгоритмы. Им надо, чтобы не тормозило.
Да ты че? И как коррелирует пользовательское "не тормозило" и время работы?

Старый баян: пользователи Visual C жаловались на медленную компиляцию проектов в студии, говорили что C++Builder делает это быстрее.
Разработчики замерили. Оказалось что VC таки работает быстрее.
Знаешь в чем было дело? C++Builder бегущие циферки во время компиляции показывает, они субъективно уменьшают время работы.

Мой случай. Рисование многослойных изображений, один раз нарисовать и закешировать было нельзя, при перемещении, масштабировании приходилось перерисовывать. При перемещении часть изображения надо нарисовать по-новой, это отнимало около 1 секунды. То есть при любом перемещении на 1 секунду интерфейс подвисал для расчетов и отрисовки. Пользователи говорили что "жутко тормозит".
Поменяли рисование на асинхронное. Фактически оно стало выполнятся дольше (тогда еще одноядерные процессоры были поголовно), но пользователи остались довольны, потому что интерфейс перестал подвисать.

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

I> H>Коли остались только низкоуровневые оптимизации то и инструмент нужен соответствующий.

I> Цитирую себя "код может получиться на порядок сложнее."

На порядок это сильно сомнительно. Но да, при оптимизациях, даже алгоритмических, код становится сложнее.

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>> H>Коли остались только низкоуровневые оптимизации то и инструмент нужен соответствующий.

I>> Цитирую себя "код может получиться на порядок сложнее."

H>На порядок это сильно сомнительно. Но да, при оптимизациях, даже алгоритмических, код становится сложнее.

С алгоритмическими особых проблем нет.

А вот числодробилки практически всегда дают код который выносит мозг.

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

I>>Справляются.
G>Да ну? Приведи ссылку на реализацию нейронной сети, которая на картинке определяет букву независимо от того как её исказили.

http://handysolution.com/science/CNN.pdf

G>>>А вообще начинай курить отсюда: http://bik-top.livejournal.com/37060.html
I>>Ты всерьез решил что кого то можешь удивить этим букварём ?
G>Ну ты видимо и его не знаешь раз для тебя представляют проблемы поворот, наклон, шум итп.

Судя по твоим 100% ты про разспознавание знаешь по таким вот букварям. Такой подход как раз дает низкий процент угадывания. Алгоритмы обработки изображений вобщем то известны, особо стараться не нужно.

Сам подумай — поменял чуток капчу и ломалки капчи отваливаются

Поставил у себя на форуме нормальную капчу, весь спам пропал, а до того был по 1-2 сообщению в час.

Представь — было бы 100%, как ты выдумал, капча вообще работать не будет

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

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

I>>>Справляются.
G>>Да ну? Приведи ссылку на реализацию нейронной сети, которая на картинке определяет букву независимо от того как её исказили.

I>http://handysolution.com/science/CNN.pdf

G>>>>А вообще начинай курить отсюда: http://bik-top.livejournal.com/37060.html
I>>>Ты всерьез решил что кого то можешь удивить этим букварём ?
G>>Ну ты видимо и его не знаешь раз для тебя представляют проблемы поворот, наклон, шум итп.

I>Судя по твоим 100% ты про разспознавание знаешь по таким вот букварям.
Ты видимо вообще не знаешь. Зачем тогда пишешь?

I>Такой подход как раз дает низкий процент угадывания.
Ага, 0.9

I>Алгоритмы обработки изображений вобщем то известны, особо стараться не нужно.
Стараться что делать?

I>Сам подумай — поменял чуток капчу и ломалки капчи отваливаются

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

I>Поставил у себя на форуме нормальную капчу, весь спам пропал, а до того был по 1-2 сообщению в час.
I>Представь — было бы 100%, как ты выдумал, капча вообще работать не будет

Ты думаешь есть алгоритм, способный взомать произвольную капчу?
Пишется код для слома определенной капчи.

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

I> H>На порядок это сильно сомнительно. Но да, при оптимизациях, даже алгоритмических, код становится сложнее.

I> С алгоритмическими особых проблем нет.

Выделил.

I> А вот числодробилки практически всегда дают код который выносит мозг.

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

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>>>Представь — было бы 100%, как ты выдумал, капча вообще работать не будет

G>>

Ты думаешь есть алгоритм, способный взомать произвольную капчу?
G>>Пишется код для слома определенной капчи.

I>В том то и дело. А для распознавания изображений такое дело не подходит, потому что здесь сразу все случаи вместе взятые.
Что ты имеешь ввиду "для распознавания изображений"? Распознавание капчи — не распознавание изображения?
Или тебе на вход дано произвольно изображение и алгоритм, который скажет что на нам?
Я тебя расстрою, такого еще не придумали.
Все алгоритмы "распознавания" распознают вполне конкретные вещи на изображениях, напрмиер текст, лица итп.
Нету алгоритма, который скажет по фотографии: "тут улыбается девочка" или "тут слово х** на заборе написано".

I>Потому может используется нейронная сеть, например, как классификатор
Логики вообще не понял. Ты что классифицировать собрался?

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

G>Обучающая выборка это уже конкретные символы и конкретные шрифты.

Да, да. Но я не знаю, что напишет на вагоне очередной железнодорожник. Поэтому выбрал вариант, который умеет обобщать знания, а не работать по шаблонам.

N>>Нафиг GUI.
G>GUI это единственное что видит пользователь. И единственное по чему он может сделать оценку что "не тормозит".

Нет, нет. Пользователь ещё видит как быстро открывается шлагбаум на автоматической парковке, слышит щелчок замка двери при подносе пальца к считывателю или лица к камере. Добро пожаловать в 21 век!

N>>Если конкуренты способны анализировать 16 видеоканалов 25 кадров в секунду, а ты только 8 — это отстой.
G>А если пользователям только два надо, но вполне нормально.

Никому не надо два. Даже маленькие аптеки и магазинчики берут не меньше 4-х.

G>Поставил проц с удвоенным ко-вом ядер, увеличил вдвое память и уже не отстой. А это только малая часть твоей ЗП за месяц. Или ты бесплатно оптимизировать будешь?

Ничего не малая. А если компов надо много? А если его ставят внутрь какого-нибудь маленького ящика и вешают на столб или стену? А если комп — это буджетный нет-топ для квартиры? Всё это клиенты, плюсы для маркетинга. Или все должны купить себе такого зверя за 700 штук и радоваться жизни?

N>>Я уже не говорю про по-настоящему большие задачи, для которых кластеры собирают. Там лишний десяток процентов производительности будет очень быстро окуплен той же электроэнергией.
G>И много ты таких видел?

2.

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

I>>В том то и дело. А для распознавания изображений такое дело не подходит, потому что здесь сразу все случаи вместе взятые.
G>Что ты имеешь ввиду "для распознавания изображений"? Распознавание капчи — не распознавание изображения?

Я имел ввиду более общий случай, а не капчу. Капча это достаточно простой случай.

Тебе, например, заранее известно, что там будет. Т.е. не надо думать, если в капче текст или нет.

Если есть капча, то и ежу понятно, что там будет какой то текст.

А представь, как быть например в том случае, когда нужно анализировать видеопоток или фотографии.

Надо например выдрать автомобильные номера — сначала надо найти кадр где есть номер. Потом вычленить сам сегмент с номером а уже потом распознать собственно сам номер.

G>Все алгоритмы "распознавания" распознают вполне конкретные вещи на изображениях, напрмиер текст, лица итп.

Спасибо, капитан очевидность.

I>>Потому может используется нейронная сеть, например, как классификатор
G>Логики вообще не понял. Ты что классифицировать собрался?

Ты просто не в теме, да и всё

Открой ссылку которую я тебе дал да посмотри, сразу поймешь что такое классификатор в обсуждаемо контексте.

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

I>> С алгоритмическими особых проблем нет.

H>Выделил.

Ты еще на каждое слово начни ответ писать.

I>> А вот числодробилки практически всегда дают код который выносит мозг.

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

Код без комментариев в функциональном стиле с правильными именами, без злоупотребления лямбдами и неявными конструкциям читается очень легко и просто.

Оптимизации это практически всегда тупая императивщина с указателями, сайдэффектами, всякими низкоуровневыми хаками. Здесь комментарии просто обязательны, т.к. код тупо не сообщает всей инфы.

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

I> I>> С алгоритмическими особых проблем нет.

I> H>Выделил.

I> Ты еще на каждое слово начни ответ писать.

Это уж мне решать.

I> H>Самые мозговыносящие оптимизации это те, что основываются на сайд-эффектах. Но если все документировано (код хорошо комментирован) то даже ассемблерные вставки читать не сложно, но о порядке сложности тут говорить трудно.

I> Код без комментариев в функциональном стиле с правильными именами, без злоупотребления лямбдами и неявными конструкциям читается очень легко и просто.

Спасибо, кэп!

I> Оптимизации это практически всегда тупая императивщина с указателями, сайдэффектами, всякими низкоуровневыми хаками. Здесь комментарии просто обязательны, т.к. код тупо не сообщает всей инфы.

Я ровно это же и сказал.

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>> Код без комментариев в функциональном стиле с правильными именами, без злоупотребления лямбдами и неявными конструкциям читается очень легко и просто.

H>Спасибо, кэп!

Ты недавно был с этим несогласен

I>> Оптимизации это практически всегда тупая императивщина с указателями, сайдэффектами, всякими низкоуровневыми хаками. Здесь комментарии просто обязательны, т.к. код тупо не сообщает всей инфы.

H>Я ровно это же и сказал.

Это значит, что разница как раз в порядок

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

I> I>> Код без комментариев в функциональном стиле с правильными именами, без злоупотребления лямбдами и неявными конструкциям читается очень легко и просто.

I> H>Спасибо, кэп!

I> Ты недавно был с этим несогласен

Где ты это узрел?

I> I>> Оптимизации это практически всегда тупая императивщина с указателями, сайдэффектами, всякими низкоуровневыми хаками. Здесь комментарии просто обязательны, т.к. код тупо не сообщает всей инфы.

I> H>Я ровно это же и сказал.

I> Это значит, что разница как раз в порядок

Ничего подобного. Можно писать код с указателями, читать который будет так же просто, как обычный. Сайд-эффекты штука конечно малоприятная, но на порядок не тянет никак.

avalon 1.0rc3 rev 368, zlib 1.2.3

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

I>> Это значит, что разница как раз в порядок

H>Ничего подобного. Можно писать код с указателями, читать который будет так же просто, как обычный. Сайд-эффекты штука конечно малоприятная, но на порядок не тянет никак.

Это когда ты освоил все эти техники и поварился в этом хотя бы пару лет, то только в этом случае читать будет просто.

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

I>> Это когда ты освоил все эти техники и поварился в этом хотя бы пару лет, то только в этом случае читать будет просто.

H>Так для низкоуровневых оптимизаций вообще подготовка требуется

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

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

I> I>> Это когда ты освоил все эти техники и поварился в этом хотя бы пару лет, то только в этом случае читать будет просто.

I> H>Так для низкоуровневых оптимизаций вообще подготовка требуется

I> Конечно требуется. Но это не значит, что на чужом проекте ты сможешь читать оптимизированый код так же легко как и неоптимизированый.

А никто и не говорит об одинаковой легкости

avalon 1.0rc3 rev 368, zlib 1.2.3

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

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

I>>>В том то и дело. А для распознавания изображений такое дело не подходит, потому что здесь сразу все случаи вместе взятые.
G>>Что ты имеешь ввиду "для распознавания изображений"? Распознавание капчи — не распознавание изображения?

I>Я имел ввиду более общий случай, а не капчу. Капча это достаточно простой случай.

I>Тебе, например, заранее известно, что там будет. Т.е. не надо думать, если в капче текст или нет.

I>Если есть капча, то и ежу понятно, что там будет какой то текст.

I>А представь, как быть например в том случае, когда нужно анализировать видеопоток или фотографии.
Представил, и че?

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

G>>Все алгоритмы "распознавания" распознают вполне конкретные вещи на изображениях, напрмиер текст, лица итп.
I>Спасибо, капитан очевидность.
А ты с чем спорить пытаешься?

I>>>Потому может используется нейронная сеть, например, как классификатор
G>>Логики вообще не понял. Ты что классифицировать собрался?

I>Ты просто не в теме, да и всё

Конечно не в теме, ты тему куда-то увел, но никому не сказал.

I>Открой ссылку которую я тебе дал да посмотри, сразу поймешь что такое классификатор в обсуждаемо контексте.
Мне лень там все читать. Вкратце суть можешь сюда выложить.

A>>>

A>>>public class Buffer {
A>>> byte [] buffer;
A>>> int offset;
A>>>}
A>>>

2 переменных всегда лучше, чем одна?

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

E__>Ну дык логично — писать-то на управляемых языках проще. Та же ждава по количеству и качеству написанных либ оставляет далеко позади все другие существующие технологии. Что, само по себе, только ускоряет процесс разработки. Да и портирование с С++ на джаву дело несложное, хоть и рутинное. А вот обратное, да особенно если в коде используется динамическая сериализация и прочие рефлекшены — тот еще геморрой.

Странно...
Когда пытался найти что-то в готовом виде, попадался код в основном на чистом С или фортране,
изредка более-менее аккуратные классы на CPP.
Хотя, конечно, о чем это я, найти новые алгоритмы на жаве.
Там они лет через 10-20 появятся

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

G>ЗЫ. Ты снова не показатель. Большинство программистов C++ не осилят асинхронное чтение из файла.

Даже не рискну пытаться объяснять среднему дот-нетчику, что это такое

A>Суперпроизводительные шахматные программы теперь нужны только нердам, вроде тебя.

Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

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

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

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

A>>Суперпроизводительные шахматные программы теперь нужны только нердам, вроде тебя.

B>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

В играх как-то больше lua и питон популярен.

B>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

ИЛ-2-Штурмовик в своё время написали

А вообще есть несколько причин отсутствия топовых игр на Яве

— Кросс-платформенная разработка. ПС3 и ХБокс360 Яву не умеют

— Существующий инструментарий — движики, библиотеки и прочее. Переписывать и переучивать людей займёт время, а в геймдеве срок выпуска игры очень важен.
— Опыт разработчиков. Они закоренелые сишники и просто не видят смысла оглядываться вокруг. Опять же издатель обычно давит сроками, нет времени переучиваться и заново набивать шишки.

При этом я лично уверен, что для сервер-сайда для всяких ММО* игр Ява используется очень плотно (доказать не могу

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

HA>>2 переменных всегда лучше, чем одна?

A>Чувак, нельзя обойтись одной переменной там, где требуется две.

A>Если у тебя есть буфер и смещение внутри него, то это ВСЕГДА две переменные. То, что в ф-цию передаётся только одна из них, не значит, что второй не существует.

Достаточно знать начало и конец интервала.
А где на самом деле буфер начинается и заканчивается, откуда взялся — должно быть пофигу алгоритму обработки,
он просто не должен обращаться вне указанного интервала.
Т.е. пользователь алгоритма отвечает за параметры, какие дал на вход,
создатель — за корректность работы.

Удобно, правда?

HA>Удобно, правда?

ok

public long process_line(InputStream s) {
 int res = 0;
 for (int b = s.read(); b != -1; b = s.read()) {
   res += b;
 }
}

process_line(new ByteArrayInputStream(data, offset, some_value));

1) У ф-ции на один параметр меньше, чем у исходного кода на С.
2) Не стукнет по памяти. Никогда.
3) b]Стандартный[/b] интерфейс InputStream позволяет передать поток хоть из файла, хоть из сокета, хоть из ZIP архива.

Удобно, правда?

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

B>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

Y>В играх как-то больше lua и питон популярен.
Для скриптинга, да.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

B>>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

Y>>В играх как-то больше lua и питон популярен.
CC>Для скриптинга, да.

Для логики. Ну а остальное покупается. Практически никто не пишет кросплатформенные движки самостоятельно.

Если взять middle range игр с бюджетами 200-400к долларов — то я думаю для новых проектов, на интерпритируемых языках кода пишется чуть ли не больше чем на компилируемых.

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

I>>Надо например выдрать автомобильные номера — сначала надо найти кадр где есть номер. Потом вычленить сам сегмент с номером а уже потом распознать собственно сам номер.
G>и?
G>Будет композиция алгоритмов распознавания. Сначала работает то что алгоритм нахождения номера, а потом то что распознает текст.

Задача распознавания надписей радикально отличается от задачи прочтения капчи. Для капчи тебе классификатор вобщем и не нужен.

G>При этом само распознание текста может разными алгоритмами делать.
G>Думаешь алгоритм распознавания текста в таком случае будет сильно отличаться?

Да, будет и это очевидно — надписи могут как угодно отличаться друг от друга только характеристиками представления.

В капче картинки имеют одинаковые характеристики представления.

G>>>Все алгоритмы "распознавания" распознают вполне конкретные вещи на изображениях, напрмиер текст, лица итп.
I>>Спасибо, капитан очевидность.
G>А ты с чем спорить пытаешься?

Не я пытаюсь, а ты хочешь углядеть спор там где его нет.

I>>Ты просто не в теме, да и всё

G>Конечно не в теме, ты тему куда-то увел, но никому не сказал.
I>>Открой ссылку которую я тебе дал да посмотри, сразу поймешь что такое классификатор в обсуждаемо контексте.
G>Мне лень там все читать. Вкратце суть можешь сюда выложить.

Чуть выше было от Nuzhny:

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

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

B>>>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

Y>>>В играх как-то больше lua и питон популярен.
CC>>Для скриптинга, да.

Y>Для логики. Ну а остальное покупается. Практически никто не пишет кросплатформенные движки самостоятельно.
Более того, много кто писал движки щас не в очень хорошем фин. положении.

Y>Если взять middle range игр с бюджетами 200-400к долларов — то я думаю для новых проектов, на интерпритируемых языках кода пишется чуть ли не больше чем на компилируемых.
Что понимать под middle range? Казуалки?
Что то из знакомых казуальщиков всё С++ да Flash.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Потому может используется нейронная сеть, например, как классификатор
Нейронная сеть, без аппаратной поддрежки, всё равно смысла не имеет.
Намного прямее как-то явно задавать соответсвующие классам области пространства принаков...

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

E>Нейронная сеть, без аппаратной поддрежки, всё равно смысла не имеет.
E>Намного прямее как-то явно задавать соответсвующие классам области пространства принаков...

ИМХО, тут вся проблема в сложности задания таких признаков. Разного вида автоматические классификаторы (не только нейросети), обучающиеся по некоторой выборке, используют как раз в тех случаях, когда вручную задать правила становится слишком сложно. Или когда это надо делать очень часто.
Нейросети — это всего лишь один из способов, зачастую не самый оптимальный. Однако для них доказано достаточно много теорем, в соответствии с которыми можно чётко обозначить круг их применимости. Данный факт значительно понижает риски при выборе нейросетей и способствует их популярности. Во многих случаях их "рвут" SVM, boosting, random forest и т.п. Но иногда — нет.

P.S. Кстати говоря, на GPU нейросети очень неплохо ускоряются. Это можно считать аппаратной поддержкой?

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

N>ИМХО, тут вся проблема в сложности задания таких признаков. Разного вида автоматические классификаторы (не только нейросети), обучающиеся по некоторой выборке, используют как раз в тех случаях, когда вручную задать правила становится слишком сложно. Или когда это надо делать очень часто.
Дык сеть признаки не задаёт. Она уже в пространстве признаков работает...

N>Нейросети — это всего лишь один из способов, зачастую не самый оптимальный. Однако для них доказано достаточно много теорем, в соответствии с которыми можно чётко обозначить круг их применимости. Данный факт значительно понижает риски при выборе нейросетей и способствует их популярности. Во многих случаях их "рвут" SVM, boosting, random forest и т.п. Но иногда — нет.

Ну да, но в целом не понятно от чего бы просто как-то геом. места классов в пространстве признаков ПРЯМО не задавать...

N>P.S. Кстати говоря, на GPU нейросети очень неплохо ускоряются. Это можно считать аппаратной поддержкой?
Ну где-то, как-то, но для SVM, например, эта поддержка не хуже, а скорее даже лучше подходит

Главный косяк сетей -- их склонность к переобученности. Граница геоммест классов в пространстве признаков может быть слишком кучерявой...

При этом плохо и то, что она может такой быть, и то, что ты про это не узнаешь никак.

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

E>Дык сеть признаки не задаёт. Она уже в пространстве признаков работает...

Да, не задаёт. Но умеет несущественные признаки отсеивать — просто весовые коэффициенты у них будут нулевыми.

E>Главный косяк сетей -- их склонность к переобученности. Граница геоммест классов в пространстве признаков может быть слишком кучерявой...

E>При этом плохо и то, что она может такой быть, и то, что ты про это не узнаешь никак.

По косвенным признакам догадаться можно: ошибка на обучающейся выборке уменьшается, а на контрольной — нет (или даже растёт).

P.S. Я сам не очень люблю с ними возиться, но как-то раз пришлось.

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

HA>>Удобно, правда?

A>ok

A>[java]
A>public long process_line(InputStream s) {
A> int res = 0;
A> for (int b = s.read(); b != -1; b = s.read()) {
A> res += b;
A> }
A>}

A>Удобно, правда?

Конечно, именно из С++ и пришел такой подход
Никто же не заставляет всегда пользоваться голыми указателями

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

E>>Дык сеть признаки не задаёт. Она уже в пространстве признаков работает...

N>Да, не задаёт. Но умеет несущественные признаки отсеивать — просто весовые коэффициенты у них будут нулевыми.

Ну, на языке геом. мест это будет обозначать, что геомместа классов будут гиперцилиндрами, или очень вытянутыми фигурами...
Сеть -- это просто описание областей в пространстве. Только очень непрямое.

N>По косвенным признакам догадаться можно: ошибка на обучающейся выборке уменьшается, а на контрольной — нет (или даже растёт).
Ну логичнее, IMHO, сразу юзать такое представление геоммест, которое не сможет представить слишком переобученный классификатор

N>P.S. Я сам не очень люблю с ними возиться, но как-то раз пришлось.
Не ясно зачем. Можно было просто как-то геомместа аппроксимировать и всё.

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

HA>>Конечно, именно из С++ и пришел такой подход

A>Честно говоря, 90% использования потоков в С++ — это описание их возможностей в учебниках, а остальные 10% — это вывод в файловый лог. И только в Яве потоки используются на полную катушку.

Не-а. Например, http://www.boost.org/doc/libs/1_45_0/libs/iostreams/doc/index.html

Я же не ругаю яву за то, что в ней буста нет

В каждом языке свои успехи, и С++ развивается тоже, причем интенсивно.

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

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

B>>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

A>>ИЛ-2-Штурмовик в своё время написали

B>Там вроде для рендеринга и отрисовки С++ использовался, а java была только для high level скриптования. Не?

Кстати вот подтверждение нарыл

Next urban legend says, that IL-2 is coded in Java. Again, this assumption is based on rumors only, and has no substance. Java is used in IL-2, but just in small part. C++ is mostly used in coding this baby.

A>>ИЛ-2-Штурмовик в своё время написали

B>Там вроде для рендеринга и отрисовки С++ использовался, а java была только для high level скриптования. Не?

Трудно сказать не зная всей внутренней кухни. Очевидно, Ява напрямую не умеет к видеокарте обращаться, значит была ДЛЛ. Как между этой ДЛЛ и Явой делились обязанности, я не знаю.

Вот пример стэка при исключении http://forums.ubi.com/eve/forums/a/tpc/f/49310655/m/3571021148

Видно, что некоторое управление рендерингом было и в Яве, но в какой степени — хз.

HA>Не-а. Например, http://www.boost.org/doc/libs/1_45_0/libs/iostreams/doc/index.html

Вообще, судя по году выпуска библиоеки iostreams (2005), её делали под очень сильным влиянием Явы.

HA>Я же не ругаю яву за то, что в ней буста нет

Буст это просто набор библиотек, а не фича языка. Под Яву библиотек не меньше.

HA>В каждом языке свои успехи, и С++ развивается тоже, причем интенсивно.

Если ты не заметил, то обращаю твой внимание — я не утверждал что "С++ хуже", я утверждал, что "Ява не хуже". Так что защищать С++ в моих глазах не надо

B>Кстати вот подтверждение нарыл

Подтверждение от бета-тестера? Чем это отличается от упомянутых "rumors"?

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

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

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

B>>>>Ну тогда вместо шахмат путь Crysis на джаве напишут. Можно будет на линуксе погаматься

A>>>ИЛ-2-Штурмовик в своё время написали

B>>Там вроде для рендеринга и отрисовки С++ использовался, а java была только для high level скриптования. Не?

B>Кстати вот подтверждение нарыл

B>

B>Next urban legend says, that IL-2 is coded in Java. Again, this assumption is based on rumors only, and has no substance. Java is used in IL-2, but just in small part. C++ is mostly used in coding this baby.

Ерунда какая-то. Хотя нужно уточнить каких из IL-2.
В самом первом IL-2 рендер был на С++, на java все что выше — надстройка над рендером, интелект, сеть и прочее, прочее. Достаточно много всего.
И это при том что тогда о компиляции байткода в нативный только, только можно было говорить да и то с натяжкой.
Т.е. в IL-2 местами был чистый байт код и это без всяких JIT и прочее.

Но блин, это же практически прошлое тысячилетие — и ява, и игры, и графические движки поменялись на столько координально, что нафиг вам обсуждать IL-2?

	От:	Pavel Dvorkin
	Дата:	03.12.10 17:06
	Оценка:	3 (1) +3

	От:	Тот кто сидит в пруду
	Дата:	03.12.10 17:07
	Оценка:	+1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	03.12.10 23:26
Оценка:	-7

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	04.12.10 22:12
Оценка:	-1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	05.12.10 12:44
Оценка:	-3

	От:	CreatorCray
	Дата:	03.12.10 23:01
	Оценка:	2 (2) +5

От:	okman	https://searchinform.ru/
Дата:	03.12.10 15:26
Оценка:	+6

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	05.12.10 12:24
Оценка:	1 (1) +3

От:	Mystic	http://mystic2000.newmail.ru
Дата:	03.12.10 16:38
Оценка:	+1 -1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	03.12.10 17:53
Оценка:

	От:	minorlogic
	Дата:	04.12.10 11:32
	Оценка:	1 (1)

От:	мыщъх	http://nezumi-lab.org
Дата:	03.12.10 16:00
Оценка:	-1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	04.12.10 15:11
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	03.12.10 15:56
Оценка:

От:	Young	yunoshev.ru
Дата:	04.12.10 17:53
Оценка:

	От:	avpavlov
	Дата:	08.12.10 07:43
	Оценка:	+1

	От:	avpavlov
	Дата:	07.12.10 07:41
	Оценка: