Здравствуйте, Serginio1, Вы писали:
S>·>Они могут стать реже. Но куда они денутся? S> Задержки никуда не денутся, но они могут быть меньше 4 мс или какого то допустимого порога.
А могут и не быть меньше, никто ничего не обещает. А вот azul даёт такую гарантию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:1
S>·>Это может говорить о качестве такого компилятора, то что для него это — мучение. Правильно, как там vdimas упомянул? "зачем мучить компьютер компиляцией, когда у нас есть девушки". S>·>Если придётся по какой-то причине понадобится реализовать похожий алгортим самому, в своём коде — компилятор тоже не осилит, и здравствуй unsafe, каша из топора. S> Вот для .Net Native можно писать как угодно. Там скорость компиляции не важна. А вот jit малооптимизирующий компилятор.
java native тоже было, см. GCJ, но померло, ибо не нужен, как оказалось, JIT мало в чём уступает AOT. Если понадобится — возродят, проблем нет.
S>>>Многие в нативе вообще ассемблерные вставки используют. S>·>Если вставки для системных вещей — ок, если для прикладных, — не ок. S> Так String это чуть ли не основной класс. Его стоит вылизать. То есть на C++ это нормально, а для C# это нонсенс.
Я в C++ не видел ассемблерных вставок в реализации std::basic_string или std::vector, в java тоже всё в пределах языка, без всяких native. А c# — это да, нонсенс.
S> То есть вполне возможно появление
Денег нет, вы держитеть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти? S>>>> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml
S>>·>Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться. S>> Ну так на этом все нативные менеджеры построены. И ведь работают. А для твоего теста они подходят лучше всего. Просто в .Net ты можешь комбинировать. ·>Ты не понял. То что в нативных менеджерах нет дефрагментации — это недостаток, ибо её реализовать невозможно, т.к. объекты неперемещаемые. В managed же объекты можно перемещать, компактифицируя кучу, делая её более cache friendly и прочее. Если тебе тупо не нужна дефрагметация кучи в gc, ты её можешь тупо отключить одним флажочком.
Есть куча задач и как раз в твоем примере, где нативные кучи рулят. S>>>>·>А зачем нужен бессмысленный тест? S>>>>Это ответ на то как поможет нативный менеджер памяти. S>>·>Он использует локи, критические секции, что практически не допустимо для LL. S>> Можно так же использовать все те же interlockedexchange. Этих менеджеров памяти достаточно много. https://habrahabr.ru/company/billing/blog/238787/ ·>Таким же образом может помочь выбор gc-алгоритма и параметров.
Вот для конкретного примера самый оптимальный вариант именно нативная куча.
S>>>>·>Ок, подытожу. S>>>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). S>>>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта. S>> Ну это нужно сравнивать в тестах. Что лучше. ·>Сравнивать в тестах что? Упрощение ЖЦ проекта??
Сравнивать задержки при уменьшении работы ГЦ S>>>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего. S>>·>Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял. S>> Ну можно писать и на нескольких языках если команда большая. Делать смешанные классы на C++, а использовать их на всех других нетовских языках. Сейчас F# продвигается активно. ·>Можно, но не нужно. К тому же на java никто не запрещает использовать C++ и прочие активно продвигаемые scala/kotlin/ceylon/closure/groovy/etc.
Все зависит от задачи. Там где это выгодно почему обязательно можно совмещать и манагед и натив.
Я ничего против Java не имею. Я говорю только об оптимальном использовании нативного менеджера памяти и GC.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:1
S>>·>Это может говорить о качестве такого компилятора, то что для него это — мучение. Правильно, как там vdimas упомянул? "зачем мучить компьютер компиляцией, когда у нас есть девушки". S>>·>Если придётся по какой-то причине понадобится реализовать похожий алгортим самому, в своём коде — компилятор тоже не осилит, и здравствуй unsafe, каша из топора. S>> Вот для .Net Native можно писать как угодно. Там скорость компиляции не важна. А вот jit малооптимизирующий компилятор. ·>java native тоже было, см. GCJ, но померло, ибо не нужен, как оказалось, JIT мало в чём уступает AOT. Если понадобится — возродят, проблем нет.
.Net Native хорош для мобильных устройств. На яблоках кстати Java нет, а .Net есть.
S>>>>Многие в нативе вообще ассемблерные вставки используют. S>>·>Если вставки для системных вещей — ок, если для прикладных, — не ок. S>> Так String это чуть ли не основной класс. Его стоит вылизать. То есть на C++ это нормально, а для C# это нонсенс. ·>Я в C++ не видел ассемблерных вставок в реализации std::basic_string или std::vector, в java тоже всё в пределах языка, без всяких native. А c# — это да, нонсенс.
Я рад за вас. S>> То есть вполне возможно появление ·>Денег нет, вы держитеть.
Так уже же появлся https://github.com/antiufo/roslyn-linq-rewrite
Example input code
public int Method1()
{
var arr = new[] { 1, 2, 3, 4 };
var q = 2;
return arr.Where(x => x > q).Select(x => x + 3).Sum();
}
Allocations: input array, array enumerator, closure for q , Where delegate, Select delegate, Where enumerator, Select enumerator.
Decompiled output code
public int Method1()
{
int[] arr = new[] { 1, 2, 3, 4 };
int q = 2;
return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
if (_linqitems == null) throw new ArgumentNullException();
int num = 0;
for (int i = 0; i < _linqitems.Length; i++)
{
int num2 = _linqitems[i];
if (num2 > q)
num += num2 + 3;
}
return num;
}
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Ikemefula, Вы писали:
I>>>>Не было никакой форы, кучу софта было просто не выгодно писать, об указатели постоянно спотыкались. I>>·>Вот именно! java предложила киллер-фичу — managed, решила проблему сломанных указателей и некоторые другие, поэтому даже 30+ лет фора не послужила помехой. I>>Алё — не было никакой форы. Ибо переход native-managed. Новая экономическая ниша и конкуренты у джавы отсутствовали ! ·>Само по себе "managed" не является причиной перехода. А именно то, что managed даёт ощутимые game changing преимущества, которые перевешивают недостатки. Ты хочешь сказать, что у c# вообще никаких преимуществ перед java нет, дык об чём речь тогда?
Ты уж постарайся запомнить — перформанс не единственное свойство. Если люди выбирают открытость в ущерб производительности, то вроде и ежу понятно, что перформанс роли не сыграет.
Зато когда тебе нужна не только открытость, но и перформанс, в таких проектах С# и будет успешно конкурировать с Джавой. С открытостью сейчас проблемы, но они решаются. Есть и другие, они тоже решаются.
I>>А здесь — есть. managed-managed. На самом деле это не так страшно, как кажется. Дотнет практически всегда в качестве догоняющего. Более того, IIS из нуля откусил долю рынка аккурат за счет дотнета. ·>Так тут меня убеждают, что c# это супер-пупер-мега-экста-максимум, голов эдак на 100 выше Java по всем фронтам.
Открытость платформы перевешивает почти любые технические преимущества. С т.з. долгоиграющих проектов нужны не кульные баззворды, а стабильный рынок труда, где нужного спеца можно найти за вменяемое время.
Вот у микрософта этого не получается, ибо они рожают и депрекейтят технологии чуть не каждый месяц.
Здравствуйте, Serginio1, Вы писали:
S>Нет привязки к винде. S> Но есть метод unsafe internal int ConvertToAnsi(byte *pbNativeBuffer, int cbNativeBuffer, bool fBestFit, bool fThrowOnUnmappableChar) S>который использует
Привязки нет, но есть привязка Что делать на тех платформах, где нет MultiByteToWideChar ?
Здравствуйте, ·, Вы писали:
I>>Представляю I>> ·>Ну почти, если тормоза будут упущены на этапе perf tests, то можно будет прод-сервак перезапустить с другими параметрами gc (изменить размер YG или возраст отправки в OG, например).
Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов.
I>> Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении. I>>Как только ты перебрал определенный лимит, часть объектов уходит в старое поколение и ты на это никак повлиять не можешь ·>Который из gc? minor gc не так страшен.
I>>То есть, off-heap нужен для того, что бы исключить gc по максимуму ·>Нет, он нужен чтобы изменение графа объектов в OG не вызывал известно бесполезные, но болезненные major gc.
Это и есть "исключить GC". Граф объектов есть, а проходов GC по ём нет.
Здравствуйте, ·, Вы писали:
I>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы. I>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде. ·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe.
И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка.
То есть, любая самая распрекрасная реализация числодробилки на менеджед сливает нативному коду. Как бы ты ни старался, менеджед код не может и никогда не будет работать так же быстро, как и нативный. У него особенность — он менеджед аккурат за счет того, что перформанс на втором месте.
Более того, с т.з. быстродействия, строки и массивы как раз и определяют всё, вообще всё — 80-90% операций происходит с этими двумя типами.
Особенно критично для маршалинга, интеропа, больших размеров данных и тд.
Это было известно примерно в 2001м году, когда были опубликованы исходники Rotor. Ты как то запоздало срываешь покровы
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
S>>Нет привязки к винде. S>> Но есть метод unsafe internal int ConvertToAnsi(byte *pbNativeBuffer, int cbNativeBuffer, bool fBestFit, bool fThrowOnUnmappableChar) S>>который использует
I>Привязки нет, но есть привязка Что делать на тех платформах, где нет MultiByteToWideChar ?
Напишут аналог под платформу.
Там же куча условий для предпроцессора
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>·>Ты не понял. То что в нативных менеджерах нет дефрагментации — это недостаток, ибо её реализовать невозможно, т.к. объекты неперемещаемые. В managed же объекты можно перемещать, компактифицируя кучу, делая её более cache friendly и прочее. Если тебе тупо не нужна дефрагметация кучи в gc, ты её можешь тупо отключить одним флажочком. S> Есть куча задач и как раз в твоем примере, где нативные кучи рулят.
С чего ты взял что они рулят только лишь потому, что они нативные? Может быть просто конкретная реализация managed кучи недостаточно хороша? Как раз у managed-кучи больше простора для оптимизаций.
S>·>Таким же образом может помочь выбор gc-алгоритма и параметров. S> Вот для конкретного примера самый оптимальный вариант именно нативная куча.
Как альтернатива конкретной имплементации dotnet-ной кучи? Верю. В общем случае — не верю.
S>>>>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). S>>>>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта. S>>> Ну это нужно сравнивать в тестах. Что лучше. S>·>Сравнивать в тестах что? Упрощение ЖЦ проекта?? S> Сравнивать задержки при уменьшении работы ГЦ
Я говорил о другом, перечитай.
S>·>Можно, но не нужно. К тому же на java никто не запрещает использовать C++ и прочие активно продвигаемые scala/kotlin/ceylon/closure/groovy/etc. S> Все зависит от задачи. Там где это выгодно почему обязательно можно совмещать и манагед и натив.
Не путай "выгодно" и "приходится, т.к. иначе тупо не работает".
S> Я ничего против Java не имею. Я говорю только об оптимальном использовании нативного менеджера памяти и GC.
Оптимально — использовать нативное как можно реже. Чем меньше ситуаций, когда вместо managed нужно спускаться до native/unsafe — тем лучше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Ты не понял. То что в нативных менеджерах нет дефрагментации — это недостаток, ибо её реализовать невозможно, т.к. объекты неперемещаемые. В managed же объекты можно перемещать, компактифицируя кучу, делая её более cache friendly и прочее. Если тебе тупо не нужна дефрагметация кучи в gc, ты её можешь тупо отключить одним флажочком. S>> Есть куча задач и как раз в твоем примере, где нативные кучи рулят. ·>С чего ты взял что они рулят только лишь потому, что они нативные? Может быть просто конкретная реализация managed кучи недостаточно хороша? Как раз у managed-кучи больше простора для оптимизаций.
Для данной задачи когда объекты определенного размера то managed-кучи рулят.
Но опять же ты так и не привел примера на твоем ГЦ. S>>·>Таким же образом может помочь выбор gc-алгоритма и параметров. S>> Вот для конкретного примера самый оптимальный вариант именно нативная куча. ·>Как альтернатива конкретной имплементации dotnet-ной кучи? Верю. В общем случае — не верю.
Еще раз ты так и не привел результатов. Так, что не с чем сравнивать.
S>>>>>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира). S>>>>>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта. S>>>> Ну это нужно сравнивать в тестах. Что лучше. S>>·>Сравнивать в тестах что? Упрощение ЖЦ проекта?? S>> Сравнивать задержки при уменьшении работы ГЦ ·>Я говорил о другом, перечитай.
Сравнивай не только задержки но и общую производительность. Твоя задача вообще говоря единичная и для её оптимизации все средства хороши. Но что бы что то выбрать нужно сравнить.
S>>·>Можно, но не нужно. К тому же на java никто не запрещает использовать C++ и прочие активно продвигаемые scala/kotlin/ceylon/closure/groovy/etc. S>> Все зависит от задачи. Там где это выгодно почему обязательно можно совмещать и манагед и натив. ·>Не путай "выгодно" и "приходится, т.к. иначе тупо не работает".
S>> Я ничего против Java не имею. Я говорю только об оптимальном использовании нативного менеджера памяти и GC. ·>Оптимально — использовать нативное как можно реже. Чем меньше ситуаций, когда вместо managed нужно спускаться до native/unsafe — тем лучше.
Если натив дает существенный прирост производительности и эта производительность необходима, то нужна.
В большинстве задач хватает и производительности Jit а и GC
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
I>>Привязки нет, но есть привязка Что делать на тех платформах, где нет MultiByteToWideChar ? S> Напишут аналог под платформу. S> Там же куча условий для предпроцессора
Напишут. По уму это надо должно быть частью архитектуры, N нативных методов. Но товарищи пошли особым путём.
Здравствуйте, Serginio1, Вы писали:
S>>> Вот для .Net Native можно писать как угодно. Там скорость компиляции не важна. А вот jit малооптимизирующий компилятор. S>·>java native тоже было, см. GCJ, но померло, ибо не нужен, как оказалось, JIT мало в чём уступает AOT. Если понадобится — возродят, проблем нет. S> .Net Native хорош для мобильных устройств. На яблоках кстати Java нет, а .Net есть.
А это что? http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html
Блин, урезанную java вон на банковских и SIM-картах запускают, а тут мобилы многоядерные...
S>·>Я в C++ не видел ассемблерных вставок в реализации std::basic_string или std::vector, в java тоже всё в пределах языка, без всяких native. А c# — это да, нонсенс. S> Я рад за вас.
Спасибо, и вам того же желаю.
S>>> То есть вполне возможно появление S>·>Денег нет, вы держитеть. S> Так уже же появлся https://github.com/antiufo/roslyn-linq-rewrite
Ну вроде ещё не production ready...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> Вот для .Net Native можно писать как угодно. Там скорость компиляции не важна. А вот jit малооптимизирующий компилятор. S>>·>java native тоже было, см. GCJ, но померло, ибо не нужен, как оказалось, JIT мало в чём уступает AOT. Если понадобится — возродят, проблем нет. S>> .Net Native хорош для мобильных устройств. На яблоках кстати Java нет, а .Net есть. ·>А это что? http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html ·>Блин, урезанную java вон на банковских и SIM-картах запускают, а тут мобилы многоядерные...
Которые взрыватюся
Ну и какие там задачи решают на симкартах? В .Net може есть https://ru.wikipedia.org/wiki/.NET_Micro_Framework S>>·>Я в C++ не видел ассемблерных вставок в реализации std::basic_string или std::vector, в java тоже всё в пределах языка, без всяких native. А c# — это да, нонсенс. S>> Я рад за вас. ·>Спасибо, и вам того же желаю.
S>>>> То есть вполне возможно появление S>>·>Денег нет, вы держитеть. S>> Так уже же появлся https://github.com/antiufo/roslyn-linq-rewrite ·>Ну вроде ещё не production ready...
Можно уже использовать.
"tools": {
"dotnet-compile-csc-linq-rewrite": {
"version": "1.0.1.9",
"imports": "portable-net45+win8+wp8+wpa81"
}
}
никакие не бетта или pre
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>>> I>·>Ну почти, если тормоза будут упущены на этапе perf tests, то можно будет прод-сервак перезапустить с другими параметрами gc (изменить размер YG или возраст отправки в OG, например). I>Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов.
А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится?
I>>>То есть, off-heap нужен для того, что бы исключить gc по максимуму I>·>Нет, он нужен чтобы изменение графа объектов в OG не вызывал известно бесполезные, но болезненные major gc. I>Это и есть "исключить GC". Граф объектов есть, а проходов GC по ём нет.
Не "исключить", а уменьшить интенсивность его использования. Вот в dotnet Sustained LL gc mode — да, это "исключить". И ещё раз повторюсь, с развитием качества gc и других алгоритмов (pauseless gc) необходимость offheap падает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде. I>·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe. I>И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка.
Не должны (но могут, если язык недостаточно быстр). Как quicksort зависит от платформы? quicksort не числодробилка. Почему реализация std::sort в C++ не зависит от платформы? Могли бы уж вылизать ассемблерными вставками...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
I>>Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов. ·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится?
Магически — никак. off-heap в java(и .Net) это переизобретение аллокаторов из C++.
Такую стратегию управления памятью надо откалибровать во время разработки.
Это демонстрация заблуждения "Сборка молодого поколения практически бесплатна."
Она бесплатна сильно условно, гарантии обеспечиваешь ты сам, как вариант — с помощью off-heap решений в менеджед, или аллокаторов — в С++.
I>>Это и есть "исключить GC". Граф объектов есть, а проходов GC по ём нет. ·>Не "исключить", а уменьшить интенсивность его использования. Вот в dotnet Sustained LL gc mode — да, это "исключить". И ещё раз повторюсь, с развитием качества gc и других алгоритмов (pauseless gc) необходимость offheap падает.
Разница в частоте срабатываний примерно 2-3 порядка. Это и есть "исключить". Необходимость не только offheap падает, но и растёт Объемы данных растут быстрее, чем улучшаются алгоритмы и соответсвенно качество работы GC.
Сейчас вобщем не редкость, когда приходится хранить миллиарды объектов в памяти. Самый распрекрасный GC сосёт не нагибаясь.
Здравствуйте, Serginio1, Вы писали:
S>·>Как альтернатива конкретной имплементации dotnet-ной кучи? Верю. В общем случае — не верю. S> Еще раз ты так и не привел результатов. Так, что не с чем сравнивать.
Ты тоже не привёл никаких результатов. Пока были только твои спекуляции, что с native кучей оно непременно заработает быстрее.
S>·>Я говорил о другом, перечитай. S> Сравнивай не только задержки но и общую производительность. Твоя задача вообще говоря единичная и для её оптимизации все средства хороши. Но что бы что то выбрать нужно сравнить.
Ещё раз повторяю — задержки (latency) и общуя производительность (throughput) — разные аспекты, которые друг-другу противоречат зачастую.
S>>> Я ничего против Java не имею. Я говорю только об оптимальном использовании нативного менеджера памяти и GC. S>·>Оптимально — использовать нативное как можно реже. Чем меньше ситуаций, когда вместо managed нужно спускаться до native/unsafe — тем лучше. S> Если натив дает существенный прирост производительности и эта производительность необходима, то нужна.
Не обязательно "нужна". Альтернативное решение — взять managed, который _достаточно_ производительный.
S> В большинстве задач хватает и производительности Jit а и GC
В большинстве задач хвататет и производительности PHP.
Суть в том, что чем меньше таких задач, когда не хватает производительности managed и приходится использовать native — тем лучше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
I>>>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде. I>>·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe. I>>И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка. ·>Не должны (но могут, если язык недостаточно быстр). Как quicksort зависит от платформы? quicksort не числодробилка. Почему реализация std::sort в C++ не зависит от платформы? Могли бы уж вылизать ассемблерными вставками...
quicksort не числодробилка...Могли бы уж вылизать ассемблерными вставками
Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка. Отсюда ясно, что сколько перформанса не дай, всё равно мало. Ассемблерными вставками вылизать трудно прежде всего потому, что это надо делать под разные процессоры, не говоря про семейства процессоров.
Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
Здравствуйте, ·, Вы писали:
S>> В большинстве задач хватает и производительности Jit а и GC ·>В большинстве задач хвататет и производительности PHP. ·>Суть в том, что чем меньше таких задач, когда не хватает производительности managed и приходится использовать native — тем лучше.
Вот здесь подробнее. Вот надо за доли секунды обработать пару миллиардов строчек статистики, потому что бизнесу это даёт один доллар каждую миликунду. Ты пойдешь к бизнесу и скажешь "чем меньше таких задач ...тем лучше" ?
Ты уж постарайся запомнить — перформанс не единственное свойство. Если люди выбирают открытость в ущерб производительности, то вроде и ежу понятно, что перформанс роли не сыграет.
Что делать на тех платформах, где нет MultiByteToWideChar ?
