А что мешает это в С++ сделать? Да и управление памятью там иное.
управление памятью можно по разному реализовать в С++, я лично использую Сишный способ с некоторыми хитростями, а вот использование С++ может убавить производительности, все таки Си более низкоуровневый язык программирования
А что мешает это в С++ сделать? Да и управление памятью там иное.
Для новичков лучше C, потому что они хватаются за всё что могут. За классы, за exceptions и в итоге знают только как класс объявить, не имея представления о работе памяти.
Кстати народ, вопрос по работе с памятью: какой самый быстрый способ в C++ для работы с двухмерными массивами? (ссылки приветствуются)
Суть проблемы. Клепаю прогу для обработки изображения. Есть 3 массива double **RVals, **GVals, **BVals; Все 3 активно используются (запись + чтение). После одноразового создания при старте проги размеры не меняют.
Суть проблемы. Клепаю прогу для обработки изображения. Есть 3 массива double **RVals, **GVals, **BVals; Все 3 активно используются (запись + чтение). После одноразового создания при старте проги размеры не меняют.
при чтении и записи нужно убрать зависимости по данным это раз, а два стараться считывать и записывать из параллельно, т.е. при первом проходе цикла память читается с шагом 32 байта (или 64/128 если оптимизируется исключительно под Athlon) во втором проходе считываются остальные ячейки памяти не кратыне 32 байтам, при таком случае эти ячейки попадут в кэш и будут считываться быстро-быстро )) и лучше тип использовать не double а float, если конечно не нужна изрядная точность, и float при том выравнивается по 4 байтовой границе а double по 8 байтовой. Если интересно почитай книжку "Крис Касперски - техника оптимизации программ, эффективное использование памяти", там все подробно рассказано, очень интеросно читать
Сообщение отредактировал Xakep - Пятница, 03 Мая 2013, 08:31
т.е. при первом проходе цикла память читается с шагом 32 байта (или 64/128 если оптимизируется исключительно под Athlon)
Кэш линия сейчас почти во всех современных процессорах - 64 байта, под нее и надо оптимизировать. А так все правильно сказано, плюсану.
Epsilon Добавлю, что память должна быть варавнена, ибо это временами заставляет процессор делать два обращения к памяти вместо двух и еще "склеивать" результат, что несомненно замедляет работу, а на большинстве RISC процессоров все это вообще упадет. Старайся писать\читать (и выделять, что тоже важно) из\в память как можно более последовательно, а не хаотично, иначе кэша на все не хватит. + Под характер работы определенного алгоритма можно подогнать алгоритм выделения памяти, что сделает работу с ней более последовательной, и получить в итоге небольшой буст.
Как советовал Xakep, тип на float заменить было бы неплохо, ибо в кэш их влезет в два раза больше (16). Но я вижу три RGB массива, а раз это и правда RGB, то для хранения цвета компоненты этой модели достаточно всего одного байта и в кэш линию их поместится в 4 раза больше (и выравнивать ничего не надо), что опять таки положительно скажется на производительности.
Цитата (Undead)
Ты ему ещё рычажками предложи программировать
А неплохая таки идея C++ - он особенный. С помощью него можно не только выстрелить себе в ногу, но и повеситься в пустой комнате:)
Сообщение отредактировал Archido - Пятница, 03 Мая 2013, 14:28
ну что-то вроде x = arr[x]; до тех пор пока процессор не узнает значение x, он не сможет приступить к загрузке следующей ячейки, т.к. еще не знает ее адресса. А такой код не имеет зависимости: а = arr[x++]; в таком случае процессору известен адресс, он считывает ее и немедленно увеличивает переменну x и, не дожидаясь ответа, отправляет следующий запрос.
Вы переходите за черту приличия, имхо. Все ЯП хороши, все они были созданы кем-то и внесли огромный вклад в историю человечества. Ту или иную вещь можно сделать миллионом разных инструментов. А если кратко, то: "Прямые руки - залог успеха, инструмент тут не при чём. Гвоздь можно забить и голой ладонью, было бы желание". Осмелитесь ли вы назвать программиста нубом, если он сотворит на паскале то, что в принципе вы не смогли бы на С++? Я считаю, что нет. Вы бы либо завидовали, либо восхищались им (как бы это парадоксально не звучало). Что у всех в головах, простите конечно дерзость мою, за чушь? Инструмент - не главное. Их же как-то собрали? А всё начиналось с того, что их сделали руки. И очень жаль, что вы не цените историю и так нагло, некрасиво оскорбляете историю, людей, которые до сих пор программируют на этом ЯП.
Сообщение отредактировал Saitei - Четверг, 09 Мая 2013, 22:01
Паскаль куда проще.
