Странность определения размера памяти структуры

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

В результате почему-то 40...
А вот так
- вполне адекватные 32.

Кто может объяснить какого...выравнивание памяти что-ли? MSVS2008.

0

Сообщение от Retyrn0 По сколько байт в блоке читать из файла?

Это довольно стандартный подход. Такие блоки называются chunks. Размер блока зависит о нагрузки и доступных ресурсов.

Сообщение от Retyrn0 пусть сообщение может состоять из от 4 до 65536 байт.

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

0

Сообщение от DrOffset А никто с запакованными структурами и не работает. Их используют для считывания из канала или файла, а дальше полученные значения в нормальном выровненном виде используются.

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

Добавлено через 1 минуту

Сообщение от DrOffset В блок может влезать несколько сообщений. Например, будешь читать по 4 сообщения за раз, пока программа занимается их обработкой, читаешь еще 4 и т.д.

Пусть сообщение занимает 4 байта. Чтобы отдать одно сообщение, я должен считать блок, пусть в 65536 байт...как-то это не оптимизированно)

Добавлено через 1 минуту
Есть много причин того, что я выбрал именно такую структуру, просто описывать идею - довольно долго будет.

0

Сообщение от Retyrn0 Т.е. можно fread подсунуть структуру и всё будет считанно с учётом выравнивания

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

Сообщение от Retyrn0 Чтобы отдать одно сообщение, я должен считать блок, пусть в 65536 байт...как-то это не оптимизированно)

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

Вот хороший и простой пример использования этого подхода для расчета crc файла любой длины

