Вопрос по коду

Вернулся к листу 186 , сорт 1193!!!, счет 732

Предлагаю не засирать ленту кодом не относящимся к теме

Распарсить на слова и посчитать их можно в одном цикле.

Вообще, на кой чёрт ты взял плюсы, если ты не умеешь их толком использовать? Бери что тебе ближе и роднее; метлу, например.

Один вариант долго считывает и слова такие: «wods weew/sdffssd ----- , а 2й надо разобрать еще и всё больше нет.

Это еще посмотрим кто что возьмет

Тот же лист без сортировки 200 и 715, отсюда следует что вариант http://programmersforum.ru/showthread.php?p=1625057&posted=1#post1625057 не подходит для поиска в листе

Вернулся к вектору: 1 тест показал: Если считывать не в лист а вектор то 319 , его сорт 169 , в целом 790 без времени считывания 2 тест: 379 ч,без сортировки,счет 655 секунд. Видно что предварительная сортировка Не влияет на скорость подсчета и поиска моего алгоритма. Непонятно в чем причина расхождения в минуту(есть идея что дела в количестве и порядке подключения хидеров , и (либо) может мой процессор очень говёный )! при считывании файла, да и ваще непонятно(даже при условии что у него машинка мощнее) что у петушни 2хглавой в 100 раз быстрее выполнился код по обоим показателям , пусть пересчитает заново закоменченную программу с дропыча и файл ~56 мегабайтный или свой и сбросит мне его для проверки. Ну а если повторится то значит что мой вариант прогограммы на его машине займёт где-то секунд 10, а это значит , что цель достигнута. Есть вариант саботажа или посчитаю под иксами

Чего-то у тебя больно долго оно работает. Не думаю, что здесь дело только в неоптимальном алгоритме чтения у меня (в идеале стоит читать буферами большого объема, а не по слову. Не думаю, что ifstream гарантирует такое - хотя в доки не лазил). Да и время сортировки очень отличается, хотя не должно. Покажи код.

з.ы. и да - здесь незачем читать в вектор, т.к. потребуется выделять новую память под весь вектор на каждое слово, не? Это всё же может быть затратным. Что до сортировки - как минимум - тебе незачем сортировать весь контейнер с кучей повторов. Ты должен отсортировать ключи словаря (кстати, в случае с std::map - должны и так ведь, не?)

Даже на нескольких языках, блин. Можно сразу идти на питоножуниора и одмина (или кому там сейчас чаще нужен шелл)

Не парь меня этим , напиши время моей программы и файла моего запусти ничего не исправляя

ПОМОГИТЕ ВЫПОЛНИТЕ ПРОГРАММУ ССЫЛКА САМ ПОСТ И ВСЁ

Профайлером научись пользоваться.

И головой.

«Не парь меня этим» Подробностями работы контейнеров (ну как подробностями - подробостечками)? По моему ты как-то неправильно подходишь к делу - для того, чтобы прикинуть что лучше ты должен из знать (или ты планируешь юзать только новую методику stackoverflow LOR driven development?)

«напиши время моей программы» Какой из? Мне влом копаться в треде. Тебе может тоже влом, но кто тут заинтересованная сторона?

Так вообщем решил использовать бинарный поиск для вектора(пока не использовал):

1 тест: Если считывать не в лист а вектор то 319 , его сорт 169 , в целом 790 без времени считывания.

2 тест: 310, 210, и 703 без 1-го и 2-го показателя.

Как видно из прошлых тестов не ускорить не время считывания не сортировки(без кардинальных изменений). Тогда будем ускорять самую долгую часть работы программы. Как сказано чем больше массив тем выгоднее этот поиск. Уже предварительно сортировав. Т.е. 500 секунд и петуха это должно быть 5 секунд. Он что то подозрительно не хочет повторить тест, ну ладно справлюсь без посторонних помощи(помех).

Т.е. 500 секунд и петуха это должно быть 5 секунд.

