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 (все равно надо руками следить).

Здравствуйте, 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? Там не так уж много кода Было бы желание.

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 от случайного значения??

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


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

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

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

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

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

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