Перейти к содержанию

visualprog

Пользователь
  • Публикаций

    17
  • Зарегистрирован

  • Посещение

Репутация

87 Excellent

Информация о visualprog

  • Звание
    Rank №2
  1. мини бот си (линукс)

    :( Еле еле разобрал ваш "исходник". Вы делаете return 1; и не удосуживаетесь подчистить за собой. Вылетает программа, может и не из-за нехватки памяти, а из-за того что лимит открытых хендлов исчерпываете (если не ошибаюсь, по дефолту даётся не более 1024 в одни руки). Код показывать я вам, конечно же, не буду, это вам моя мстя за то что вы не показали его мне :D З.Ы. Закрывайте за собой пайпы. ИМХО, проблема требует более кординальных решений. Вам необходимо начать с теории. Желательно взять книгу по нужному вам языку. Ещё лучше её открыть. Идеалом совершенства будет если вы её прочитаете.
  2. Хорошо, буду исправляться.
  3. О чём вы, сейчас, без понимания, человек не связанный с программированием может написать целый сервер :lol: Лично мне, без пояснений, она не понятна, что вы хотите этой диаграммой показать/объяснить? Наличие простоя? Я вам предложил самостоятельно проводить замеры. В программировании далеко не всё имеет свой стандарт или эталон. Во времена когда 90% программ было написано на асме, можно было бы ответить на ваш вопрос, зная архитектуру вашего процессора и железо и ОС, причём, если ОС запускает приложение в синхронном режиме - это облегчило бы работу в разы. Сейчас же, когда ваша программа может быть как на Qt, так и на каком нибудь електроне с js, и выполнятся на 1/2/3/4 ядрах одновременно (да что там ядра процессора, берём CUDA, и ядер у вас сразу становится несколько тысяч) - как определить реально ли работает поток/процесс в текущий промежуток времени, или он простаивает? И дело даже не в том, сколько ядер, а в том, как ОС сможет распределить нагрузку (если только вы не супер-программист и не пишете распределение работы своей программы на ядра самостоятельно, вероятность чего стремится к нулю). Общие сведения о том "что быстрее", могут охарактеризовать какие то действия в программе, но, только в виде сравнения (вряд ли можно выразить количественное значение). Список таких очевидных сравнений известен большинству людей: - Самый быстрое чтение памяти - это код который использует только кэш процессора - что это может быть в вашей программе? Пишите на асме, чтобы ответить на эти вопросы, и разобраться в них. - Чтение/запись из оперативной памяти медленнее чтения/записи из кэша процессора. (на несколько порядков) - Чтение/запись с SSD медленнее чтения/записи из оперативной памяти. (на несколько порядков?) - Чтение/запись с HDD медленнее чтения/записи с SSD. (на несколько порядков) Всё это связанно между собой физикой процесса чтения/записи. Но, это не гарантирует что ваше приложение, например, на вашем ПК будет быстрее читать что то из ОЗУ чем с HDD (то есть, вы сможете прочитать файл с диска быстрее чем если бы он располагался в оперативной памяти). Почему? Потому что никто не гарантирует что ваша ОЗУ не повреждена, из-за чего скорость доступа к ней может стать медленнее :) Соответственно, на перечисленных выше сравнениях можно построить ряд других, что то на вроде: - Доступ к переменной быстрее чтения из БД. (по сути, это аналог "чтение/запись из оперативной памяти быстрее чтения/записи на HDD/SSD"). И опять же, это идеальный случай. В реальности, в конкретном случае, может быть всё не так.
  4. Про планировщик потоков/процессов я знаю, но не понимаю как это противоречит моей фразе о том что нельзя ответить на вопрос ТС? Зафиксировать статистику и визуализировать её в виде результата можно не понимая вообще что такое процесс, поток, ОС, профайлер. Но, как эта визуализированная информация поможет ТС? Чтобы ответить на вопрос "вызов А быстрее вызова Б?", необходимо не просто на время смотреть, а понимать что за вызовом стоит, и какие механизмы этот вызов обеспечивают. (тот же планировщик, который шедулер, не учитывая работу которого, можно долго недоумевать - почему использование 10 ядер может замедлить работу программы во столько же раз, хотя все вокруг кричат что многопоточность ускоряет код?) Из подводных камней профилирования - "холодный"/"тёплый" код (lazy/eager запуски и алгоритмы, наличие кеширования в "горячих алгоритмах"), учитывание текущей конфигурации системы/ПК (некоторые CPU имеют характерные только им команды, возьмёт AMD vs Intel, я не знаю что за программа у ТС, но я уверен, есть ряд оптимизаций, например, собирая одну и ту же программу на две эти архитектуры выполнение инструкций и их скорость может отличаться, вероятно, даже значительно)... я не смогу вам ответить с ходу хотябы половину таких подводных камней, более того, я не сталкивался со всеми. Но, их наличие не оставляет сомнений. Провести один заход профайлинга - это не даст объективной информации. Поэтому я и говорю, что процесс сложнее чем может показаться на первый взгляд.
  5. То есть, вы уже вкурсе что за программа у ТС? :) "Чтение сигналов от ОС" (ну, или "ожидание событий") - это настолько общая формулировка, что она описывает поведение абсолютно любой программы, и не несёт никакой полезной нагрузки в ответе, ИМХО :D Замечу, то что уже возникает несколько мнений о работе программ - так же объясняет почему я упомянул:
  6. То что вы пытаетесь узнать называется профилированием. Задача профилирования, как раз сбор такой статистики и подведения итогов. Никто не сможет вам ответить на вопрос "что работает в вашей программе быстрее". Причина проста - работа программы может зависеть от железа, от конкретной ОС, от окружения внутри ОС, от других программ, от прослойки между монитором и стулом. Самый адекватный способ ответить на ваш вопрос - самостоятельно собрать эти данные и провести статистический анализ: 1. Найдите программу-профайлер для вашего приложения. 2. Создайте благоприятную среду для профилирования (процесс очень тяжёлый в плане нагрузки на железо), например, тестовый сервер с миниальным окружением. Закиньте туда профайлер и ваше тестируемое приложение. 3. Запустите профайлер, создайте инстанс вашего приложения. Профайлер начнёт собирать ВСЁ что делает приложение и как оно это делает, начиная от файловой системы и оперативной памяти, заканчивая работой с процессором. 4. В процессе профилирования профайлер строит базу данных с параметрами и результатами считанных данных - какая инструкция или функция была выполнена, сколько было выделено памяти, сколько это заняло времени и т.д. (информации собирает огромное количество). 5. Когда профайлер соберёт достаточно информации (например, вам необходимо протестировать серверную программку, достаточно собрать сутки или двое её работы), вы сможете визуализировать собранный набор данных, найти "пики" нагрузки, что их вызывало, какие функции выделяют слишком много памяти, возможно даже, найти утечки и прочее. Если же ваша программа не является демоном/службой/фоновой задачей - тут дела обстоят сложнее. Придётся собственноручно обкатывать весь функционал программы, прокликивать все кнопки, вести штатную работу с программой под пристальным наблюдением профайлера. В такой атмосфере собранные данные будут более менее соответствовать действительности. Проблема профилирования очень обширная, её сложно описать в одном сообщении или посте.
  7. C/C++ . ASM , NASM Tutorials

    Плюсы тут: https://yadi.sk/d/2ibyTzEg37xwzP Книги по асмам в процессе изучения, когда нибудь добавлю
  8. Оба варианта правильны. 1. Случай когда POP3 объявлен как приватное поле класса TMythread. В данном случае, время жизни такого поля полностью совпадает с временем жизни экземпляра класса. Пример: При создании экземпляра класса, это поле, так же создаётся, под него отводится минимальный объём памяти (насчёт вашего языка не уверен, скорее всего, оно ещё и инициализируется, например nullptr или nil, если поле - объект). Далее, в конструкторе, вы можете создать экземпляр TPOP3send для вашего поля POP3. Замечу, именно в конструкторе, а не в методе Execute. Хотя, согласен, ваш вариант тоже имеет право на существование. 2. Случай, когда POP3 является локальной переменной в методе выполнения потока. Отличием данного варианта от первого является то, что время жизни вашей POP3 переменной ограничено одним методом Execute. Например, данный код: Оба способа являются нормальными в вашем случае. Создавая 10 или 1000 экземпляров потока TMythread и вызывая тело потока на выполнение, вы будете создавать максимум по 1 экземпляру поля/переменной POP3 для каждого экземпляра класса потока TMythread. Про "все экземпляры класса, указывающие на 1 объект" - это называется статическим полем (static field), у вас я такого не наблюдаю. Однако, стоит упомянуть критическую секцию... в такие моменты, стоит задуматься, возможно ли разделить работу на потоки, или же, это приведёт к замедлению работы программы, вызванной синхронизацией потоков, обращающихся к одному ресурсу. В вашем случае, всё выглядит более-менее безобидно. Это будет свой отдельный X для каждого потока. В обоих случаях.
  9. Программа c++, directx крашит

    Уверяю Вас, это не плюсы. То что это компилится под g не говорит о содержимом. Вы пишите на каком то псевдо-си, да, это даже не си, потому что вы не используете и их :) С чем ошибка связана вам уже сказал отладчик - во время работы программы вы пытаетесь выделить в стеке слишком много памяти. Лично я сталкивался с подобным только в бесконечных рекурсиях. Могу предлоложить, что такое возможно при выполнении goto до того как из стека очистятся данные выделенные под заголовок функции (опять же, с соответствующим зацикливанием), как можно забить стек только переменными - не знаю. Но, то что в коде что то не в порядке - это очевидно. Вот и предлагаю начать с основ. Сначала нужно думать об архитектуре. Если бы вы о ней подумали, проблем было бы в разы меньше. Я уверен что практически все глобальные переменные там не нужны. Программа ваша, что делать решать вам. Повторюсь, я ещё намекнул на параметры компиляции, которые, чисто теоретически, могли бы расширить стек (если такие команды существуют), так что, делать квадратное колесо из костылей или пересмотреть свою программу и сделать полноценный велосипед - решать не мне.
  10. Программа c++, directx крашит

    А почему бы от этого не избавиться? Вам надо чтобы программа, написанная левой пяткой с завязанными глазами отработала так как вам надо. Это ясно как день. Но, вы учитывайте, что переполнение стека возникает не от того что плохой компилятор что то там неправильно понял. Может дело именно в вашем отношении к коду? Просто взять и запусить - хз, я не знаю таких шаманств, быть может, существуют махинации с параметрами компиляции чтобы умышленно выделить память под стек ещё больше. Но, вы же продолжите делать всё глобальным, и забьёте даже расширенный стек :lol: Попробуйте посмотреть в сторону с , он намного более удобен чем тот язык на котором вы пишите.
  11. Программа c++, directx крашит

    Эта проверка даже не выполняется. У меня есть подозрения, что всё что вы привели - это лишь малая часть того что там у вас есть. Я правильно понимаю, все ваши переменные во всех модулях - глобальные? И вы не ответили, вызываете ли вы где нибудь методы рекурсивно?
  12. Программа c++, directx крашит

    Как объявлен direct3? Нет ли рекурсивных вызовов функций?
  13. Вопрос по C#

    Было бы идеально, если бы скинули хотябы скрин того о чём вы говорите... Чтобы не гадать, "что это за каталоги по HTTP?" и хотябы фагмент html с несколькими файликами и папками. (Если это действительно какая то GUI обёртка над FTP в виде HTTP, неужели из стилей элементов нельзя однозначно отличить папку от файла? Если это не обёртка, может проще (если возможно) воспользоваться фитчами протокола?)
  14. Вопрос по C#

    FTP/SFTP?
  15. Оптимизация sed

    1.5 ГиБ? за 7-8 часов??? Рекомендую описать вашу задачу подробнее, может есть смысл написать утилиту... 30-40 ГиБ можно обработать за несколько минут. У вас не такие уж и существенные объёмы данных, а времени тратите как то многовато, даже если учесть что там 100 000 регулярок. Желательно пример (небольшой фрагмент) данных в гиговом файлике, и пару примеров регулярок.
×