Но вообще я в этот спор ввязался только из-за вашего смешивания неизменяемости и структур.
Я несколько оговорился. Я не путал, я постулировал, что
1.Структуры обязаны быть неизменяемыми.
2.Изменяемые структуры — путь мучений и невзгод.
3.Неизменяемые структуры — при правильном подходе могут дать хороший буст в некоторых сценариях
В общем то остальное — косноязычие при попытке сформулировать и доказать эту мысль. В частности, попытки доказать, что этих сценариев не так уж мало, чтобы «Забить на них», как в джаве. Хотя и там, насколько я помню, существует выделение памяти на стеке, только там оно автоматизированно. насколько я помню.
При этом в качестве примера приводите крайне не очевидный баг, вызванный наличием этой части языка. И тут же, кстати, в ответ получаете, что при правильном использовании плюсы теряются (улетает в хип).
ну да, я же не любитель представлять только в выгодном свете, нужно учитывать плюсы и минусы.
Как вообще структуры связаны с thread safety? Неизменяемый класс ни чуть не менее thread safety, чем структура. Посмотрите на scala и akka — весьма безопасная многопоточность благодаря удобным неизменяемым классам и механизмам работы с ними (на jvm).
неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.
Я знаю только 2 профита от структур: тяжелая арифметика и размещение в массиве. Это полезно в очень редких случаях. При этом на jvm можно таких же улучшений добиться, хоть и с чуть большими затратами.
может в этом дело — последнее время я работаю с массивами структур, в частности при триангуляции объектов в 3d-моделировании, над которыми, соответственно, проводятся довольно непростые вычисления…
Я вообще ни чего подобного не писал. Мое мнение выше: есть крайне узкая ниша полезности структур в C# и не то, чтобы без них не обойтись.
а я говорил, что без них нельзя обойтись? Просто если можно их в язык поместить — почему бы и нет, если есть сценарии, когда они удобны. Они применяются не часто, но всегда по делу.
Ладно, уже ушли от темы, и возможно, я не прав, так что тем более нужно перевсти тему :)
Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя, если не хочется за каждым чихом писать код на другом, более низкоуровневом языке (С++ тот же). Андройд выпустил целый NDK, потому что java-приложения часто из-за своей высокоуровневости и абстракции не обеспечивали нужной производительности.
Никто не заставляет ими пользоваться. Но само их наличие — это очень нехилый буст для определенных задач.
Если нужен иммутабельный класс (той же даты), то её логично сделать структурой — получаем бонус от thread safety и прочего. Если не нужно — пишем обычный класс и не пытаемся себе отстрелить ногу мутабельными структурами.
В общем, имхо — это ценная возможность, которую нужно уметь применять, потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций, а несколько больше. Не всегда узкое место — медленная выгрузка из базы по узкому каналу, иногда и так бывает.
Ваше мнение: для низкоуровневых задач использовать С/С++ (насколько я понял из речей выше), мое — хорошо, когда все есть в одном языке и не нужно возиться с P/Invoke. И то и то имеет право на жизнь, но мое мнение, логично, я считаю более правильным (иначе бы я его изменил на ваше :) )
Да, несколько косноязчыно сказал. Мысль в том, что выделение памяти для структур заключается всего лишь в увеличении указателя стека, причем память под все локальные переменные выделяются вообще одной инструкцией. В то время как выделение памяти с помощью newobj несколько более затратно (хотя и намного быстрее, чем new в каком-нибудь C++). Ну и то, что структуры уничтожаются сразу при выходе из области видимости (по той же причине со стеком), а объекты должны пережить сборку мусора. Особенно если это объекты с финализаторами.
И даже множественные присвоения стэковой переменной получаются быстрее, чем изменение переменной по ссылке. Естественно, граничные условия в которых все наборот — существуют, но в целом картина такая. Если бы от структур не было бы толка — их не стали бы вводить в язык. Обошлись бы классами, а для взаимодействия с неуправляемым кодом позволили бы классам также иметь атрибут ClassLayout, например
Ну например строки в C# — иммутабельны. Это не мешает вполне нормально с ними работать. А то, что структуры даже если их копировать при каждом присваивании быстрее, чем объекты в куче — вы же, конечно, это знаете?
А структуры по-умолчанию иммутабельны. Потому что мутабельные структуры — прекрасный способ отстрелить себе все что можно. На примере int видно, зачем могут быть нужны иммутабельные структуры.
Вовсе нет. Моя точка зрения в том, что оптимизировать стоит 1% кода, который действительно является узким местом и от этого будет польза.
совершенно верно
А от оптимизации 99% кода сомнительными практиками типа структур
а вот с тем, что использование структур это плохая практика — категорически не согласен. Вряд ли бы вам понравилась запись int a = 5;
int b = a.Clone()
из-за того, что иначе a и b указывали бы на пятерку, а не присваивались просто и понятно.
Естественно, я говорю про иммутабельный структуры с полями read-only.
Заранее ничего нельзя предусмотреть со 100% точностью. Это абсолютно нормально, такова жизнь.
да, но не до такой степени же, что «ой, ребят, вы мне сайт делаете, я на самом деле хотел приложение в аппстор».
Заказчику не нужно ПО, которое работает на 10% быстрее и на 10% экономнее по памяти, но при этом периодически валится по непонятной причине в самый неподходящий момент.
В жизни есть ценности поважнее пары сэкономленных байт.
100% прирост по памяти, путем замены слова class на поле struct, это, конечно, огромные затраты ресурсов за ничтожный выигрыш.
но при этом периодически валится по непонятной причине в самый неподходящий момент.
ой, опять придумываете. В общем, ваша ТЗ ясна. От структур одно зло. Ваша воля — класс byte паковался бы тоже в класс, чтобы занимать в 5(9) раз больше места.
Тем более, что это возможность, а не обязанность. Недостаток VM, которая просирает все типы во время рантайма, тоже предоставляется как достоинство. Круто, что сказать.
Это связано не с MSIL, а с развитием кода. В самый неожиданный момент выясняется, что метод должен быть виртуальным, что бы его перекрыть.
значит, нужно было думать раньше, а не в последний момент. «Наговнокодим — а там как-нибудь разберемся», а виноваты в этом, конечно же, IDE, язык, ось, что угодно, но не мы.
Я считаю, что компилятор и среда выполнения должны быть достаточно умны, что бы самостоятельно оптимизировать код, написанный без низкоуровневой оптимизации и хаков. Можно сказать, Oracle Java вполне удовлетворяет этому требованию. Поэтому, не вижу смысла захламлять обычный код хаками и низкоуровнемыми оптимизациями.
какой хак? какия низкоуровневая оптимизация? Как раз в тему попадалась хаброцитата
«Переход на графен откроет совершенно новую эпоху — частота электронных устройств может достигнуть терагерца.»
exvel: Ну, слава богу. Можно продолжать говнокодить.
А то логика «пусть за меня это делает компьютер. Если компьютер еще недостаточно умен, чтобы решать это за меня — значит пользователям не повезло, т.к. я слишком себя люблю, чтобы париться знанием устройства ЭВМ»
А еще, например, в C# невиртуальные методы со временем стремятся превратиться в виртуальные.
Это с какого вы взяли? Разве что с того, что и обычные, и виртуальные методы вызываются MSIL-овской командой callvirt?
Насчет похожих структур: во-первых ссылка потребляет +4 (+8 для х64) байт, во-вторых уменьшается вероятность попадания данных в кэш. Может джваисты уже окончательно забили на производительность, но структура из двух интов занимает 8 байт, а вот экземпляр класса — 12, а в x64 — все 16. Я бы не хотел раздувать размер объектов в 2 раза, да и еще терять на скорости, из-за аллокации памяти в кучи, а не на стеке.
Кто вам такую глупость сказал?
Я эту настройку никогда не трогал (не знал про её существование), вот скрин с моего рабочего компа:
Я несколько оговорился. Я не путал, я постулировал, что
В общем то остальное — косноязычие при попытке сформулировать и доказать эту мысль. В частности, попытки доказать, что этих сценариев не так уж мало, чтобы «Забить на них», как в джаве. Хотя и там, насколько я помню, существует выделение памяти на стеке, только там оно автоматизированно. насколько я помню.
ну да, я же не любитель представлять только в выгодном свете, нужно учитывать плюсы и минусы.
неизменяемые структуры — это то же самое, что неизменяемые классы, только быстрее.
может в этом дело — последнее время я работаю с массивами структур, в частности при триангуляции объектов в 3d-моделировании, над которыми, соответственно, проводятся довольно непростые вычисления…
а я говорил, что без них нельзя обойтись? Просто если можно их в язык поместить — почему бы и нет, если есть сценарии, когда они удобны. Они применяются не часто, но всегда по делу.
Я считаю, что структуры — важная часть языка, и возможность их использования очень нелишняя, если не хочется за каждым чихом писать код на другом, более низкоуровневом языке (С++ тот же). Андройд выпустил целый NDK, потому что java-приложения часто из-за своей высокоуровневости и абстракции не обеспечивали нужной производительности.
Никто не заставляет ими пользоваться. Но само их наличие — это очень нехилый буст для определенных задач.
Если нужен иммутабельный класс (той же даты), то её логично сделать структурой — получаем бонус от thread safety и прочего. Если не нужно — пишем обычный класс и не пытаемся себе отстрелить ногу мутабельными структурами.
В общем, имхо — это ценная возможность, которую нужно уметь применять, потому что профит от нее зачастую не 2% за потраченную неделю оптимизаций, а несколько больше. Не всегда узкое место — медленная выгрузка из базы по узкому каналу, иногда и так бывает.
Ваше мнение: для низкоуровневых задач использовать С/С++ (насколько я понял из речей выше), мое — хорошо, когда все есть в одном языке и не нужно возиться с P/Invoke. И то и то имеет право на жизнь, но мое мнение, логично, я считаю более правильным (иначе бы я его изменил на ваше :) )
К чему вспомнил: вот это — действительно отстрел ноги, можете попробовать этот код для просветления:
Кстати еслиб энумератор был «в хипе», то этого эффекта не наблюдалось бы.
И даже множественные присвоения стэковой переменной получаются быстрее, чем изменение переменной по ссылке. Естественно, граничные условия в которых все наборот — существуют, но в целом картина такая. Если бы от структур не было бы толка — их не стали бы вводить в язык. Обошлись бы классами, а для взаимодействия с неуправляемым кодом позволили бы классам также иметь атрибут ClassLayout, например
stackoverflow.com/questions/2365272/why-net-string-is-immutable
А структуры по-умолчанию иммутабельны. Потому что мутабельные структуры — прекрасный способ отстрелить себе все что можно. На примере int видно, зачем могут быть нужны иммутабельные структуры.
совершенно верно
а вот с тем, что использование структур это плохая практика — категорически не согласен. Вряд ли бы вам понравилась запись
int a = 5; int b = a.Clone()из-за того, что иначе a и b указывали бы на пятерку, а не присваивались просто и понятно.
Естественно, я говорю про иммутабельный структуры с полями read-only.
да, но не до такой степени же, что «ой, ребят, вы мне сайт делаете, я на самом деле хотел приложение в аппстор».
100% прирост по памяти, путем замены слова class на поле struct, это, конечно, огромные затраты ресурсов за ничтожный выигрыш.
ой, опять придумываете. В общем, ваша ТЗ ясна. От структур одно зло. Ваша воля — класс byte паковался бы тоже в класс, чтобы занимать в 5(9) раз больше места.
Тем более, что это возможность, а не обязанность. Недостаток VM, которая просирает все типы во время рантайма, тоже предоставляется как достоинство. Круто, что сказать.
Как захотели, так и извратили.
значит, нужно было думать раньше, а не в последний момент. «Наговнокодим — а там как-нибудь разберемся», а виноваты в этом, конечно же, IDE, язык, ось, что угодно, но не мы.
какой хак? какия низкоуровневая оптимизация? Как раз в тему попадалась хаброцитата
А то логика «пусть за меня это делает компьютер. Если компьютер еще недостаточно умен, чтобы решать это за меня — значит пользователям не повезло, т.к. я слишком себя люблю, чтобы париться знанием устройства ЭВМ»
Это с какого вы взяли? Разве что с того, что и обычные, и виртуальные методы вызываются MSIL-овской командой callvirt?
Насчет похожих структур: во-первых ссылка потребляет +4 (+8 для х64) байт, во-вторых уменьшается вероятность попадания данных в кэш. Может джваисты уже окончательно забили на производительность, но структура из двух интов занимает 8 байт, а вот экземпляр класса — 12, а в x64 — все 16. Я бы не хотел раздувать размер объектов в 2 раза, да и еще терять на скорости, из-за аллокации памяти в кучи, а не на стеке.
Вот — конкретная заявка на производительность.
Про нативное — в контексте андройда и десктопа.