Т.е. 1 петуха == -495 секунд. Попробуй вставить в программу побольше петухов, это должно её ускорить.

держи нас в курсе

Так вообщем решил использовать бинарный поиск для вектора

Зоганый свет, так усложнить задачу на std::map. Кстати, ведь можно совместить чтение и подсчёт - просто сразу по чтению обновлять счётчик в std::map-е.

Он что то подозрительно не хочет повторить тест, ну ладно справлюсь без посторонних помощи

Может тебе ещё нотариально заверенный скриншот дать?

Доктор, скольким петухам в программе соответствует аватарка на ЛОР-е, и удваиваются ли показатели от двухголовсти? А то я заметил некоторый прогресс в последний месяц :-)

Мда не заметил что предложения в векторах, а не слова придётся сделать новый набор и посмотреть результаты , что займёт еще минут 30 - погорят все сроки дедлайна с такой проблемой сталкнулся впервые что ~60 мегабайт памяти файла привращаются в 700 мегабайт памяти оперативы , что же интересный факт

Двухголовая аватарка соответствует 2 (двум) петухам, которые, в свою очередь, эквивалентны -980 (минус девятистам восьмидесяти) секундам.

Вот оно как, а я-то думал что это от того, что переписал числодробильную часть проекта на numpy.

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

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Read time:3.788
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

При сброке последним MinGW-м g++ без дополнительных опций. Так что звиняй, твой алгоритмический гений не оценен. Но я могу подтвердить, что оно чего-то молотило более 10 секунд.

Значит разделил на слова:

187 чтение, 367 разделение и сортировка,852 подсчет и добавление.

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

Тоже попробовал запустить его код. Вывалился по памяти (а её у меня 16 гигов). Попробовал запустить код invy, получил около 1,4 сек. От запуска к запуску меняется от 1,38 до 1,43. На чём ОП запускает, непонятно. Восемьсот секунд! Какая-то жуть.

Теперь ты можешь узнать, зачем нужны CVS вообще и git с github в частности. Какой-то общеобразовательный тред.

Вообще говоря - я бы на твоём месте копал в сторону профайлера. Ладно бы чтение (спишем на диск, ФС и прочую зрень) - но простая операция над std::map и std::list у тебя, видишь ли, долго работает - явный непорядок.

Вот текущий запустите через минут 5 я его не правлю для ваших тестов

Мой запускал, кстати? Интересен разброс. Сотни секунд - какая-то совсем уж жуть. Ну не atmega8 же его пускают, в самом деле.

твои результаты * 100

Вот текущий запустите

Та же фигня:

$ time ./testtaskjunior 
Read time:1.6439
Killed

real	0m48.638s
user	0m42.588s
sys	0m3.824s

Кстати, если в коде invy поменять isalnum на isalpha, будет примерно одна секунда на всё. Это если развязать C++ потоки с stdio. Иначе около четырёх секунд где-то.

Ответ на: комментарий от i-rinat 03.08.2016 20:16:12

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

Мой запускал, кстати?

(собираю gcc 4.9 с O3 под debian jessie)

Твой крестовый код:

Read time : 1769 ms
Count time : 1816 ms

без синхронизации с stdio:

Read time : 1654 ms
Count time : 1824 ms

Хм, у меня оно ещё и безбожно тормозило значит. Ну, ждём признания мегаджуна - на чем пускал-то и как :-) ?

О! Видно , что прочел за 1.6 секунды- это отлично. Причина в том что похоже мой компилятор тормозит, а под иксами всё как надо.

Попробовал ещё вариант анонима на регулярках. 4,5 секунды.

Причина в том что похоже мой компилятор тормозит

Я бы сказал, что в твоём случае жутко похоже на то, что это главная проблема. Ну или ты таки толсто троллишь :-)

Ввиду отсутствия рабочего поиска ссылка оказалась не работо способной вот результаты исправленные:

