SH>>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. CC>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, CreatorCray, Вы писали:
SH>>>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. CC>>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить?
<skipped>
Во времена оные пришлось мне с машиной Мир-2 работать, киевского производства. У нее не было фиксированной разрядности, числа могли расти как угодно, хоть одно число на всю память. Запустил я на ней некий итерационный алгоритм, который, по моему представлению, должен был около минуты работать. Когда он через 10 минут не закончился , я его принудительно остановил и нажал на пульте "Вывод значений" (вот как тогда отладку производили ). И выдал он мне числа с десятичным порядком около 100 . Процесс разошелся, а overflow-то нет...
With best regards
Pavel Dvorkin
Re[22]: Раннее знакомство с Java калечит судьбы программисто
Это даже не жалкая породия.
SH>> итераторов CC>Уже есть в плюсах
Очень неудобные по сравнению м питоновсеими.
SH>> и GC. CC>GC — зло в общем случае. + плохо сочетается с ручным управлением памятью.
В общем члучае GC все таки добро, в частностях да бывает и зло, но в том же питоне GC как раз на счетчиках и поэтому добрый так как не умеет внизапно тормозить
SH>>И лямбд. CC>Ну, вот чего нет так нет CC>Насколько я понимаю, без GC они кривовато реализуются...
Лямбдам на GC плевать. Но лямбды обычно всегда идут в комплекте с замыканиями, а замыкания без GC да сплошной гемморой.
SH>>И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта. CC>ИМХО реализуемо и в С++. Разумеется не так прозрачно
Угу как всегда очень коряво
SH>>Я не могу назвать что-то одно или исчерпывающий список. Я просто рекомендую тебе попробовать Питон. CC>Пробовал. Дописывал функционал в готовой проге когда то давно... В проекте часть функционала вынесена в питоновские скрипты. Причем солидный такой кусок. CC>Что могу сказать — скриптовый язык он и есть скриптовый...
И?
SH>>Причина — С++ слишком заботится о байтах. О машинном представлении. Даже если это скрыто внутри класса, это всегда приходится держать в уме. CC>Т.е. думать надо о том, что получится перед тем как писать?
Думать к сожалению ( ) приходится не зависимо от используемого языка
CC>Мелочь писать на нем и всякие управляющие скрипты — можно. То, что не требует особой скорости — тоже. Но блин, почему как только человек открывает для себя новый язык он тут же стремится писать на нем все подряд?!
Это и к C++ относится.
Я вот сейчас на трех языках пишу, один из них C++ и ничего нормально.
И сейчас вполне реально для меня использовать C++ только как интерфейс для общения с OS.
Re[23]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, FR, Вы писали:
SH>>>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. CC>>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить?
Вопрос из любопытства, как человека, который занимается алгоритмами математики с большими числами — а сколько оно это считало?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, FR, Вы писали:
SH>>>>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. CC>>>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить? CC>Вопрос из любопытства, как человека, который занимается алгоритмами математики с большими числами — а сколько оно это считало?
Практически моментально, нажал enter и консоль практически сразу выплюнуло ответ. Вообще считает же хорошо оптимизированный сишный код внутри интерпретатора.
Re[23]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, FR, Вы писали:
SH>>> итераторов CC>>Уже есть в плюсах FR>Очень неудобные по сравнению м питоновсеими.
Мм... А можно "на пальцах" разницу показать?
CC>>GC — зло в общем случае. + плохо сочетается с ручным управлением памятью. FR>В общем члучае GC все таки добро, в частностях да бывает и зло, но в том же питоне GC как раз на счетчиках и поэтому добрый так как не умеет внизапно тормозить
Это гут.
FR>Лямбдам на GC плевать. Но лямбды обычно всегда идут в комплекте с замыканиями, а замыкания без GC да сплошной гемморой.
Это я и имел в виду.
SH>>>И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта. CC>>ИМХО реализуемо и в С++. Разумеется не так прозрачно FR>Угу как всегда очень коряво
Ну не надо передергивать. Не "как всегда" и не так уж "очень коряво".
SH>>>Я не могу назвать что-то одно или исчерпывающий список. Я просто рекомендую тебе попробовать Питон. CC>>Пробовал. Дописывал функционал в готовой проге когда то давно... В проекте часть функционала вынесена в питоновские скрипты. Причем солидный такой кусок. CC>>Что могу сказать — скриптовый язык он и есть скриптовый... FR>И?
Не понравился. Как скриптовый язык по мне LUA несколько лучше с точки зрения юзабилити и интеропа. Хотя опять таки от задач зависит.
CC>>Т.е. думать надо о том, что получится перед тем как писать? FR>Думать к сожалению ( ) приходится не зависимо от используемого языка
К сожалению, не все так считают. И при написании прог на управляемых языках наивно верят что можно ни о чем не заботясь фигачить "что вижу о том и пою". Ну и огребают потом проблем и удивляются, как так вышло.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, FR, Вы писали:
SH>>>>Питон относится к этому проще.. Например, Питоновский int никогда не переполняется. CC>>>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить? CC>Вопрос из любопытства, как человека, который занимается алгоритмами математики с большими числами — а сколько оно это считало?
Вот это
from time import clock
t1 = clock()
x = 287368235523**1024 * 76523876532**512
t2 = clock()
print t2 - t1
печатает (p4 2.8)
0.00779449739352
Re[3]: реальная проблема на Java - помогите решить
Здравствуйте, mik1, Вы писали:
M>Ну то, что при росте траффика до 100% от одного процессора доберетесь — это, думаю, очевидно. Ну это лирика.
Да, но когда ? Если там всего 5% уходит, это одно. Если 28% — очень сильно другое.
M>Какой процент от общего времени уходит на поток записи — это тоже лирика.
Кстати, кто мешает сделать несколько потоков записи?
А зачем ? Поставщик-то один, и очередь одна. Система один писатель — один читатель. Что я получу от нескольких читателей, крое оверхеда на переключение потоков ?
M>А вот про одну пару машин ничего не ясно. Можете привести такие же 4 цифры, какие приводили для двух пар машин? Тогда и станет ясно, где узкое место с ростом траффика будет.
Итак
2 пары машин (повторяю)
YourKit
Поток записи — 28% суммарного времени, из них 16% на poll, 12 — на запись в БД, остальное почти нули
JProfiler —
Поток записи — 5% суммарного времени, из них 2% на запись в БД, 2% на мой код, о котором речи не было, 1% по мелочам. poll не упоминается.
1 пара машин
YourKit
Поток записи — 34% суммарного времени, из них 21% на poll,14% на запись в БД
JProfiler —
Поток записи — 2.1% суммарного времени, из них 0.8% на запись в БД, 1% на мой код, 0.3% по мелочам. poll не упоминается.
В общем, похоже, что YourKit приплюсовал сюда время ожидания. Писатель-то не ждет (кроме лока), а вот читатель все время ждет — он быстрее, а точнее, писатель пока медленнее — трафик небольшой, он трафика ждет.
Если 2% на пару машин — это пока что еще оптимистично. Тем более там мой код, это не очередь явы оптимизировать
Правда, остается неясным, почему у YourKit столь велико время операций с БД. Хотя, мб, он и там включил время ожидания ответа.
Спасибо.
With best regards
Pavel Dvorkin
Re[24]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, FR, Вы писали:
SH>>>> итераторов CC>>>Уже есть в плюсах FR>>Очень неудобные по сравнению м питоновсеими. CC>Мм... А можно "на пальцах" разницу показать?
Итераторы напрямую подерживаются языком, поэтому они гораздо безопаснее и мощнее, например легко делать цепочки функции обрабатывающих итераторы практически в стандартной библотеке http://docs.python.org/lib/itertools-functions.html есть набор повторяющий базовый для функциональных языков.
а на пальцах
for x in array:
вместо
for(my_vector::iterator it = array.begin(); it != array.end(); ++it)
SH>>>>И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта. CC>>>ИМХО реализуемо и в С++. Разумеется не так прозрачно FR>>Угу как всегда очень коряво CC>Ну не надо передергивать. Не "как всегда" и не так уж "очень коряво".
Коряво, я например очень редко в C++ пользуюсь такими указателями и почти всегда смотрю в книжку чтобы вспомнить синтаксис, в питоне же это простое присваивание.
"Как всегда" тоже верно стоит посмотреть на boost::lambda хотя бы Хотя вот boost::python неплох.
SH>>>>Я не могу назвать что-то одно или исчерпывающий список. Я просто рекомендую тебе попробовать Питон. CC>>>Пробовал. Дописывал функционал в готовой проге когда то давно... В проекте часть функционала вынесена в питоновские скрипты. Причем солидный такой кусок. CC>>>Что могу сказать — скриптовый язык он и есть скриптовый... FR>>И? CC>Не понравился. Как скриптовый язык по мне LUA несколько лучше с точки зрения юзабилити и интеропа. Хотя опять таки от задач зависит.
Lua да хороший скриптовый язык. Питон же не хуже lua в этом качестве, но он больше чем скриптовый, на нем вполне можно и приложения реализовывать и как язык-клей использовать. А интероп у луа проще если ручками делаешь, с билиотеками же разницы нет, тот же boost::python во многом мощнее луавских оберток.
CC>>>Т.е. думать надо о том, что получится перед тем как писать? FR>>Думать к сожалению ( ) приходится не зависимо от используемого языка CC>К сожалению, не все так считают. И при написании прог на управляемых языках наивно верят что можно ни о чем не заботясь фигачить "что вижу о том и пою". Ну и огребают потом проблем и удивляются, как так вышло.
На неуправляемых тоже, я вот недавно кучу гавнокода на C++ разгребал, там такие перлы попадались что невозможно было поверить что приложение работало и не падало
Re[4]: реальная проблема на Java - помогите решить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да, но когда ? Если там всего 5% уходит, это одно. Если 28% — очень сильно другое.
Я знаю, но это не имеет отношения к тому, где именно в потоке узкое место.
PD>А зачем ? Поставщик-то один, и очередь одна. Система один писатель — один читатель. Что я получу от нескольких читателей, крое оверхеда на переключение потоков ?
Что-то мне подсказывает, что прочитать данные из сети можно быстрее, чем закинуть их в БД. Из-за этой разницы и предлагаю сделать дополнительных читателей (писателей в БД).
PD>2 пары: Поток записи — 28% суммарного времени, из них 16% на poll, 12 — на запись в БД, остальное почти нули PD>1 пара: Поток записи — 34% суммарного времени, из них 21% на poll,14% на запись в БД
Пропорция для 1 пары машин: 3 к 2, для 2 пар машин — уже 4 к 3. То есть процент времени на poll уменьшается, а на запись в БД растет. На самом деле, судя по времени, очень похоже, что здесь включено время ожидания (с ростом траффика оно будет стремиться к нулю).
Да, я бы еще обратил внимание на то, что при росте траффика суммарное время, съеденное потоком записи в БД, уменьшается. Может, сначала сниффер посмотреть?
Еще что прошу уточнить — БД локальная или на другой машине? Подозреваю, что удаленная.
Re[25]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, FR, Вы писали:
FR>Коряво, я например очень редко в C++ пользуюсь такими указателями
Я вообще не пользуюсь такими указателями. Просто не возникало надобности. На данный момент не могу себе представить ситуацию, в которой это было бы самым удобным решением. ИМХО если возникает такая надобность то что то не в порядке в архитектуре проги.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Раннее знакомство с Java калечит судьбы программисто
Это второй и следующие запуски. Первый был около 0.5 сек, он не в счет по понятной причине.
Спасибо. Я и не знал, что в Яве есть поддержка mmf.
Запустил я на твою программу профайлер (пришлось в цикл ее вставить). В общем, что я и ожидал — половина времени уходит на get
Ты смог сделать половину того, что в моем примере на 0.015 сек было. Там 2 основных момента это mmf и p++. Первое ты сделал, а второе все же Яве противоречит. Или придумаешь ?
Кстати, вот тут
for (int i = 2; i < (fl — 3) >> 1; i++)
я бы все же (fl — 3) >> 1 из заголовка вынес. Не меняется же fl
With best regards
Pavel Dvorkin
Re[22]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, CreatorCray, Вы писали:
SH>>Динамической типизации. CC>Для чего? SH>>А так же генераторов CC>см http://en.wikipedia.org/wiki/Generator_%28computer_science%29 раздел С++ SH>> итераторов CC>Уже есть в плюсах SH>> и GC. CC>GC — зло в общем случае. + плохо сочетается с ручным управлением памятью. SH>>И лямбд. CC>Ну, вот чего нет так нет CC>Насколько я понимаю, без GC они кривовато реализуются...
Всё это позволяет меньше думать о реализации и больше о смысле. При этом, в отличии от костылей в C++, использование всех перечисленных возможностей в коде просто и красиво.
SH>>И возможности передать в функцию указатель на метод конкретного объекта (конкретного экземпляра, this передаётся незаметно) — прозрачно и для функции и для объекта. CC>ИМХО реализуемо и в С++. Разумеется не так прозрачно
На С++ даже динамическая типизация реализуема при желании, почитай Коплиена. Только, действительно "не так прозрачно".
В C++ есть указатель на функцию-член, но к нему нужен указатель на объект. Чтобы совместить, нужно засунуть всё это в объект "КАЛЛБЕК", который имеет функцию call (очевидно, со всеми вариантами параметров) и два конструктора — один для обычных указателей на функции, а второй — для указателей на методы объектов. Пока всё хорошо (хотя и есть проблема с параметрами), но вот как ты заставишь все стандартные и сторонние библиотеки работать с твоим КАЛЛБЕК-ом?
SH>> Хотя бы — тупой пример — какой класс строк должна использовать эта библиотека? CC>std::wstring
Отличный выбор! Как насчёт COM? COM-у нужен BSTR.. Как насчёт использования этой библиотеки в приложении на ATL? У них свои строки. В приложении на MFC, на WTL, на Qt? Как насчёт "правильного юникода"? Не поручусь, но, имхо, питоновские строки работают с правильным юникодом, а не с UCS2.
CC>Т.е. думать надо о том, что получится перед тем как писать?
Я там ниже развернул, в отдельном собщении.
CC>угу. И 287368235523^1024 * 76523876532^512 тоже посчитает и будет хранить?
Мне нечего добавить к ответу FR
CC>В чем приличие?
Их достаточно для всех разумных use-case-ов и никому не приходится писать свой вариант.
CC> Но блин, почему как только человек открывает для себя новый язык он тут же стремится писать на нем все подряд?!
Чтобы понять границы. Чтобы попробовать тоже, но по новому. Кроме того, я же явно оговорил область применимости C++. Я в неё не вмешиваюсь. Правда, из неё нужно вычесть область применимости Фортрана и Ассемблера
Делай что должно, и будь что будет
Re[14]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня вышло PD>Time elapsed: 0,125000 sec PD>Line count = 718847 PD>Java 1.5, Eclipse 3.3.1.1
Ключик -server не забыли? Ну и машины то разные (C2D 6600, правда хард дешевый на 80 гиг).
PD>Спасибо. Я и не знал, что в Яве есть поддержка mmf.
Она декларируемая. Зависит от реализации JVM.
PD>Запустил я на твою программу профайлер (пришлось в цикл ее вставить). В общем, что я и ожидал — половина времени уходит на get
Я знаю. Было критически важно уменьшить кол-во get-ов в цикле. Можно было бы еще немного схитрить, оставив байтовый буфер и ища 0x0D на четных позициях, но это было бы не совсем одно и тоже. А ну совсем прямого доступа к памяти нету...
PD>Ты смог сделать половину того, что в моем примере на 0.015 сек было. Там 2 основных момента это mmf и p++. Первое ты сделал, а второе все же Яве противоречит. Или придумаешь ?
А нет смысла...
PD>я бы все же (fl — 3) >> 1 из заголовка вынес. Не меняется же fl
Я знаю. Только в отличие от вызова метода в условии for, я сомневаюсь, что компилятор здесь сам не оптимизирует.
Re[18]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, о MSVC. Я до сих пор с тоской вспоминаю MSVC 6.0. Тянул с переходом на новые версии до последнего, оставил ее когда уж совсем было нельзя. Она буквально летала на компьютерах 5-летней давности. А нынешняя только проект открывает 10-15 сек...
Чего??? У меня дома машина 4х летней давности (Athlon XP 2100, 512 Мб RAM). И VS2008 вполне нормально работает. Проект открывается секунды 2-3. Вообще, с переходом с 2005 на 2008 заметил только улучшение стабильности и поддержку C# 3.0. Работает так же быстро, разве что рефакторинг чуть помедленее. На рабочих компах просто летает, хотя и они не первой свежести. Я ещё на свой матерюсь, что не может, как рабочие, проект мгновенно открывать.
Кстати, посмотрел бы я на MSVC 6.0, если бы он обеспечивал столь же мощную работу с кодом, что и VS2008 в случае с C#. А то работал он может и побыстрее, но эффективность кодинга была раза в 3-4 меньше.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[20]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это точно. Отработала. Дал на вход файл с одной текстовой строкой длиной 534 символа (длина файла 1070 байт). Вот что она печатает PD>Это, мягко выражаясь, несколько не соответствует действительности. Там все же одна строка, а не две. И к тому же лишний символ- 0xFEFF в начале эта программа почему-то включила в первую часть строки, хотя его надо было опознать как признак Юникодного файла и в строку не включать .
а кто тебе сказал что она по строкам считывает файл? ... ты там еще что-нить припиши и потом повозмущайся ... вывод количества символов ведь твоих рук дело ...
S>>кстати че там у нас со скоростью?
PD>Сначала сделай, чтобы программа работала, потом обсудим
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
M>Ключик -server не забыли?
Нет, не ставил. Куда его — в Arguments ? Добавил сейчас — то же самое. Запускаю так — RunAs — Java Application. Предварительно открыл Open Run Dialog и там в Arguments его поставил.
А зачем он нужен ? Там есть в Run Run At Server, я его и не пробовал.
Ну и машины то разные (C2D 6600, правда хард дешевый на 80 гиг).
А вот это да. У меня Athlon 4200+
M>Она декларируемая. Зависит от реализации JVM.
Я ими воспользуюсь. Переносимость меня совсем не волнует.
PD>>я бы все же (fl — 3) >> 1 из заголовка вынес. Не меняется же fl
M>Я знаю. Только в отличие от вызова метода в условии for, я сомневаюсь, что компилятор здесь сам не оптимизирует.
А вынести все же лучше. Бог его знает, соптимизирует или нет.
With best regards
Pavel Dvorkin
Re[26]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, FR, Вы писали:
FR>>Коряво, я например очень редко в C++ пользуюсь такими указателями CC>Я вообще не пользуюсь такими указателями. Просто не возникало надобности. На данный момент не могу себе представить ситуацию, в которой это было бы самым удобным решением. ИМХО если возникает такая надобность то что то не в порядке в архитектуре проги.
Архитектура тут ни причем, в других языках (да и даже в борландовском диалекте C++) широко пользуются подобными указателями. Просто это так коряво сделано, что я тоже практически этим в C++ не пользуюсь.
Re[19]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, konsoletyper, Вы писали:
K>Кстати, посмотрел бы я на MSVC 6.0, если бы он обеспечивал столь же мощную работу с кодом, что и VS2008 в случае с C#. А то работал он может и побыстрее, но эффективность кодинга была раза в 3-4 меньше.
Visual Assist + VS 6 по функциональности ни чем ни хуже VS 80 для C++.
Re[25]: Раннее знакомство с Java калечит судьбы программисто
