Сообщение Re[21]: C# - from indians by indians от 02.06.2015 23:25
Изменено 03.06.2015 3:14 mik1
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здесь используется не класс типа Complex, а класс типа ComplexArray.
EP>Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
А вот тут ты немного обманываешься — ни в деке, ни в очереди ты уже безразрывный блок памяти не получишь, и весь твой выигрыш рискует превратиться в тыкву
EP>Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.
Давай по честному — мой код по длине не сильно больше твоего. По производительности подозреваю что тоже похож. По сложности — тоже самое.
Синклер тут где-то заявлял, что такое в принципе невозможно.
Просто поверь, что более сложную логику я точно также напишу (но за деньги ).
EP>В этом примере (перемножение массивов объектов Complex) — тормоза на Java будут даже без учёта GC.
"Тормоза" тут будут только от 12-16 байтов заголовка объекта в Яве, которые будут "разрывать" последовательность даблов.
Как только ты уйдешь от массивов в плюсах, все станет на свои места. Кроме того, как я уже намекнул, твой пример скромно обходит любые выделения памяти
EP>Здесь используется не класс типа Complex, а класс типа ComplexArray.
EP>Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
А вот тут ты немного обманываешься — ни в деке, ни в очереди ты уже безразрывный блок памяти не получишь, и весь твой выигрыш рискует превратиться в тыкву
EP>Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.
Давай по честному — мой код по длине не сильно больше твоего. По производительности подозреваю что тоже похож. По сложности — тоже самое.
Синклер тут где-то заявлял, что такое в принципе невозможно.
Просто поверь, что более сложную логику я точно также напишу (но за деньги
).EP>В этом примере (перемножение массивов объектов Complex) — тормоза на Java будут даже без учёта GC.
"Тормоза" тут будут только от 12-16 байтов заголовка объекта в Яве, которые будут "разрывать" последовательность даблов.
Как только ты уйдешь от массивов в плюсах, все станет на свои места. Кроме того, как я уже намекнул, твой пример скромно обходит любые выделения памяти
Re[21]: C# - from indians by indians
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здесь используется не класс типа Complex, а класс типа ComplexArray.
EP>Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
А вот тут ты немного обманываешься — ни в деке, ни в очереди ты уже безразрывный блок памяти не получишь, и весь твой выигрыш рискует превратиться в тыкву
EP>Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.
Давай по честному — мой код по длине не сильно больше твоего. По производительности подозреваю что тоже похож. По сложности — тоже самое.
Синклер тут где-то заявлял, что такое в принципе невозможно.
Просто поверь, что более сложную логику я точно также напишу (но за деньги ).
Да, и мне казалось в числодробилках обычно довольно однородные типы данных обрабатываются.
EP>В этом примере (перемножение массивов объектов Complex) — тормоза на Java будут даже без учёта GC.
"Тормоза" тут будут только от 12-16 байтов заголовка объекта в Яве, которые будут "разрывать" последовательность даблов.
Как только ты уйдешь от массивов в плюсах, все станет на свои места. Кроме того, как я уже намекнул, твой пример скромно обходит любые выделения памяти
EP>Здесь используется не класс типа Complex, а класс типа ComplexArray.
EP>Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
А вот тут ты немного обманываешься — ни в деке, ни в очереди ты уже безразрывный блок памяти не получишь, и весь твой выигрыш рискует превратиться в тыкву
EP>Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.
Давай по честному — мой код по длине не сильно больше твоего. По производительности подозреваю что тоже похож. По сложности — тоже самое.
Синклер тут где-то заявлял, что такое в принципе невозможно.
Просто поверь, что более сложную логику я точно также напишу (но за деньги
).Да, и мне казалось в числодробилках обычно довольно однородные типы данных обрабатываются.
EP>В этом примере (перемножение массивов объектов Complex) — тормоза на Java будут даже без учёта GC.
"Тормоза" тут будут только от 12-16 байтов заголовка объекта в Яве, которые будут "разрывать" последовательность даблов.
Как только ты уйдешь от массивов в плюсах, все станет на свои места. Кроме того, как я уже намекнул, твой пример скромно обходит любые выделения памяти