Добавлено через 21 минуту
А вообще я изначально немного с другим уклоном писал.
Вот ты писал в первом сообщении, что тебе надо, чтобы структура занимала 32 байта. Вот вместо непереносимых плясок с упаковкой и т.п. я предложил взять массив на 32 байта и читать данные туда. А потом уже их интерпретировать как тебе надо, хочешь как несколько int32, хочешь как несколько int64 и парочку int32.
Собственно тема chunk`ов - это просто развитие дальнейшее, но уже выходящее за рамки первоначального вопроса.

0

Сообщение от DrOffset Мы про файлы или сообщения из сети

Понял) Т.е. текстовые массивы создавать такой длины, чтобы общий размер был кратен максимальному размеру элемента(INT64). Согласен - идеальное решение) Хотя я не уверен с порядком...если стоит INT32 потом char[65532] потом INT64 потом снова INT32 и char[65532], то это сработает? Сейчас поем и буду пробовать. Огромное спасибо за очевидное решение!) Как-то не сталкивался с этой фигнёй со структурами, раньше даже не задумывался, всё работало - везло) Ну и задач таких не было.

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

0

1024 потока? Не перебор?

0

Сообщение от nmcf 1024 потока? Не перебор?

Нет, в самый раз) Это потоки обработки соккетов - чтобы одновременно могло обращаться хотя бы 1024 пользователя. Примеры с динамическим созданием потоков по приходу на слушающий соккет сообщения тоже требует дополнительных ресурсов процессора. Поэтому я создаю 1024 потока сразу, а работают они поочерёдно в привязке к критической секции. Может не самый идеальный вариант, но это всё что мне пришло в голову. Думается, что работа с критической секцией чуть быстрее запуска нового потока...могу ошибаться.

0

Сообщение от Retyrn0 Нет, в самый раз)

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

0

Сообщение от DrOffset Это очень неоптимально, если конечно у тебя не 1024 процессора. Система замучается переключать контексты.

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

Сообщение от DrOffset А еще лучше что-нибудь фундаментальное про сети, потоки. Недавно куча книг переиздавалась. Тот же Танненбаум, Стивенс, из новых у Энтони Вильямса довольно неплохая книга по многопоточности в С++.

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

Добавлено через 3 минуты
Или не могли бы Вы описать как в реальных серверах делают именно эту ветку проекта - множественный доступ к сети?

0

Сообщение от Retyrn0 В примерах, которые нашёл, после acept создавался новый поток.

Так то просто примеры. Единственное достоинство такого подхода - простота.

Сообщение от Retyrn0 Или не могли бы Вы описать как в реальных серверах делают именно эту ветку проекта - множественный доступ к сети?

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

1

Сообщение от DrOffset Сама по себе многопоточность пользы не дает

Хм..ну не знаю. Вот к примеру, когда происходит чтение-запись файла у меня используется критическая секция на операцию считывани-записи из-в файл. Пусть, например, один поток получил сообщение и начал его обрабатывать - подсчитывает некоторые формулы, занимается математикой. Потом входит в критическую секцию считывания-записи файла. Эта процедура довольно медленная. В этот момент, другие потоки могут спокойно подсчитывать математику до момента считывания файла. А в один поток - считывание из файла тормозит всё и вся...разве я не прав?

Добавлено через 2 минуты
С пулом та же фигня. Почему не считать что-то пока ждём файловые тормоза?

Добавлено через 1 минуту
Или тогда сделать 3 потока: 1 слушает соккет, 2 считает математику, 3 читает-пишет файл...

Добавлено через 3 минуты
Как считаете?
ЗЫ: времени нет разбирать чужой код. Позже обязательно.

0

Сообщение от Retyrn0 Поэтому необходима максимальная скорость. Поэтому отказался от стандарного NULL-терминального символа окончания строки в конце и заменил на предваряющий размер в начале - скорость приоритетна.

Тогда учитывайте и что файл читается минимум целыми секторами (512 байт, вроде). На практике это означает что если четыре нужных вам байта влезают в сектор целиком, то вы читаете один сектор. А если два байта в одном секторе, два байта в другом, то читаете два сектора и получаете минус к скорости. После чего мы приходим к выравниванию данных и внутри файла. В самом дубовом варианте - можно завести отдельные файлы под 2, 4, 8 ... 512 байтовые блоки данных и внутри этих файлов гарантировать что блоки не наезжают на границу секторов. А блоки с размером не кратным степени двойки вообще не использовать.

1

Сообщение от Renji 512 байт, вроде

Вроде это зависит от файловой системы и от её настройки при форматировании, если ФС таковую поддерживает, но вообще да, спасибо! Как-то мне в голову не пришло это =/ Старею)

Добавлено через 2 минуты

Сообщение от Renji А блоки с размером не кратным степени двойки вообще не использовать.

А брать с запасом максимум в половину-1 байт...в худшем варианте жёсткий диск расходует почти в 2 раза больше места. Хотя скорость и важнее.

Добавлено через 58 минут
На счёт 512 байт тупанул...всем спасибо за ответы! Буду курочить.

0

Сообщение от Retyrn0 Хм..ну не знаю.

Вот зачем ты выдрал фразу из контекста? Совсем другой смысл получил, вот и не знаешь. Вот как надо было цитировать:

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

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

Сообщение от Retyrn0 В этот момент, другие потоки могут спокойно подсчитывать математику до момента считывания файла. А в один поток - считывание из файла тормозит всё и вся...разве я не прав?

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

Добавлено через 1 минуту

Сообщение от Retyrn0 Или тогда сделать 3 потока: 1 слушает соккет, 2 считает математику, 3 читает-пишет файл...

Сделай.

0

Сообщение от DrOffset Вот как надо было цитировать: Сама по себе многопоточность пользы не дает, если потоки будут постоянно блокироваться

Прошу прощения.
Вот упрощённая часть кода функции потоков:
Т.е. поток блокируется исключительно для того, чтобы одновременно только один поток мог принять новое соединение. Весь остальной функционал, кроме работы с файлом, где используется вторая критическая секция по тому же принципу, остально код работает без блокировок. Или это не особо смягчает последствия использования блокировок потоков?

Добавлено через 3 минуты
На моём довольно хиленьком ноуте, как для сегодняшних мерок Пара тысяч соединений(с 8-ми таких же ноутов) одновременно работает, проц на 7% максимум. Я поэтому не думал, что блокировка - это такая бяка.

Добавлено через 2 минуты

Сообщение от Retyrn0 Пара тысяч

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

Добавлено через 5 минут
Где-то читал, что критическая секция - довольно быстрая штука и что лучше не экономить на ней, всё равно много сэкономить не удастся. Могу попробовать найти источник цитаты.

0

Сообщение от Retyrn0 Или это не особо смягчает последствия использования блокировок потоков?

Без тестов ничего особо говорить нельзя. Вроде бы в этом коде внешне ничего страшного нет.
Но я бы не стал так делать.
Я бы предоставил слежку за соединениями основному потоку, в нем же держал список клиентов (зачем его синхронизировать вообще?). Мониторить события чтения, записи, коннекта\дисконнекта и т.п. можно через функции типа select, poll, epoll или аналоги. Они усыпляют главный поток до момента наступления какого-либо события на одном из прослушиваемых сокетов. Как только пришла задача или новое соединение, ожидание прекращается, выполняется работа по регистрации клиента, либо постановка задачи в очередь для одного или нескольких рабочих потоков (которые как раз можно объединить в пул). Вот добавление в очередь как раз и должно синхронизироваться. Кроме очереди больше ничего синхронизировать не надо. Ну а дальше твои потоки делают что нужно, пишут файлы, считают математику и т.п. По завершении своей работы они засыпают и ждут новых заданий.

Добавлено через 5 минут

Сообщение от Retyrn0 Где-то читал, что критическая секция - довольно быстрая штука и что лучше не экономить на ней, всё равно много сэкономить не удастся. Могу попробовать найти источник цитаты.

Дело не в критической секции. В приведенном отрывке синхронизация только одна, на соединении. Вроде бы ничего страшного в этом нет. Но что там у тебя дальше с данными будет я не знаю. Поэтому естественно никаких прогнозов давать не буду.
Я говорю в общем про архитектуру приложения, про распределения ответственностей. Инструменты выбирать конечно важно подходящие, но дело сейчас не в них, а в принципе, подходе к задаче. Если, например, три потока постоянно синхронизируют (не важно с помощью чего) одну переменную по кругу, то это вносит в их работу ту синхронность, которую как раз нужно бы преодолеть. Отсюда и польза от многопоточности падает, начинаются тормоза и т.п.

1

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

Кроме слушающего соккета и файл у потоков нет общих ресурсов, так что в этом плане порядок)

Сообщение от DrOffset функции типа select, poll, epoll или аналоги. Они усыпляют главный поток до момента наступления какого-либо события на одном из прослушиваемых сокетов

connect вроде блокирует поток до появления нового соединения, а с клиентскими keep-alive - это да, спасибо, скорее всего так и поступлю.

Сообщение от DrOffset Без тестов ничего особо говорить нельзя.

Абсолютно согласен. Сейчас доделаю что есть, со временем для себя переделаю на предложенный вариант - сравню. Если что напишу результаты, хотя к тому времени может много воды утечёт)
ИМХО, поточная очередь несколько "прозрачнее" пулов с основным и вспомогательным-ми потоком-ми. Здесь не нужно учитывать ничего лишнего. Поток, который раньше закончил вычисление и ответил клиенту - раньше обратился за новыми данными. Если вдруг сервер не будет успевать считать ответы, то он просто не будет слушать никого, пока хоть один поток не завершится. Потоки мне показались более понятными и прозрачными.

Пул: основной поток принял данные, проверил, грубо говоря, есть ли место в пуле, если есть - добавил. Обработчик должен проверить не пуст ли пул. Если пуст, то ждать, если не пуст, то взять данные и "оповестить" пул о том, что эти данные пошли по-рукам.
Потоки: Фактически та же реакция, только более естественная что-ли, без проверок дополнительных. Есть возможность - считаем, нет возможности - игнорим. При желании, конечно, можно вставить дефалтный поток, который при занятости всех остальных будет отправлять некий стандартный ответ о том, что занято, например html рефрешер с задержкой в секунду...много идей, мало времени)

0

Сообщение от Retyrn0 connect вроде блокирует поток до появления нового соединения, а с клиентскими keep-alive - это да, спасибо, скорее всего так и поступлю.

connect можно сделать неблокирующим, вместо этого блокировать будет select/poll/epoll. Преимущество в том, что все события на сокетах, а не только коннект, можно обрабатывать единообразным лаконичным кодом. C poll или epoll будет еще красивее Почитай про них, все-таки, хотя бы тут (да, epoll - это только linux, но здесь больше важен принцип, в windows есть аналогичные инструменты).

0

Сообщение от DrOffset Почитай про них

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

Сообщение от DrOffset в windows есть аналогичные инструменты

?)

0

Сообщение от Retyrn0 всё же можно подробнее

Ну например WSASelect.

0

Спасибо, буду учить)

0