форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Передача массива"
Сообщение от ghost (??) on 30-Сен-04, 16:52  (MSK)
Помогите аматору. Есть структура: typedef struct{int x,int y;                float *matrix;}t_matrix; и есть функция типа t_matrix invert_matrix(t_matrix *matrix); Функция копирует саму t_matrix, а я бы хотел вернуть еще и масив значений матрицы (t_matrix->matrix). То есть не указатель на него а именно скопировать массив значений вместе с самой структурой. К примеру получить последовательно в памяти масив трех интов и x*y флоатов и вернуть указатель уже на него. Это в принципе можно сделать отдельной функцией копирования матрицы в void* массив и вернуть его, но, может, можно сразу объяснить машине как резервировать память под матрицу? Большое спасибо. P.S. Простите за глупый вопрос, но в простых статьях такие вопросы не обсуждаються, а сложные статьи трудны для понимания. P.P.S. Если решение требует вставки ассемблера, то это меня не испугает, даже интересно было бы попробовать.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Передача массива"
Сообщение от Аноним on 30-Сен-04, 19:48  (MSK)
#include <string.h> typedef struct { int x, y; float *matrix; } t_matrix; t_matrix invert_matrix(t_matrix *matrix) { t_matrix matrix_new; memcpy(matrix_new, matrix, sizeof(t_matrix)); matrix_new.matrix = malloc(sizeof(float) * (matrix->x * matrix->y)); memcpy(matrix_new.matrix, matrix.matrix, sizeof(matrix->x * matrix->y)); return(matrix_new); }
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Передача массива"
	Сообщение от MaximKuznetsov on 30-Сен-04, 20:09  (MSK)
	несколько поправок к неработающему, синтаксически неверному примеру ;-) >#include <string.h> > >typedef struct { > int x, y; > float *matrix; >} t_matrix; > >t_matrix invert_matrix(t_matrix *matrix) { > t_matrix matrix_new; > memcpy(matrix_new, matrix, sizeof(t_matrix)); > matrix_new.matrix = malloc(sizeof(float) * (matrix->x * matrix->y)); > memcpy(matrix_new.matrix, matrix.matrix, sizeof(matrix->x * matrix->y)); > return(matrix_new); >} #include <stdlib.h> #include <string.h> /** создать копию матрицы */ t_matrix *matrix_dup(t_matrix *orig) {   t_matrix *m;   /* копия дескпиптора */   m=(t_matrix *)malloc(sizeof(*m));   if (m==NULL)     exit(1);   memcpy(m,orig,sizeof(*orig));   /* копия значений */   m->matrix=(float *)malloc(sizeof(float)*m->x*m->y);   if (m->matrix==NULL)     exit(1);   memcpy(m->matrix,orig->matrix,sizeof(float)*m->x*m->y);   return m; } Если речь идет о С (не С++) - функции С не могут возвращать структуры - максимум указатели на них ;-) Кстати наверное было-бы лучше матрицу представлять в виде двумерного массива.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Передача массива"
