Здравствуйте, Aртём, Вы писали:
Aё>Здравствуйте, greenpci, Вы писали:
G>> UI, например, реализованы на дотнете. Aё>А вот за масдайность гуя надо руки отбивать.
Странная ситуация: Microsoft делает гуй студии и офиса безо всякого дотнета — на нативном коде.
Это видно невооруженным глазом — посмотри на "мистическое число" 32 в строке с соответствуюшими процессами (Windows Task Manager).
Здравствуйте, AlexGin, Вы писали:
Aё>>А вот за масдайность гуя надо руки отбивать. AG>Странная ситуация: Microsoft делает гуй студии и офиса безо всякого дотнета — на нативном коде. AG>Это видно невооруженным глазом — посмотри на "мистическое число" 32 в строке с соответствуюшими процессами (Windows Task Manager).
Кэп: начиная с 2010й студии почти весь ui — wpf. Свежий офис (который для тач-интерфейса) по слухам местами написан с использованием winrt xaml (вот тут я оччень сомневаюсь, но допустим). Стартовое меню в десятке — xaml. Короче, xaml везде Кроме приложений на html (и их вы тоже чёрта с два отличите от обычных).
Кэп #2: разрядность процесса и используемый фреймворк не связаны от слова никак.
Кэп #3: а .net native это куда — в дотнет или в нативный код?
Здравствуйте, Sinix, Вы писали:
S>Кэп: начиная с 2010й студии почти весь ui — wpf. Свежий офис (который для тач-интерфейса) по слухам местами написан с использованием winrt xaml (вот тут я оччень сомневаюсь, но допустим). Стартовое меню в десятке — xaml. Короче, xaml везде Кроме приложений на html (и их вы тоже чёрта с два отличите от обычных).
Офис еще с версии 97 весь на custom draw со своим layout движком, так что xaml там или еще что-то влияет только на удобство программистов.
Здравствуйте, AlexGin, Вы писали:
AG>Странная ситуация: Microsoft делает гуй студии и офиса безо всякого дотнета — на нативном коде.
А еще office team сидит на древней версии Visual Source Safe, даже не TFS. Если они не могут сорсконтрол сменить, то как думаешь когд дойдут руки переписать что-либо на .NET?
Кстати для веб-офиса ситуация обратная. Там все на JS+C#\.NET на сервере.
Тебе ситуация кажется странной, потому что ты не понимаешь экономических мотивов технологических решений.
AG>Это видно невооруженным глазом — посмотри на "мистическое число" 32 в строке с соответствуюшими процессами (Windows Task Manager).
А как связана разрядность процесса и native-managed?
Здравствуйте, greenpci, Вы писали:
G>Поэтому, в этой переписке на дотнет, была бы только маркетинговая привлекательнось.
Давайте объективно смотреть на вещи. Любой код на любом языке размером от 1М строк никто никогда переписывать не будет. Это экономически неоправданно. Вон даже МС в SharePoint имеет ядро на C++, в котором баги сидят с 2001 года (15 лет уже) и оно обеспечивает наибольшие тормоза платформы.
G>Многие удивятся, но зарплата плюсника в Австралии меньше, чем шарпера при прочих равных. Плюсистов на рынке тьма.
А чего удивительного? C++ программист в единицу времени создает меньше добавленной стоимости, чем программист на C#\Java. В условиях насыщенности рынка падение ЗП C++ программистов вполне закономерно.
G>Честно говоря, я не понимаю, зачем все так хотят переписать все на дотнет и джаву.
Никто переписать не хочет. См выше. Но начинать новый проект выгоднее на более высокоуроневом языке.
G>Я понимаю, что гуй и все где "пямять- не ресурс" писать на дотнете быстрее и дешевле. А там где это ресурс, затраты такие же, как минимум, а то и выше.
Самое смешное, что "память не ресурс" сейчас только лишь на десктопе. А на сервере это ресурс (хоть и дешевый), а на мобильных устройствах — очень дорогой ресурс. Но именно на мобилках и серверах .NET и Java встречается чаще всего.
G>Есть знакомый джавист, который пишет быстрый коннективити на джаве. Он рассказывал, как они там извращяются, что бы сделать это действительно быстрым. По его рассказам, трудоемкость не меньше, чем писать на плюсах и думают они так же, как плюсисты. Просто делают все через призму джавы, то есть еще один уровень абстракции, с которым нужно иметь дело.
Не знаю как на Java, а на .NET есть прекрасный пример — компилятор C# (Roslyn). Мало того, что он на .NET, так написан еще и в функциональном стиле, он генерирует кучу мелких объектов и создает изрядный gc pressure. Тем не менее работает быстрее старого csc компилятора, написанного на C++. В интернетах можно найти докалды как оптимизировали Roslyn. Там вообще не космос, постигнуть может практически кто угодно. И никакого unamanaged не надо. А с unmanaged можно писать на C# как на С (c соответствующими скоростями). Разве что математика не такая быстрая получается, но это вроде новым джитом исправляется.
Здравствуйте, Sinclair, Вы писали:
M>>Прямо таки все? И прямо таки сразу? S>Прямо таки да — при первом же обращении (отсюда и термин JIT).
Вам стоит завести блог о производительности Java.
Здравствуйте, mapnik, Вы писали:
M>Господа, я не уверен было уже или нет. Думаю что да, прошу прощения за возможное повторение. M>Читаю подобные темы и неудержимо тянет на гомерический хохот M>http://rsdn.ru/forum/dotnet/6006483.flat.1
M>"С# такая няшечка, в нем столько красивых рюшечек...". Все это в целом мило, но что насчет реально нужных фич, которые имеют действительно сильные проверенные временем ОО-языки? M>Простейший пример оператор const в С++ в применении к функциям (Constant Member Functions).
public class WorldModel
{
public double Gravity { get { return _gravity; } }
private readonly double _gravity;
public double RadiusKm { get { return _radiusKm; } }
private readonly double _radiusKm;
public double MassKg { get { return _massKg; } }
private readonly double _massKg;
public WorldModel(double gravity, double radiusKm, double massKg)
{
_gravity = gravity;
_radiusKm = radiusKm;
_massKg = massKg;
}
public static readonly WorldModel EarthModel = new WorldModel(9.8, 6371, 5.972E24);
}
class Program
{
static void Main(string[] args)
{
//Ooops compile time error.
WorldModel.EarthModel.Gravity = 10.0;
}
}
Так что можно в C# делать аналог константных объектов, которые можно будет изменить только через рефлексию.
Когда я перешел с C++ на C#, то тоже возмущался что нет константных методов, а потом понял, что есть свои паттерны в C# для реализации неизменяемости объекта.
На много сложнее было привыкнуть к разнице работы шаблонов в C++ и дженериков в C#.
P.S. Слабая попытка набрасывания говна на вентилятор — старайся лучше
Здравствуйте, Sinix, Вы писали:
S>Свежий офис (который для тач-интерфейса) по слухам местами написан с использованием winrt xaml (вот тут я оччень сомневаюсь, но допустим).
Здравствуйте, mik1, Вы писали:
M>1) Time to market уменьшается для последующих изменений. M>2) Я не думаю, что с byte[] в Яве управляться труднее, чем в плюсах.
Ну конечно же труднее. Потому, что С предоставляет удобный синтаксис для доступа к данным, лежащим внутри этих byte[]. В реальных задачах почти никогда не нужен byte[], зато нужен complex[] c удобным доступом к complex[i].Re и complex[i].Im. А на java, насколько я в курсе, с этим беда — во-первых, из-за отсутствия пользовательских типов, а во-вторых, из-за запрета реинтерпретации памяти чтобы это починить.
Те из моих знакомых, которые оперировали byte[] на джаве, адски плевались — потому, что для вытаскивания реальных данных из byte[] приходилось применять адские колдунства с вызовами в натив. Это резко понижает производительность труда, т.к. вы выходите за пределы поддержки компилятора. M>3) То, что на Яве молотилки / near realtime делать труднее, чем на плюсах — миф.
Его легко опровергнуть, приведя код перемножения двух complex-массивов, сравнимый по быстродействию с банальным Complex[] operator *=(Complex[] left, Complex[] right).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Aртём, Вы писали: Aё>Вам стоит завести блог о производительности Java.
Вряд ли. Мой опыт с производительностью на Java получен во времена 1.3. Вряд ли все эти годы sun и oracle сидели на попе ровно и никак не улучшали JVM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вряд ли. Мой опыт с производительностью на Java получен во времена 1.3. Вряд ли все эти годы sun и oracle сидели на попе ровно и никак не улучшали JVM.
Ну у Вас весьма много опыта с производительностью на Java, судя по Вашим комментариям- программисты боевых высоконагруженных коннекторов на Java могли бы узнать много нового
Здравствуйте, Sinclair, Вы писали:
S>Те из моих знакомых, которые оперировали byte[] на джаве, адски плевались — потому, что для вытаскивания реальных данных из byte[] приходилось применять адские колдунства с вызовами в натив. Это резко понижает производительность труда, т.к. вы выходите за пределы поддержки компилятора.
Скажите, а те из ваших знакомых, которые оперировали byte[] на джаве- у них какая специализация?
Здравствуйте, Aртём, Вы писали: S>>Те из моих знакомых, которые оперировали byte[] на джаве, адски плевались — потому, что для вытаскивания реальных данных из byte[] приходилось применять адские колдунства с вызовами в натив. Это резко понижает производительность труда, т.к. вы выходите за пределы поддержки компилятора. Aё>Скажите, а те из ваших знакомых, которые оперировали byte[] на джаве- у них какая специализация?
Разработка высокопроизводительных приложений на Java.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
M>>1) Time to market уменьшается для последующих изменений. M>>2) Я не думаю, что с byte[] в Яве управляться труднее, чем в плюсах.
S>Те из моих знакомых, которые оперировали byte[] на джаве, адски плевались — потому, что для вытаскивания реальных данных из byte[] приходилось применять адские колдунства с вызовами в натив. Это резко понижает производительность труда, т.к. вы выходите за пределы поддержки компилятора.
У людей, которым реально приходилось работать с byte[] в Яве, есть мнение, что использовать JNI для этого не умно, т.к. может быть нужно собирать больше одного бинарника.
А вот sun.misc.Unsafe есть всюду (с разными именами). И работает он без просадки производительности.
Здравствуйте, mik1, Вы писали: M>У людей, которым реально приходилось работать с byte[] в Яве, есть мнение, что использовать JNI для этого не умно, т.к. может быть нужно собирать больше одного бинарника. M>А вот sun.misc.Unsafe есть всюду (с разными именами). И работает он без просадки производительности.
Я по-прежнему жду убедительного примера про умножение комплексных массивов на Java. Можете продемонстрировать чудеса владения sun.misc.Unsafe, если это поможет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я по-прежнему жду убедительного примера про умножение комплексных массивов на Java. Можете продемонстрировать чудеса владения sun.misc.Unsafe, если это поможет.
В чём вообще проблема сделать представление области памяти через direct ByteBuffer? Кстати, это документированный способ использования Unsafe.
PS Погуглил жавские квантовые либы — есть http://www.jquantlib.org/en/latest/. Ну и плюснутые либы из жавы никто не отменял — чтоб не изобретать велосипед жава ради жавы.
Здравствуйте, Aртём, Вы писали:
Aё>В чём вообще проблема сделать представление области памяти через direct ByteBuffer? Кстати, это документированный способ использования Unsafe.
Ну, то есть примера не будет. Это же однострочник — его не должно быть трудно написать, не? Aё>PS Погуглил жавские квантовые либы — есть http://www.jquantlib.org/en/latest/. Ну и плюснутые либы из жавы никто не отменял — чтоб не изобретать велосипед жава ради жавы.
О, вот мы уже приходим к идее, что правильный язык для быстрой математики на Java — это C++.
Я вообще плюсы не очень люблю (во всяком случае, меньше Java), но вы их очень хорошо рекламируете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я по-прежнему жду убедительного примера про умножение комплексных массивов на Java. Можете продемонстрировать чудеса владения sun.misc.Unsafe, если это поможет.
Вас не затруднит дать ссылку на аналогичный код на плюсах ? Это чтобы было с чем сравнивать.
Для чистоты экперимента — без нестандартных зависимостей, чтобы мне, не работавшему с плюсами много веков, не так сложно было собирать и запускать этот код
Попутно хотелось бы определить, по каким критериям мы сравниваем.
M>Для чистоты экперимента — без нестандартных зависимостей, чтобы мне, не работавшему с плюсами много веков, не так сложно было собирать и запускать этот код
Пока ты редактировал сообщение, я уже сделал в таком виде Убрать зависимость boost конечно не сложно, но давай уже сделаем это после того как увидим Java версию. M>Попутно хотелось бы определить, по каким критериям мы сравниваем.
Простоту работы со struct-like вещами, а конкретнее — скорость выполнения и удобство кода.
P.S. На Java можно писать быстрый код, но если выходить за рамки каких-то примитивнейших случаев (типа сортировки массива int'ов) — то приходится работать против языка, а не вместе с ним — нужно отказываться от GC и даже классов, и нарезать структуры вручную по массивам байт — по сути это уровень даже ниже чем в языке C.
Кроме приложений на html (и их вы тоже чёрта с два отличите от обычных).