218 сек, 235 только разбивка, 765 подсчет и сортировка с учетом коэффициента 100, выходит , что мой алгоритм на другой машине займёт 12 секунд где - то.

что прочел за 1.6 секунды- это отлично

Правильно! Главное — прочитать за 1,6 секунды. А то, что код invy к этому моменту уже 0,6 секунд как уже всё закончил, это пофигу. Главное — прочитать.

Даже интересно, как сотни получить (ну, вдруг столкнусь). Разумеется без ускоряющих циклов.

Попробовал с std::map - скорость не сильно отличается от unordered_map, но результат сортированный.

cat bigtestfile.txt  0,00s user 0,06s system 1% cpu 3,295 total
./a.out  3,22s user 0,07s system 99% cpu 3,299 total

cat bigtestfile.txt  0,00s user 0,06s system 1% cpu 3,804 total
./a.out  3,75s user 0,06s system 99% cpu 3,808 total

// да, у меня калькулятор старый :)

Крашится из-за того , что strtok нужно праверить под иксами

Попробовал с std::map - скорость не сильно отличается от unordered_map

У меня 1,7 секунд с map против 1,0 секунд с unordered_map.

Попробуй ещё std::ios::sync_with_stdio(false) в начало программы вставить. У тебя много частых чтений из потока, синхронизация сильно влияет.

// да, у меня калькулятор старый :)

Тут ещё выяснится, что твой калькулятор быстрее моего.

Крашится из-за того , что strtok нужно праверить под иксами

Чо за бред?

count[word] = 0

бугога!

Gremlin_ я бы рекомендовал сообщить, какое чудесатое сочетание калькулятора, дистрибутива и компилятора (и опций). Вдруг чего подскажут. Ну или признаться в том, что ты уже вытекаешь из треда https://2ch.hk/b/arch/2016-03-11/src/119666474/14577316247860.jpg. Ну и раз ещё чтение - ФС.

А далее, извини, не могу сдержать внутреннего Петросяна :

Чо за бред?

Ну, сейчас окажется тот крайне маловероятный случай, в котором работа иксов вызывала какой-то баг в линуксовом ядре, влияющий на stdlib-у в отдельном процессе :-)

Тут ещё выяснится, что твой калькулятор быстрее моего.

Бери выше - кластера из всех калькуляторов участников.

Это тебе не пых, 0 по умолчанию не прокатит. И да, можно, конечно, тело цикла записать иначе - но зачем, всего-то пару секунд из сотни сбросит :-)

Попробуй проверить свою отредактированную прогу у меня в файле - верхняя часть должна быть раскоменчена и вместо вывода в консольку - вывод файл должен присутствовать выложи результаты

Не о том я. 1 же надо, ну!

Допустим, вот.

$ clear; g++ test.cpp; ./a.exe
test.cpp: In function 'int gettimeofday(timeval*, timezone*)':
test.cpp:16:18: error: 'uint64_t' does not name a type
     static const uint64_t EPOCH = ((uint64_t)116444736000000000ULL);
                  ^
test.cpp:20:5: error: 'uint64_t' was not declared in this scope
     uint64_t    time;
     ^
test.cpp:24:23: error: expected ')' before 'file_time'
     time = ((uint64_t)file_time.dwLowDateTime);
                       ^
test.cpp:25:24: error: expected ')' before 'file_time'
     time += ((uint64_t)file_time.dwHighDateTime) << 32;
                        ^
test.cpp:27:33: error: 'EPOCH' was not declared in this scope
     tp->tv_sec = (long)((time - EPOCH) / 10000000L);

Кстати, твои ifdef-ы излишни c MinGW, но черт с ними. Плюс иклуд и я вижу :

Readed
Complete! Press any key and Enter!Read time : 4114 ms
Count time : 8928 ms

Выхлоп - http://pastebin.com/icFJFhun . Не без мусора, но его фильтрация или избегание не должны замедлить работу обоих стадий в сотни раз.