Сообщение от Vladislav Lazarenko on 30-Сен-04, 21:13  (MSK)
Лучше возьми в руки Си++, напиши красивый класс с конструктором копирования и выиграешь на многом.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Передача массива"
	Сообщение от SergeiZz on 01-Окт-04, 12:54  (MSK)
	>Лучше возьми в руки Си++ >выиграешь на многом. Во, во: очень-очень на многом. Правда, придётся учиться года три, прежде, чем научишься решать мало-мальски сложные задачки. А учиться всегда лень, независимо от пола и возраста. >напиши красивый класс с конструктором копирования Ещё лучше сперва научиться пользоваться uBLAS (http://boost.org), а уж потом учиться самому писать подобные библиотеки.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Передача массива"
Сообщение от ghost (??) on 01-Окт-04, 18:51  (MSK)
>Если речь идет о С (не С++) - функции С не могут возвращать структуры - максимум указатели на них ;-) Да речь идет о С, С++ я, к сожалению, не знаю. Проблема состоит в управлении памятью. У меня есть функция решения уравнений через матрицы 3-го,4-го порядка, какую надо вызывать для решения задачи 10-100 тысяч раз. Я не могу организовать в С единого адресного пространства для промежуточных данных и приходиться мучить систему постоянными вызовами malloc/free (иначе завешивается система из-за перепотребления памяти). Я хотел создать фрагмент памяти для матрицы и постоянно ее туда сливать при всех вызовах функций матричных расчетов. То есть надо возвращать структуру t_matrix и саму матрицу одновременно. Как это сделать я и хотел узнать. К примеру следующий вопрос: Мы вызываем malloc два раза и получаем два независимых фрагмента памяти локализованных где угодно. Таким образом для упорядочивания памяти надо еще и копировать саму матрицу. Мне кажется это потребует еще больше времени чем сам поиск решения... да и потребность в вызове free остается :(. >Кстати наверное было-бы лучше матрицу представлять в виде двумерного массива.   Это да, вообще матрица имеет вид typedef struct {unsigned int x,y;                 float **matrix;}t_matrix; и указатели выставляются на один линейный массив с шагом в sizeof(float)*x. Пример с float *matrix я взял для простоты. >>напиши красивый класс с конструктором копирования >Ещё лучше сперва научиться пользоваться uBLAS (http://boost.org), а уж потом учиться самому писать подобные библиотеки. Это классно, но для С++, а под сам С есть чего-то такое? Я хотел задать вопрос: что лучше С++ или С в плане контроля памяти и быстродействия кода? (Sorry, если такой вопрос вообще не корректен). P.S. Огромное всем спасибо за помощь.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Передача массива"
	Сообщение от SergeiZz on 02-Окт-04, 07:59  (MSK)
	>С++ я, к сожалению, не знаю. Видимо, и C -- тоже... Так, что разница не велика. >>>напиши красивый класс с конструктором копирования >>Ещё лучше сперва научиться пользоваться uBLAS (http://boost.org), а уж >потом учиться самому писать подобные библиотеки. > >Это классно, но для С++, а под сам С есть чего-то такое? Преогромное количество. Для линейной алгебры де-факто стандартная библиотека -- BLAS. >Я хотел задать вопрос: что лучше С++ или С в плане контроля >памяти и быстродействия кода? (Sorry, если такой вопрос вообще не >корректен). Некорректен. В плане контроля памяти -- C++. В плане быстродействия -- ассемблер.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Передача массива"
	Сообщение от ghost (??) on 04-Окт-04, 13:29  (MSK)
	>Видимо, и C -- тоже... Так, что разница не велика. Ну не совсем так, есть несколько моих С программ молекулярного моделирования, которые успешно работают. Просто я не профессиональный программист. >>Это классно, но для С++, а под сам С есть чего-то такое? >Преогромное количество. Для линейной алгебры де-факто стандартная >библиотека -- BLAS. Спасибо. >Некорректен. Я так и думал. >В плане контроля памяти -- C++. В плане быстродействия -- ассемблер. А не будете столь любезны подсказать хороший ресурс для обучения С++ для человека, который уже немного освоил С. Если вы знаете еще и ресурс обучалки на смеси С/assembler или С++/assembler то я буду вам очень признателен. Я имею в виду, что разный код по-разному оптимизируется и не всегда вставки assembler имеют особый смысл и все такое. Заранее спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Передача массива"
	Сообщение от klalafuda on 04-Окт-04, 13:34  (MSK)
	>А не будете столь любезны подсказать хороший ресурс для обучения С++ для >человека, который уже немного освоил С. >Если вы знаете еще и ресурс обучалки на смеси С/assembler или С++/assembler >то я буду вам очень признателен. Я имею в виду, что >разный код по-разному оптимизируется и не всегда вставки assembler имеют особый >смысл и все такое. Страуструп, "Язык С++" // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Передача массива"
	Сообщение от SergeiZz on 04-Окт-04, 14:30  (MSK)
	>>А не будете столь любезны подсказать хороший ресурс для обучения С++ для >>человека, который уже немного освоил С. > >Страуструп, "Язык С++" Не рекомендую эту книку для "программистов-непрофессионалов". Это очень хорошая книга, но она трудна для чтения начинающему; она более ориентирована на профессионалов, или по крайней мере на тех, кто собирается ими стать. Если есть желание освоить синтаксис C++ (только синтаксис, а не ООП), то больше подойдёт, по моему, книга Лафоре: http://www.books.ru/shop/books/81171 Если web, то я знаком только с англоязычными ресурсами, и более справочниками, чем учебниками. Здесь могу предложить этот: http://www.informit.com/guides/guide.asp?g=cplusplus Но лишь как пример: хороших web ресурсов, как обычно, -- днём со гнём. Как изучать ООП на C++ (а не "выучить C++"), -- очень большая тема... В этом плане первый и главный шаг -- ответить на вопрос: "А зачем мне это ООП нужно?". Но это только первый шаг на длинном-предлинном пути... Я согдасен говорить на эту тему, но только при условии, что меня будут слушать. >>Если вы знаете еще и ресурс обучалки на смеси С/assembler или С++/assembler >>то я буду вам очень признателен. Я имею в виду, что >>разный код по-разному оптимизируется и не всегда вставки assembler имеют особый >>смысл и все такое. Смесь C++/assembler -- это гремучий газ. Для программирования на asm (особенно AT&T) для UNIX знаю такой русскоговорящий ресурс: http://www.wasm.ru/about.php Но если речь идёт о моделировании и мат. рассчётах, то ассемблер от этой тематики очень далёк, даже, по части on-line эксперимента (когда требуется общаться с диковинным железом).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Передача массива"
	Сообщение от ghost (??) on 05-Окт-04, 21:53  (MSK)
	Здравствуйте Сергей. >Как изучать ООП на C++ (а не "выучить C++"), -- очень большая тема... В этом плане первый и главный шаг -- ответить на вопрос: "А зачем мне это  ООП нужно?". Но это только первый шаг на длинном-предлинном пути...  Я согдасен говорить на эту тему, но только при условии, что меня будут  слушать. Это просто замечательно, если Вы согласитесь обсудить тему с таким чайником как я. Ответ на вопрос об ООП для меня самого не сильно ясен, но я вижу прогресс этого языка по сравнению с тем же С и Фортраном по его популярности хотя бы в сфере научного программирования. В Вашем предыдущем посте вы, вообщем, правильно высказались, что для меня разница не велика, чего использовать как основной язык программирования. Ваше замечания по поводу оптимальности работы С++ с памятью вызвали у меня большой интерес. Проблема моих программ сводиться не столько к тому, что бы как-то получить результат, а к тому, что бы получить результат за разумное время. Ваша фраза: ?Но если речь идёт о моделировании и мат. рассчётах, то ассемблер от этой тематики очень далёк, даже, по части on-line эксперимента (когда требуется общаться с диковинным железом)? поставила меня в тупик  - лучшие (самые быстрые) программы как раз и имеют вставки ассемблера? К сожалению с самим ресурсом http://www.wasm.ru/about.php еще не разобрался и пока не могу сказать это то что мне надо или нет. В любом случае большое Вам спасибо за помощь. Что касается Страуструппа, то начальные главы почти один в один копируют мой учебник по С Кернигана и Ричи и особой разницы между языками я пока не увидел, но читать продолжаю. :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "Передача массива - вдогонку про ассемблер"
	Сообщение от dimus (??) on 06-Окт-04, 11:23  (MSK)
	Ассемблерные вставки действительно работают на максимально возможной скорости - если их пишет ЗНАЮЩИЙ программист. Однако увлекаться ими очень сильно не следует - такие вставки полезны, если вставлены в кусок кода, который выполняется очень много раз. Если Вы захотите их использовать - внимательно проанализируйте код на предмет больших по продолжительности циклов - там ассемблер будет максимально полезен. Есть еще такая штука, как inline-assembler (Это, если не знаете, когда ассемблерный код вставляется в исходный код С/С++). Так вот, лучше им не пользоваться. Дело в том, что у разных компиляторов есть разное представление о том, как такие вставки должны выглядеть. На мой взгляд, более правильно будет выделить критичные по времени функции в отдельный файл и работать с ним. Если возникнет необходимость в переносе вашего кода на машину с другой системой команд, то вам потребуется всего лишь подправить этот файл, не внося суматоху в основной код. Касательно главного сабжа. Подумайте, нельзя ли немного поменять алгоритм. Как показывает практика, наибольшая выгода от оптимизации получается именно на этом этапе. Тут вам, например, предлагалось выделять память маленькими кусочками. По моему это очень плохая идея (в плане быстродействия). Попробуйте включить ваш массив в саму структуру, выделите огромный кусок памяти для всех структур (или хотя бы для части) и работайте с ним. Кстати, ОЗУ сейчас дешевое, так что можно при желании поднять его объем, что будет хорошо как для вашей программы, так и для всей системы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 06-Окт-04, 18:06  (MSK)
	Спасибо dimus. Если я правильно понял, то Ваша идея о выделении памяти под структуру и массив должна выглядеть где-то так (или есть еще более простое и быстрое решение?): typedef struct {unsigned int x,y;                               float **matrix;}MATRIX;         MATRIX* alloc_matrix(unsigned int x,unsigned int y) { MATRIX *matrix; matrix=(MATRIX*)malloc(sizeof(MATRIX)+sizeof(float*)*y+sizeof(float)*y*x); matrix->x=x; matrix->y=y; matrix->matrix=matrix+sizeof(MATRIX)+sizeof(float*)*y; while(--y)   matrix->matrix[y]=matrix->matrix+sizeof(float)*x*y;    return matrix; } И второй вопрос, а есть ли какие библиотеки для быстрого управления памятью? По принципу как Вы и писали - выделяется системой большой кусок памяти и пока в него можно поместиться, БЫСТРО нарезаются блоки нужной длинны уже самой программой. Спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "Передача массива - вдогонку про ассемблер"
	Сообщение от MaximKuznetsov on 06-Окт-04, 18:18  (MSK)
	>Спасибо dimus. >Если я правильно понял, то Ваша идея о выделении памяти под структуру >и массив должна выглядеть где-то так (или есть еще более простое >и быстрое решение?): > >typedef struct {unsigned int x,y; >             >    float **matrix;}MATRIX; > >MATRIX* alloc_matrix(unsigned int x,unsigned int y) >{ >MATRIX *matrix; > >matrix=(MATRIX*)malloc(sizeof(MATRIX)+sizeof(float*)*y+sizeof(float)*y*x); >matrix->x=x; >matrix->y=y; >matrix->matrix=matrix+sizeof(MATRIX)+sizeof(float*)*y; >while(--y) >  matrix->matrix[y]=matrix->matrix+sizeof(float)*x*y; > >return matrix; >} > >И второй вопрос, а есть ли какие библиотеки для быстрого управления памятью? >По принципу как Вы и писали - выделяется системой большой кусок >памяти и пока в него можно поместиться, БЫСТРО нарезаются блоки нужной >длинны уже самой программой. >Спасибо. > не зашоривайтесь на управлении памятью - напишите сначала программу, чтобы она корректно работала..всему своё время и место - оптимизировать работу с памятью надо только если это будет __тонким местом__, о чём можно сказать только имея уже работоспособный проект..а то так вы убьете уйму времени и сил, а требуемые матричные операции так и не сделаете ;-) кстати malloc достаточно быстро (и главное надёжно)работает, был случай убедится..
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 06-Окт-04, 18:24  (MSK)
	>не зашоривайтесь на управлении памятью - напишите сначала программу, чтобы она корректно >работала..всему своё время и место - оптимизировать работу с памятью надо >только если это будет __тонким местом__, о чём можно сказать только >имея уже работоспособный проект..а то так вы убьете уйму времени и >сил, а требуемые матричные операции так и не сделаете ;-) > >кстати malloc достаточно быстро (и главное надёжно)работает, > был случай убедится.. Ну программа уже работает и я хотел бы ее разогнать немного.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 07-Окт-04, 15:54  (MSK)
	>>не зашоривайтесь на управлении памятью - напишите сначала программу, чтобы она корректно >>работала. >>кстати malloc достаточно быстро (и главное надёжно)работает, >> был случай убедится.. > >Ну программа уже работает и я хотел бы ее разогнать немного. Она уже решила задачу? Или требуется утилита для решения целого класса задач? Кто будет использовать жту программу: только Вы, или другие люди тоже? Не помешал бы пример типичного трудоёмкого вычисления. Как уже много говорилось выше, язык программирования, честно говоря, не определяет эффективность программы ни в какой степени. Чтобы было что обсуждать, нужно поставить задачку и (хотя бы на словах) описать выбранный способ решения (который чем-то не удовлетворяет; чем?). Тогда и понятно станет, каое место нужно писать на каком языке и почему. Из общих соображений такие проблемы не решаются.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 07-Окт-04, 17:19  (MSK)
	>>Ну программа уже работает и я хотел бы ее разогнать немного. >Она уже решила задачу? Или требуется утилита для решения целого класса >задач? Кто будет использовать жту программу: только Вы, или другие люди >тоже? > >Не помешал бы пример типичного трудоёмкого вычисления. Как уже много >говорилось выше, язык программирования, честно говоря, не определяет >эффективность программы ни в какой степени. >Чтобы было что обсуждать, нужно поставить задачку и (хотя бы на словах) > >описать выбранный способ решения (который чем-то не удовлетворяет; чем?). >Тогда и понятно станет, каое место нужно писать на каком языке и >почему. >Из общих соображений такие проблемы не решаются. Это фрагмент комбайна для расчета молекулярного аффинитета (сродства). Его задача вычислять и оптимизировать энергетический профиль молекулярной системы. Конкретно функции матричных вычислений планируется использовать во многих узлах комбайна (вращения, вычисления заряда, зависимости структура-активность, ...), но здесь речь идет о оптимизации двугранных углов в 3D пространстве (вычисление вектора для помещения точки А в плоскость BCD и поиск оптимальной суперпозиции точек А и D, при их свободном вращении вокруг оси BC). Пример очень простой - есть две молекулы протеин (белок) и его низкомолекулярный лиганд, надо получить их комплекс при условии, что не плохая исходная позиция уже задана другим модулем комбайна. Алгоритм заключается в последовательном вычислении векторов сил действующих на каждый атом системы и смещение самих атомов под действием вектора этих сил на dt, с последующим перерасчетом этих сил для новой суперпозиции и новым смещением и т.д. пока длинна векторов смещений не станет слишком маленькой. В системе 2 000 - 6 000 атомов, надо около 100 шагов на одну систему из 2-10 разных исходных систем одного лиганда для около 100 000 разных лигандов.     P.S. Цикл минимизатора получается настолько громоздкими (около 1500 строк), что я и в С исходнике в нем путаюсь, а про ассемблер и подумать страшно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 07-Окт-04, 18:49  (MSK)
	>>Из общих соображений такие проблемы не решаются. > >Это фрагмент комбайна для расчета молекулярного аффинитета (сродства). Его задача вычислять и >оптимизировать энергетический профиль молекулярной системы. >Конкретно функции матричных вычислений планируется использовать во многих узлах комбайна (вращения, вычисления >заряда, зависимости структура-активность, ...), но здесь речь идет о оптимизации двугранных >углов в 3D пространстве (вычисление вектора для помещения точки А в >плоскость BCD и поиск оптимальной суперпозиции точек А и D, при >их свободном вращении вокруг оси BC). Да. Этого я и просил. Подобные пакеты (в основном коммерческие) широко используются в хим. физике; примеры из самых простых -- Гиперхимия, Алхимия. >Пример очень простой - есть две молекулы протеин (белок) и его низкомолекулярный >лиганд, надо получить их комплекс при условии, что не плохая исходная >позиция уже задана другим модулем комбайна. > >Алгоритм заключается в последовательном вычислении векторов сил действующих на каждый атом системы >и смещение самих атомов под действием вектора этих сил на dt, >с последующим перерасчетом этих сил для новой суперпозиции и новым смещением >и т.д. пока длинна векторов смещений не станет слишком маленькой. >В системе 2 000 - 6 000 атомов, надо около 100 шагов >на одну систему из 2-10 разных исходных систем одного лиганда для >около 100 000 разных лигандов. Теперь могу говорить определённо: а) это стандартная задача, ничего экзотического в ней нет; б) для решения таких задач лучше всего воспользоваться BLAS (на C), или uBLAS (на C++), ибо они и разрабатывались для решения таких задач; в) использование BLAS в данном конкретном случае оптимально с точки зрения эффективности: у BLAS очень добротные реализации (к тому же она хорошо переносима), если использовать её разумно, то память и прочие ресурсы будут использоватся наилучшим возможным способом (какого только можно достичь на C); г) осваивать C++ (с прицелом на uBLAS и всё остальное) стоит только, если на это есть время и жгучее желание -- результат окупит трудозатраты, но не факт, что он будет достигнут; д) ассемблер до указанной задачи не имеет ровно ни какого касательства; е) разумное использование BLAS требует некоторого опыта работы с ней, так как она рассчитана на проффессионалов в этой области (не в пример uBLAS, которая более легка для изучения математиками-непрограммистами); поэтому возможно стоит поначалу использовать более простую библиотеку, с меньшими возможностями и менее эффективной реализацией, пример -- GSL (GNU Scientific Library), она имеет во-первых, интерфейс к BLAS, более лёгкий для изучения, во-вторых собственные средства работы с матрицами (уступают BLAS в сожных вычислениях типа поиска соб. векторов). >P.S. Цикл минимизатора получается настолько громоздкими (около 1500 строк), что я и >в С исходнике в нем путаюсь, а про ассемблер и подумать >страшно. 15 строк на BLAS не обещаю, но вот за 150 могу постоять...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 07-Окт-04, 19:48  (MSK)
	Спасибо Сергей. C приложениями Гиперхимии знаком - тормоза редкие, не факт, впрочем, что из-за библиотек. Алхимия вроде лучше, но опыт работы с такими приложениями у меня не велик и они точно не самые быстрые. С освоением С++ не совсем понятно. Да желание есть, но и С мне кажется изящным языком, а о преимуществах С++ я не имею четкого представления. Может вы как работающий с ним человек объясните более предметно чем тот же Страуструп (он пишет о создании языка более удобного чем С, но с чем фишка я пока не особо понял :( )?   Говоря о ассемблере в пункте д вы имеете в виду невозможность существенно улучшить производительность по сравнению с тем же BLAS, так? 1500 строк - это моя библиотека матричных/векторных вычислений плюс сам минимизатор, если выкинуть геометрию и алгебру, то все займет те же 180 строк (там не только двугранные углы) :). А можно здесь задавать вопросы по BLAS или это будет сильно офтопик? P.S. Самый быстрый подобный продукт в мире имеет ассемблерные вставки и работает несравненно быстрее чем известные мне аналоги (там правда еще fftw используется).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	19. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 08-Окт-04, 19:22  (MSK)
	>C приложениями Гиперхимии знаком - тормоза редкие, не факт, впрочем, что из-за >библиотек. >Алхимия вроде лучше, но опыт работы с такими приложениями у меня не >велик и они точно не самые быстрые. Я привёл эти примеры, только, чтобы проиллюстрировать моё понимание задачи -- не больше. Эти пакеты -- настольные игрушки, -- но они находят свою аудиторию и довольно популярны. >С освоением С++ не совсем понятно. Да желание есть, но и С >мне кажется изящным языком, а о преимуществах С++ я не имею >четкого представления. Может вы как работающий с ним человек объясните более >предметно чем тот же Страуструп (он пишет о создании языка более >удобного чем С, но с чем фишка я пока не особо >понял :( )? А я предупреждал, между прочим... Он пишет для людей, которые уже знают и на собственной шкуре испытали трудности использования структурного программирования в решении сложных задач. Он и говорит: "Лучше, чем C", подразумевая, что читатель детально знаком с темой "Чем C плох". Он поэтому совсем не разжёвывает подобных утверждений. Ещё, нужно иметь в виду, что эта книга -- не введение в ООП, а просто изложение синтаксиса C++. Если Вы ставите целью изучения C++ повысить быстродействие своих программ, то Вы ошибаетесь в главном. Если поставите целью, например, написать "убийцу Гиперхимии", то в этом случае C++ -- это ультимативное решение. Если видите, что перед Выми в будущем встанет широкий класс сложных задач, то C++ -- верное направление (но возможно, не оптимальное). Так, что, опять же, нужно определиться, зачем это ООП Вам сдалось; что не устраивает в привычном C? Только быстродействие? Если причина в неэффективной реализации линейной алгебры -- нужно перейти на BLAS, если причина в неэффективном алгоритме -- почитать литературу на эту тему в поисках новых идей. Например, так как у Вас задача оптимизации, можно посмотреть в сторону Simulated Annealing (в GSL есть реализация). >Может вы как работающий с ним человек объясните более >предметно чем тот же Страуструп Попробовать можно... Но нужно убрать из разговора слово "лучше". C++ не лучше C, а совсем другой язык и для совсем других задач. Вот например для Вашей задачи C++ может оказаться более подходящим, чем С. Но это потребует выполнения ряда довольно тонких условий, большинство из которых к собственно программированию имеют мало отношения. К тому же, нужно иметь в виду, что использование того или иного языка мало влияет на эффективность программ: программа на ассемблере быстрее работает чем программа на C не потому, что она на ассемблере, а потому, что, например, C универсальным образом передаёт аргументы в подпрограмму (через стек); на ассемблере удобнее, чем на C оптимизировать эту особенность. C++, кстати, лишь добавит ещё подобных "приторможек" по сравнению с C. И тем не менее... Одной непонятной фразой: на C++ удобнее, чем на C писать программы с использованием ООП, и в этом его главное преимущество. >Говоря о ассемблере в пункте д вы имеете в виду невозможность существенно >улучшить производительность по сравнению с тем же BLAS, так? Невозможность в принципе -- нет. Невозможность в данной ситуации -- да. Вы упоминали об основном цикле, переписанном на ассемблере, применительно к нему я сказал, что ассемблер тут ни причём. Действительно, если переписать этот цикл на ассемблере ничего хорошего из этого не выйдет. >1500 строк - это моя библиотека матричных/векторных вычислений плюс сам минимизатор, если >выкинуть геометрию и алгебру, то все займет те же 180 строк >(там не только двугранные углы) :). Я о том же. Вы просто написали то, что уже давно написано. Обычно не удаётся сразу создать что-то лучшее чем де-факто стандартное. BLAS не вчера разработан и с тех пор много людей только и думали, как повысить его эффективность, стоит воспользоваться плодами их труда. >А можно здесь задавать вопросы по BLAS или это будет сильно офтопик? Что топик, а что нет, как я понимаю, должен решать автор темы. Но, наверно, для читателей удобнее, когда темы жёстко структурированы, а не в одной куче. >P.S. Самый быстрый подобный продукт в мире имеет ассемблерные вставки и работает >несравненно быстрее чем известные мне аналоги (там правда еще fftw используется). А почему он работает быстрее? Потому что имеет ассемблерные вставки? Или может быть главный-то компонент этой быстрости Fast Fourier?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	20. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 09-Окт-04, 15:38  (MSK)
	>Я привёл эти примеры, только, чтобы проиллюстрировать моё понимание >задачи -- не больше. Эти пакеты -- настольные игрушки, -- но они >находят >свою аудиторию и довольно популярны. "Настольные игрушки" - отличная характеристика, которая точно иллюстрирует ваше понимание задачи. Если не секрет, Вы с ними работаете или просто сталкивались? >Если видите, что перед Выми в будущем встанет широкий класс сложных >задач, то C++ -- верное направление (но возможно, не оптимальное). >Так, что, опять же, нужно определиться, зачем это ООП Вам сдалось; что >не устраивает в привычном C? Только быстродействие? Если причина в >неэффективной реализации линейной алгебры -- нужно перейти на BLAS, >если причина в неэффективном алгоритме -- почитать литературу на эту тему >в поисках новых идей. Например, так как у Вас задача оптимизации, можно >посмотреть в сторону Simulated Annealing (в GSL есть реализация). С мне кажется в целом быстрым и изящным языком. Широкий - понятие относительное, но я думаю что уже имею много сложных задач. Эффективность алгоритма и есть то, на что я нацеливаю свои программы. Но я могу создать эффективный алгоритм решения только профессиональной макро задачи, что разобьет последнюю на огромное количество тривиальных микро задач. Мне лишь хочется как-то разумно ускорить и решения этих самых микро задачи. SA слишком ресурсоемок, нет? Для минимизатора я думаю использовать Steepest descent и Raphson Block-Diagonal, вы не сталкивались с хорошей их реализацией? >Одной непонятной фразой: на C++ удобнее, чем на C писать программы с >использованием ООП, и в этом его главное преимущество. Ага, с плюсами понятно, а в чем сила объектов? >Я о том же. Вы просто написали то, что уже давно написано. >Обычно не >удаётся сразу создать что-то лучшее чем де-факто стандартное. BLAS не >вчера разработан и с тех пор много людей только и думали, как >повысить >его эффективность, стоит воспользоваться плодами их труда. Целиком с Вами согласен, но жалко как-то выбрасывать свои (уже рабочие!) функции даже в угоду BLAS... Я думаю, они достаточно хороши, что бы работать, а в будущем их можно использовать совместно с BLAS, когда я с ним разберусь лучше. >>P.S. Самый быстрый подобный продукт в мире имеет ассемблерные вставки и работает >>несравненно быстрее чем известные мне аналоги (там правда еще fftw используется). >А почему он работает быстрее? Потому что имеет ассемблерные вставки? >Или может быть главный-то компонент этой быстрости Fast Fourier? Ну я думаю и то и другое :) ОК. Сразу надо привести программу к виду подходящему для применения ассемблера - короткий вычислительный модуль, максимум строк на 300 С кода и потом вывесить тему на топик по оптимизации уже конкретного фрагмента. P.S. Большое спасибо всем, кто помог мне разобраться с местом ассемблера в С/С++ проекте.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "Передача массива - вдогонку про выделение памяти"
	Сообщение от dimus (??) on 11-Окт-04, 15:19  (MSK)
	Ваша задача мне очень напоминает компьютерную игру - есть много-много объектов с которыми одновременно что-то происходит, и надо чтобы это происходило как можно быстрей. Когда я писал про выделение памяти, я имел ввиду выделение ее не под одну структуру, а под целый их массив - именно такой подход использовали в старых играх разработчики с целью обеспечить максимальную производительность.(Современые разработчики обленились, и больше внимания уделяют срокам выхода, а повышение производительности достигается покупкой более мощного железа :( ) И думать об этом надо в самом начале разработки, так как это не оптимизация, а архитектурное решение. Так что если Вы будите дальше разрабатывать свою программу, то имеет смысл подумать над этой возможностью. Хотя конечно использование готовых библиотек выглядит весьма заманчиво. В любом случае желаю Вам удачного завершения проекта.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	22. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 11-Окт-04, 16:29  (MSK)
	>>Я привёл эти примеры, только, чтобы проиллюстрировать моё понимание >>задачи -- не больше. Эти пакеты -- настольные игрушки, -- но они >>находят >>свою аудиторию и довольно популярны. >"Настольные игрушки" - отличная характеристика, которая точно иллюстрирует ваше понимание задачи. Если >не секрет, Вы с ними работаете или просто сталкивались? С ними работают мои знакомые и знакомые моих знакомых. Для них это единственный доступный способ построить молекулу. Задачи, стоящие перед моими знакомыми, эти пакеты решить доконца не в состоянии и поэтому часть трудоёмкой работы им приходится выполнять вручную (а реальные объёмы такой работы, соответственно, недоступны вовсе). >С мне кажется в целом быстрым и изящным языком. Широкий - понятие >относительное, но я думаю что уже имею много сложных задач. Эффективность >алгоритма и есть то, на что я нацеливаю свои программы. Но >я могу создать эффективный алгоритм решения только профессиональной макро задачи, что >разобьет последнюю на огромное количество тривиальных микро задач. Мне лишь хочется >как-то разумно ускорить и решения этих самых микро задачи. Очень опасно ускорение микро задач ставить слишком высоко по сравнению с ускорением алгоритма (макро задачи). Ускорение реализации обычно приносит фиксированную выгоду. Можно ускорить программу в 10-100 раз, переписав её на ассемблере, но это мелочь, если подходящий алгоритм заменяет N^2 шагов на просто N. Ассемблерная оптимизация актуальна больше в системном программировании, нежели в прикладном. Потом, это дело и там всегда не тривиально и должно быть веско оправдано. >SA слишком ресурсоемок, нет? За счёт чего? >Для минимизатора я думаю использовать Steepest descent и >Raphson Block-Diagonal, вы не сталкивались с хорошей их реализацией? Мне не приходило в голову искать специальной реализации этих методов: в них нет ничего, кроме линейной алгебры. Такая специыльная реализация интересна, наверное, только на C++. >>Одной непонятной фразой: на C++ удобнее, чем на C писать программы с >>использованием ООП, и в этом его главное преимущество. >Ага, с плюсами понятно, а в чем сила объектов? Объектный подход -- единственный известный (Sic!) способ справиться со сложностью современных задач. Другие методологии терпят крах, даже если просто объём программы превышает предел в 100тыс. строк (информация к размышлению: ядро Linux содержит более 9млн. строк, оно написано на C, использовано ли в нём ООП?). Размер программы лишь условно характеризует её сложность, и маленькая программа может быть сложной. Что понимать под самим словов "сложность" -- вопрос тонкий, но бытовое понимание приемлемо. Предвижу вопрос: "За счёт чего объекты побеждают?". Мысля задачу в терминах объектов, мы во-первых приближаем её к предметной области (Мир состоит их объектов, а не из алгоритмов), во вторых наш ум так устроен, что ему проще искать решение, оперируя объектами. Если конкретно, то, например, в стиле C сложение векторов выглядит как вызов подпрограммы для пары массивов, на C++ -- как операция +, которая ничем не отличается синтаксически от сложения фундаментальных типов, вроде int и double. Так на C++ можно мыслить непосредственно в терминах линейной алгебры, на C, же для того же требуется так или иначе ещё один шаг: сперва перевести рассуждения с C на язык предметной области. Лишняя работа никогда не идёт в прок. >жалко как-то выбрасывать свои (уже рабочие!) функции >даже в угоду BLAS... >Я думаю, они достаточно хороши, что бы работать, а в будущем их >можно использовать совместно с BLAS, когда я с ним разберусь лучше. Разумеется, делать нужно именно так. Любое изменение существующего кода должно быть процессом эволюционным, а не революционным. >Сразу надо привести >программу к виду подходящему для применения ассемблера - короткий вычислительный модуль, >максимум строк на 300 С кода и потом вывесить тему на >топик по оптимизации уже конкретного фрагмента. Именно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	23. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 11-Окт-04, 18:09  (MSK)
	Спасибо dimus. Как вы оцениваете следующую стратегию работы с памятью: 1. Выделяется большой линейный фрагмент на определенное число итераций алгоритма. 2. Выделанная память засоряется микро фрагментами. Передаются только адрес последнего занятого байта  и необходимые для работы адреса. 3. В момент между итерациями, когда потребление памяти минимально выделяется новый громадный массив  памяти, а со старого копируются нужные еще данные и он  освобождается.       Это не совсем то о чем вы говорили, но память уже дешевая, и 10Mb на итерацию должно хватить, если использовать ее более-менее аккуратно.   Здравствуйте Сергей. 10 раз на ассемблере ? это просто фантастика! Цепочки операций в алгоритмах не настолько длинные, что бы пренебрегать таким приростом производительности. Но идею я понял и абсолютно с вами согласен. Никто не будет писать убийцу чего-то уже известного, полагаясь на разгон простой оптимизацией кода, с другой стороны даже новый алгоритм может проигрывать старому из-за бездарности технической реализации. Со сложностью задач тоже понятно. Да для разработчиков Microsoft это актуально, хоть как-то читать коды своих детищ. Но у меня запросы поскромнее ? едва ли наберется 20000 строк моего кода, а цифра в 50000 кажется целиком достаточной для моих нужд на ближайших два-три года (аспирантура). Для такого объема работ ООП, наверно не актуален. Ядро Линуха написано на С, но оно сильно модульное и требует работы с железом. Суммировать вектора простым плюсом, конечно, удобно, но использование функций  тоже не сильно напрягает. Хотя вынужден признать С++ снимает много рутины с программиста.  Я думаю, оптимумом будет применение его для графики. Иногда бывает потребность в создании простых графических визуализаторов результатов вычислений. Тем более, что на изучение того же синтаксиса плюсов уйдет некоторое время. Медлительность SA как раз и есть следствием решения макро задачи, о которой я говорил. Вы, наверное, работаете с задачами типа квантовых вычислений. У меня ? скрининг баз данных и молекулярный докинг. SA ? дает расхождения решений на каждом шагу и для картирования всего профиля свободной энергии надо много запусков. Релаксация молекулярных макрообъектов (протеинов и их комплексов) происходит в наносекундном диапазоне, а отжиг одного фрагмента системы можно получить намного быстрее и с той же точностью тем же матчингом точек взаимодействия и молекулярной топологии фрагмента. Если есть альтернативный генератор исходных низко энергетических состояний, то минимизация SA не имеет смысла ? зачем прыгать между минимумами, если коридор спуска уже определен. И второе, молекулярные взаимодействия в не квантово-химических моделях очень неточны и значительно лучшие результаты можно получить если использовать комбинированный подход из эмпирических правил и энергетических свойств систем.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	24. "Передача массива - вдогонку про ассемблер"
	Сообщение от Vladislav Lazarenko on 11-Окт-04, 18:14  (MSK)
	Придумано неплохо, но Вы уверены что напишете самую лучшую реализацию? Или может быть лучше воспользоваться несколькими хорошо продуманными, реализованными и протестироваными алгоритмами? На это уйдет меньше сил и времени, чем на реализацию и тестирование ваших идей. Советую почитать про контейнеры STL (Standard Template Library) C++ и встваить совсем немного Си++ кода в вашу Си программу. (Как подсказка что Вам нужно, чтобы не учить всю STL, это контейнеры, std::map, std::vector и т.п. У многих из них (точно не скажу сейчас у каких), есть capecity, Вы можете зарезервировать сразу память под её дальнейшее использование). Ask if any questions.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	25. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 12-Окт-04, 10:06  (MSK)
	>1. Выделяется большой линейный фрагмент на определенное число итераций алгоритма. > 2. Выделанная память засоряется микро фрагментами. Передаются только адрес последнего занятого >байта  и необходимые для работы адреса. >3. В момент между итерациями, когда потребление памяти минимально выделяется новый громадный >массив  памяти, а со старого копируются нужные еще данные и >он  освобождается. Реализуется на BLAS/GSL с помощью matrix_view... Это матрицы, которые физически являются подматрицами других матриц, но обращение с ними ничем не отличается от обращения с обычными матрицами. >Здравствуйте Сергей. >10 раз на ассемблере ? это просто фантастика! Цепочки операций в алгоритмах >не настолько длинные, что бы пренебрегать таким приростом  роизводительности. Время, которое нужно затратить разработчику на низкоуровневую оптимизацию слишком велико даже в простых случаях. Обычно выгоднее его тратить на оптимизацию алгоритма. >другой стороны даже новый алгоритм может проигрывать старому из-за бездарности технической >реализации. Поэтому предпочтительно использовать стандартные решения... >Со сложностью задач тоже понятно. Да для разработчиков Microsoft это актуально, хоть >как-то читать коды своих детищ. Но у меня запросы поскромнее ? >едва ли наберется 20000 строк моего кода, а цифра в 50000 >кажется целиком достаточной для моих нужд на ближайших два-три года (аспирантура). >Для такого объема работ ООП, наверно не актуален. Сложность не определяется объёмом прогаммы, просто, большие программы обычно и сложные тоже. Актуальность ООП определяется целиком и полностью умением/неумением разработчика им воспользоваться. >Суммировать вектора простым плюсом, конечно, удобно, но использование функций  тоже >не сильно напрягает. Так будет всегда? >Хотя вынужден признать С++ снимает много рутины с >программиста.  Я думаю, оптимумом будет применение его для графики. Open Inventor -- C++ обёртка для GL. >Тем более, >что на изучение того же синтаксиса плюсов уйдет некоторое время. На синтаксис -- полгода. На ООП -- может и жизни не хватить...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	26. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 13-Окт-04, 15:02  (MSK)
	Здравствуйте Сергей. Я не могу найти, как вычислять определитель матрицы в BLAS, не подскажите?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	27. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 14-Окт-04, 10:37  (MSK)
	>Здравствуйте Сергей. >Я не могу найти, как вычислять определитель матрицы в BLAS, не подскажите? Нужно вычислить соб. значения и перемножить их. Подпрограмма вычисления детерминанта -- вещь бесполезная: в численных рассчётах прямого использования определителя нужно избегать (хороший пример на эту тему -- нормальная система в методе наименьших квадратов).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	28. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 14-Окт-04, 12:56  (MSK)
	>Нужно вычислить соб. значения и перемножить их. Подпрограмма вычисления >детерминанта -- вещь бесполезная: в численных рассчётах прямого >использования определителя нужно избегать (хороший пример на эту тему -- >нормальная система в методе наименьших квадратов). А можно поподробнее о вреде прямого использования определителя?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	29. "Передача массива - вдогонку про ассемблер"
	Сообщение от SergeiZz on 14-Окт-04, 14:20  (MSK)
	>>Нужно вычислить соб. значения и перемножить их. Подпрограмма вычисления >>детерминанта -- вещь бесполезная: в численных рассчётах прямого >>использования определителя нужно избегать (хороший пример на эту тему -- >>нормальная система в методе наименьших квадратов). >А можно поподробнее о вреде прямого использования определителя? Это обычное дело: то, что хорошо для теоретика, обычно смерть для вычислителя. И определитель, и комплексная форма рядов Фурье, итд, итп. Чаще всего определитель неудобен из-за двух его особенностей: а) не известно эффективного способа его вычислить; б) известные способы его вычисления численно неустойчивы. По второму пункту такой пример: как легче обращать матрицу, методом последовательных исключений, или через определители? -- методом последовательных исключений, потому что он точнее.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	30. "Передача массива - вдогонку про ассемблер"
	Сообщение от ghost (??) on 14-Окт-04, 15:05  (MSK)
	Ага, вы ответили сразу и на второй вопрос о обращенных матрицах. Перепишу код без вычислений определителей. Большое спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	31. "Передача массива - вдогонку про оптимизацию"
	Сообщение от dimus (??) on 15-Окт-04, 08:11  (MSK)
	Чуть не забыл. Есть совсем простой способ немного ускорить вызов ваших функций - попобуйте использовать конвенцию fastcall. Это дает ощутимый выигрыш в скорости при минимуме затрат времени с вашей стороны.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.