Re[12]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 13:29
Оценка:
Здравствуйте VladD2, Вы писали:

Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому.

VD>Ну, а чего тогда ты пытаешься здесь доказать?

Что многоплатформенность — не полностью бесполезная вещь. Больше ничего.

VD>Я вообще не понимаю как можно судить о качестве, возможностях, а главное востребованности системы не найдя в ней какой-нибудь финтифлюшки.

Я по моему не говорил что .Net неприменим из-за отсутствия связанного списка. Просто я тебе пример привел сыроватости библиотеки дотнета.

VD>Может у меня действительно мозги не так работают. Ну, сказывается время проведенное за C++...

Я тоже на C++ писал, особенно под Win32 (когда Борланд на Паскаль забил а Дельфи еще не вышла)
VD> Но я ни как не могу понять, ну, даже если нет нужной тебе реализации связанного списка, ну, так сядь и напиши.
Я напишу. Но ведь это время!
VD> Алгоритмы то там плевые.
Да все я прекрасно понимаю. Мне вот интересно — почему в библиотеке его нет? Недосмотр или специально так сделано?

VD> Или берешь массив и делаешь к нему нужные методы (может выйти эффективнее) или работать на ссылках.

А вот ArrayList как раз и сделан на основе массивов. И произвольный доступ там очень быстрый. А вот добавление-удаление ... Пример я привел.

VD>В конце концов если тебя .Net не устраивает,

Где я такое написал?

VD> то что ты его не бросишь и не продолжишь работать на Яве.

А кто сказал что я на java не работаю?

VD> Она на сегодня неплохо развилась... грабли все ее ты уже знаешь... они тебя не смущают... так бросай других агитировать.

Где я кого нибудь агитировал? Пока здесь агитируешь исключительно ты сам. И почему то упорно всем пытаешся доказать что ,Net это идеал а все остальное ацтой.

VD> .Net это для тех кто программировал COM на C++ или VB, и для тех кому больше важна гибкость, а не переносимость.

Я что то делал и на С++ и на Дельфи, под COM/DCOM, на 1С, на php, на java, на VB вот только не довелось. Мне как — подходит?

Меня убивает твоя позиция — для тебя все черное или белое. Либо рулез немеряный либо сакс полный. Любая технология имеет свои недостатки и свои достоинства, даже php. И надо уметь в каждом конкретном случае выбрать наиболее эффективную.
AVK Blog
Re[12]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 13:59
Оценка:
Здравствуйте VladD2, Вы писали:

AVK>>ОК. Давай, расскажи хотя бы про 1 пункт. Как мне на .Net получить LinkedList?



VD>
VD>class Node
VD>{
VD>   publib Noden pNext = null;
VD>   SomeDataType SomeData;
VD>};
VD>...

VD>Node Root = new Node();

VD>Node pNewNode = Root;
VD>for(int i = 0; i < 100; i++)
VD>{
VD>  Node pTmp = new Node();
VD>  pNewNode.pNext = pTmp;
VD>  pNewNode = pTmp;
VD>}
VD>


VD>Если очень хочется, можешь написать универсальную реализацию с интерфейсом IList.

Вот это я и хотел доказать — придется писать ручками с нуля. Больше вопросов нет.


AVK>>Но, в отличие от того же веб софта КИС очень активно видоизменяется в процессе жизнедеятельности. А планировать на 5 лет вперед просто не реально.

VD>Т.е. форумы не изменяются. Ты это IT раскажи вот он обрадуется. :)
Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше.

AVK>> как правило на этих фирмах уже накоплен приличный багаж. Ты предлагаешь все это похерить и переписать все заново.


VD>Если фирма растет, такие изменения происходят постоянно и система постоянно перепроектируется. В некоторых этпапх, когда руководство тех. отдела понимает, что количество примочек слишком велико, принимается решение и перепроектируется система. В ином случае фирма или перестает расти, или плюет на систему автоматизации, или дохнет.

Извини, но ты не прав. Я уже тебе говорил — даже если руководство согласно отдавать IT почти всю прибыль — частая замена информационных систем приведет к полному краху. Ибо людей не переделать. Если у тебя нет опыта внедрения подобных систем — не стоит на эту тему спорить. Я тебе говорил — там все по другому.

AVK>>И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки.

VD>Когда выбор стоит между тяжолым решением и прозибанием, зачастую выбирается трудная жизнь, а не легкая смерть. :)
Ну когда такой выбор стоит — тогда конечно

VD>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете?

Нет. Но когда тебе говорят что черное это белое...

AVK>> И именно на этот софт нацелены все те технологии которые вызывают здесь ожесточенные споры в их нужности.


VD>Да ну? А вто я, IT и MS думаем по другому. MS конечно не помешает замена VB, но он MS был бы не MS если бы в их планы не входил захват всех рынков на которых можно зарабатывать деньги. Не удевлюсь если через пру лет MS начнет обсуждать вопросы разработки драйверов на C#.

Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.
А за других я бы на твоем месте не стал говорить.

VD>Чтобы понять разницу между Явой И Нэтом нужно написать сотню строк на миксе из MC++ и C#. Я ничего не имею против параллельного развития Явы, но думаю Windows-программистам (коих большинство) ближе будет Нэт. И им будет куда проще преодалеть его подводные камни чем перейти в лагерь сана.

Я вот большую часть времени писал именно под Windows. Однако что то мне не кажется что дотнет безоговорочно лучше всего и везде.

VD>Кстати, а какую скорость показывает твой тест если его запустить на НотСпоте?

Нет проблем. Тест конечно пришлось немножко переписать. Вот код

import java.util.*;

public class Coll {
 public static void main(String[] args) {
  ArrayList al = new ArrayList();
  long st = System.currentTimeMillis();
  for(int i = 0; i < 1000000; i++) {
   al.add(0,new Object());
   if(al.size() > 1000)
    al.remove(al.size()-1);
  }
  System.out.println(System.currentTimeMillis()-st);

  LinkedList q = new LinkedList();
  st = System.currentTimeMillis();
  for(int i = 0; i < 1000000; i++) {
   q.addFirst(new Object());
   if(q.size() > 1000)
    q.removeLast();
  }
  System.out.println(System.currentTimeMillis()-st);
 }
}


Вот результат

2312
141

Результат старого теста на машине на которой я сейчас пишу

1547
156

Что же — массивы в дотнете быстрее :). Но не на столько чтобы заменить связаные списки.
Списки медленнее. Это при том что джавовски LinkedList это и очеред и стек в одном флаконе. Я честно говоря думал что у java результаты будут хуже.
AVK Blog
Re[16]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 14:35
Оценка:
Здравствуйте VladD2, Вы писали:

AVK>>Контейнер тут не при чем. Достаточно было сделать LinkedList а уж от него унаследовать Queue и Stack. Причем судя по ildasm практически один и тот же связаный список реализован в Queue и Stack раздельно. Причины этого мне не понятны.


VD>Как манимум Stack нмного эфективнее создавать на базе обычного массива.

Я на твоем месте попробовал бы и кинул сюда исходнички и результаты. Скорее всего ты прав. Впрочем попробуем:

using System;
using System.Collections;

class ArrayStack {
 private ArrayList al = new ArrayList();
 public void Push(object obj) {
  al.Add(obj);
 }
 public object Pop() {
  object obj = al[al.Count-1];
  al.RemoveAt(al.Count-1);
  return obj;
 }
}

public class Test {
 private const int ITER_COUNT = 1000000;

 public static void Main() {
  ArrayStack ars = new ArrayStack();
  int st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
   ars.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);

  Stack s = new Stack();
  st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Push(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Push(new object());
   s.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);

  Queue q = new Queue();
  st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Enqueue(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Enqueue(new object());
   q.Dequeue();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Dequeue();
  }
  Console.WriteLine(Environment.TickCount-st);
 }
}


Смысл теста такой — сначала забиваем стек, затем работаем на его вершине и затем опустошаем. Очередь приведена в качестве стека на основе связаного списка. Понятно что забирает элементы она с другого конца, но для связаного списка конец с которого мы будем выдергивать элементы на скорость влияния не оказывает.

И результат
407
515
688

Что ж
1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее.
2) Похоже что дотнетовкий список реализован на основе массивов
3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.
AVK Blog
Re[13]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.03.02 14:52
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому.


Т.е. если чувствуем, что не правы, объявляем спор бессмысленным и уходим от ответа.

VD>>Ну, а чего тогда ты пытаешься здесь доказать?

AVK>Что многоплатформенность — не полностью бесполезная вещь. Больше ничего.

А те и говорят. Писюки давно в лидерах производительности... по цене они всех делали всегда... совместимость с большим количеством платформ — это дополнительный геморрой (даже на Яве)... Короче, для многих переносимость не показатель. Вот для меня с IT, например. Кому нужна переносимость пусть используют Яву или C++ с переносимыми библиотеками, а навязывать ее всем, да еще и объявлять это главным достоинством, не стоит.

VD>>Я вообще не понимаю как можно судить о качестве, возможностях, а главное востребованности системы не найдя в ней какой-нибудь финтифлюшки.

AVK>Я по моему не говорил что .Net неприменим из-за отсутствия связанного списка. Просто я тебе пример привел сыроватости библиотеки дотнета.

Не... Ты заявлял нечто вроде этого "что же это за платформа если в ней нет даже...".

VD>> Но я ни как не могу понять, ну, даже если нет нужной тебе реализации связанного списка, ну, так сядь и напиши.

AVK>Я напишу. Но ведь это время!

Не. Ну бывают действительно ресурсоемкие вещи. Если бы ты о тех же стэйтфул-EJB-ях заговорил, я бы понял... но связанный список!

VD>> Алгоритмы то там плевые.

AVK>Да все я прекрасно понимаю. Мне вот интересно — почему в библиотеке его нет? Недосмотр или специально так сделано?

Думаю недосмотр или не посчитали эту фичу важной. Зато там много чего другого есть ценного. И главное есть стройная компонентная модель.

VD>> Или берешь массив и делаешь к нему нужные методы (может выйти эффективнее) или работать на ссылках.

AVK>А вот ArrayList как раз и сделан на основе массивов. И произвольный доступ там очень быстрый. А вот добавление-удаление ... Пример я привел.

Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.

VD>>В конце концов если тебя .Net не устраивает,

AVK>Где я такое написал?

Ну, это как бы из критики вытекает. Чувствуется, что ты на этот продукт обижен, что ли...

VD>> то что ты его не бросишь и не продолжишь работать на Яве.

AVK>А кто сказал что я на java не работаю?

Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию... причем делаешь это заранее предвзято. Я тоже могу много плохого про Нэт сказать. Но общее впечатление положительное. Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно (вот еще бы вернули возможность создавать деструкторы для value-типов ...).

VD>> Она на сегодня неплохо развилась... грабли все ее ты уже знаешь... они тебя не смущают... так бросай других агитировать.

AVK>Где я кого ни будь агитировал? Пока здесь агитируешь исключительно ты сам. И почему то упорно всем пытаешся доказать что ,Net это идеал а все остальное ацтой.

Не, ну, нормально. Может этот спор я начал? Я Явы не отрицаю. Считаю, что это технология при некоторых обстоятельствах подходит для решения определенных задач. Нэт мне определенно нравится больше, но если кому охота использовать Яву я не против.

VD>> .Net это для тех кто программировал COM на C++ или VB, и для тех кому больше важна гибкость, а не переносимость.

AVK>Я что то делал и на С++ и на Дельфи, под COM/DCOM, на 1С, на php, на java, на VB вот только не довелось. Мне как — подходит?

Ну, это уже решай сам. Я бы вот на 1С точно ничего делать не стал. Ну, разве что импортер данных из этого замечательного продукта, но мне можно по тому как я сам себе хозяин и определяю чем буду заниматься. Если по делу, скажу так везде есть свои особенности... Ява предлагает множество отдельных технологий направленных на построение систем автоматизации бизнеса, но не одна технология меня лично (заметь о других я не говорю) не привлекают, они или утопичны или настолько слабо реализованы, что меня не устраивает. И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы. Мне ведь нужно соблюдать генеральную линию партии. Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно. Короче, каждому свое. Я (пока) выбрал Нэт. Все кто хочет могут выбирать что угодно. Например в нашем журнале "Кехнология Клиент-Сервер" мы уделяем внимание Яве не меньшее чем Нэту. Но писать про Яву я не буду. Пусть уж это делает наш постоянный автор Цимбал. (хотя он в глубине души тоже больше любит CORBA-у и C++ )

AVK>Меня убивает твоя позиция — для тебя все черное или белое. Либо рулез немеряный либо сакс полный. Любая технология имеет свои недостатки и свои достоинства, даже php. И надо уметь в каждом конкретном случае выбрать наиболее эффективную.


Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело. Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги.

А про черное и белое... ну вижу я что пытаются на выдернутых фактах создавать негативное впечатление о том что мне нравится. Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы.

Если бы у тебя был конкретный вопрос связанный с решение конкретной проблемы, то и спора бы не было. Мы просто попытались бы найти наилучшее решение. Но ты полез в обвинения, ну и получил отпор. В общем, мы мирные люди но наш бронепоезд...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 15:07
Оценка:
Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:


AVK>>Аксиома — разработка софта стоит дороже железок. Далее спорить бесполезно.


VD>Когда как. Софт все равно писать и можно его написать так, что он ни на каких супер-железках быстро работать не будет. Супер машины стоят миллионы долларов.

Согласен. Крайние случаи (простенькие программки и монстры-числомолотилки) не берем. Там все может быть наоборот.

VD>Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее.

Россия для IT технологий мягко говоря не показатель. А то что в России труд своих разработчиков может быть дешевле импортных железок, увы это так.

VD> К тому же ты сам себе противоричишь. Если всегда выгоднее купить более крутую железку, то выбрось свою Яву напиши свою програму абы как на нете и купи кластер за 10 килобаксов (тот что делает в два раза самый лучший Сан).

Никакая, самая крутая железка не поможет улучшить некоторые характеристики, например управляемость. Я говорил что софт дороже железок к тому что потеря быстродействия и увеличенный расход ресурсов в угоду упрощения разработки и эксплуатации до определенного предела вполне оправдан.

VD> Так что твои разсуждения о том, что LinkedList тормозит, по меньшей мере странны. :)

Он не тормозит. Его просто нет :)

VD>>>А ну как поделись. Какая реазация объодится без CORBA-ы?

AVK>>Resin, JBoss, Orion

VD>Я этих не видел. Но по статьям того же Цимбала основные сетевые решения для Явы серьезнвми конторами пишится на базе CORBA-ы. И по-моему это правильно.

А MS почему то на CORBA забил. И WS проталкивает. Хотя WS до CORBA в текущем состоянии еще далеко.

VD>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?

И что?

VD>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32.

А ты сравни сложность работы скажем с so модулями? :)

VD>Не я понимаю, что лично тебе это не нужно, но вот многим другим (мне например) не хочется отказываться от одобств даваемых Виндовс в пользу эфимерной (для меня) переносимости.

Вот, для тебя. Очень важная оговорка. Все, больше вопросов к тебе нет.

AVK>>То можно взять через WinAPI

VD>Какой ценой? Да и далеко не все можно взять. А без JNI и C вообще мало чего получится.
А JNI это уже не java?

VD>Мне до некоторых нет дела. А лексика обычная разговорная. Вот если статью сяду писать, то выберу слова по пристойнее и за ошипками начну следить. :)

Меня последнее время сильно достает безкультурье теперешней молодежи. Поэтому я так нервно и реагирую на слова вроде сосет, отдыхает, продвинутый, ацтой и т.д. Что, в русском языке слов не хватает? Так что извини если обидел.

VD>>>Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :)

AVK>>Серьезная то она серьезная, но деньги там не те.
VD>Тото я смотрю MS дла Сан занимаются этими "безденежными" технологиями, а крутой 1C окучивает самый богатый рынок! :)))
Давая Россию поминать не будем.

AVK>>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList.

VD>>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь)
AVK>>Круто! ...
VD>Нда на вопросы ты отвечать не хочешь...
На какой? Почему мне не хочется примитивные и практически везде используемые вещи писать ручками? Так я думаю это и так понятно.

VD>Я же говорю... менталитет у нас с тобой разный. Я привык писать на языке, а колекции воспринимаю как библитечную реализацию некоторого алгоритма.

Я вобще то говорю не о языке а о платформе.

VD>По этому ситуацию когда если чего нет, но можно дописать воспринимаю лучше, чем когда почти все есть, но то чего нет и желать не надо из-за нарушения стройности или проблем с переносимостью.

Ну почему обязательно вот так вот. Я например предпочитаю чтобы 99% моих неспецифических потребностей было уже реализовано, но при этом я могу дописать сам все что мне хочется. Я многого хочу?

AVK>>А нужен он частенько — когда нужен список в который часто добавляют и из которого часто удаляют, а произвольный доступ не нужен, нужен только через итератор. Разницу в производительности между ArrayList и LinkedList я тебе наглядно показал.


VD>Ну, ты не сказал зачем он тебе нужне и не показал как это же будет выглядеть на Яве (скорость имеется в виду).

Для чего нужен? Конкретный пример — писал кеш объектов. Размер кеша ограничивался определенным количеством элементов. Если их становилось больше — самые старые выпихивались. Т.е. обычная очередь. Но иногда объекты удалялись принудительно и их нужно было выкинуть из очереди вне очереди (сорри за каламбурчик :). Иногда их нужно было выпихнуть из середины в начало.
А вобще частенько приходилось использовать LinkedList, просто раньше как то не замечал его, а вот когда его не стало стразу обратил внимание. Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать.
VD> В наших проектах на C++ очень часто необходимо работать со списками, но вот связанные списки там вообще не испльзуются (в чистом виде). Все сделано на универсальных массивах. Практика показала, что грамотный массив работает быстрее чем связанный список элементы которого занимаются через хип.
Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов.

VD>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п.

Я где то говорил что все вышеперечисленное не нужно?

VD>А колекции если мне от них будет нужна максимальная скорость я все равно перепишу сам.

Точно, на ассемблере.

VD> Мои реализации все равно будут выстрее, чем то что засунуто в Нэт или Яву.

А я вот хочу переписывать базовые вещи очень редко. Опять многого хочу?

VD> Именно по этому я ечень хочу, чтобы в Нэт и Яву добавили Шаблоны как в C++.

В java в 1.5 точно уже добавят.В дотнет тоже вроде слухи ходили.

VD> Пока же я могу писать шаблоны на MC++, делать на их основе классы для конкретных типов .Нэт и испльзовать их в Шарпе и Васике, а на Яве я как всегда приплыл. И пока что ничего не поделаешь. :( Мои ActiveX-ы никак не засунуть в Яву, а в Нэт они входят как будто для него были написаны. Переносимость же у С (обычного не ++) выше. Так что же на нем писать?

Если понадобится — будешь и на нем писать. Я видел одну программку — так там на голом С был написан механизм реализующий ООП. А сделано это было для того чтобы работало на одной платформе на которой C++ отсутствовал. Вот такие вот пирожки с котятами.
Это так, не для спора, просто забавный пример извращений.
AVK Blog
Re[10]: all it
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 15:08
Оценка:
Здравствуйте VladD2, Вы писали:

AVK>>Ну так предложи тему поинтереснее.

VD>Ну, например попробуй сравнить стэйтлес технику предлагаемую MS и стытфул-EJB и им подобную. Это будет по интереснее.
В каком плане сравнить?
AVK Blog
Re[8]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 15:17
Оценка:
Здравствуйте VladD2, Вы писали:

VD>То что ты называешь "стилем" является не стилем, а просто навязываемой тактикой. C++ тем и хорош, что на нем можно испльзовать любой стиль программирования и реализовывать, то что нужно программисту теми методами которые ему нравятся.

Тем же он и плох. Свобода средств увы приводит к увеличению количества ошибок даже при наличии некривых рух. А уж при их отсутствии.

VD>>> Думаю, .Net замечательное средство для подстегивания Сана... может тепрь они начнут устранять дурь мешающую многим программистам.

Кстати, посмотрел недавно новые JSR и планы sun на 1.5
1) В java добавят аттрибуты
2) В java добавят какое то подобие foreach
3) В java добавят boxing/unboxing. Вот уж где действительно косяк полный, отсутствие out параметров перед этим просто меркнет.
ну плюс еще generics(темплейты), улучшенная поддержка констант и кучу еще другого.
Так что таки подстегнули

VD>"Крайне правильный" — это даже забавно. Я вот только не понимаю почему из-за этой крайней правильности нужно эмулировать [out]- и [in, out]-параметры через массивы. Оставили бы хотья бы передачу по ссылке...

out параметры являются потенциальными источниками трудноуловимых ошибок. Это не мое ИМХО, это так разработчики говорят. Их можно эмулировать, но еще лучше так спроектировать систему чтобы надобность в них отпала.
AVK Blog
Re[14]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 16:17
Оценка:
Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:


AVK>>Мне этот бессмысленный спор надоел, поэтому ничего на тему серверов я тебе отвечать не буду. Да и неинтересно это уже здесь никому.

VD>Т.е. если чувствуем, что не правы, объявляем спор бессмысленным и уходим от ответа.
Нет, именно надоело.

VD>А те и говорят. Писюки давно в лидерах производительности... по цене они всех делали всегда... совместимость с большим количеством платформ — это дополнительный геморрой (даже на Яве)... Короче, для многих переносимость не показатель. Вот для меня с IT, например. Кому нужна переносимость пусть используют Яву или C++ с переносимыми библиотеками, а навязывать ее всем, да еще и объявлять это главным достоинством, не стоит.

Я где то это делал? Или ты о Sun? Так я с ними в этом плане тоже не согласен.

VD>Не... Ты заявлял нечто вроде этого "что же это за платформа если в ней нет даже...".

Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.

VD>Не. Ну бывают действительно ресурсоемкие вещи. Если бы ты о тех же стэйтфул-EJB-ях заговорил, я бы понял... но связанный список!

Это пример. Причем не единственный. Еще раз кину списочек
1) LinkedList
2) RandomAccessFile
3) MemoryMappedFile
Из API
1) JDO
2) EJB
3) JAAS.
Список самый негемморойный.
А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть.

VD>Думаю недосмотр или не посчитали эту фичу важной. Зато там много чего другого есть ценного. И главное есть стройная компонентная модель.

Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.
Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?

VD>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.

Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь.

VD>Ну, это как бы из критики вытекает.

Не надо пожалуйста за меня говорить. Ничего такого из моей критики не вытекает

VD> Чувствуется, что ты на этот продукт обижен, что ли...

Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится. На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?

VD>Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию...

То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net

VD> причем делаешь это заранее предвзято.

Нет, это твои личные впечатления.

VD> Я тоже могу много плохого про Нэт сказать.

Но будешь молчать? Это ли не предвзятое отношение? Я ведь и плохие моменты java тоже отмечаю.

VD> Но общее впечатление положительное.

У меня тоже.

VD> Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно

Да много чего еще дорабатывать надо. А на производительность компилятора мне честно говоря на*№ать. В С# incremental compiling есть, а в условиях отсутствия хидеров работает он просто идеально.

VD> (вот еще бы вернули возможность создавать деструкторы для value-типов ...).

А нафига? Эти типы — нечто вроде объектных заменителей ... ну скажем record в паскале. Т.е. сложных типов данных. А деструкторы им как бы не к чему.
Ну а отсутствие деструкторов у классов — да мешает. Но это цена которую приходится платить за GC и отложеное удаление.

VD>Не, ну, нормально. Может этот спор я начал?

Может я?

VD>Ну, это уже решай сам.

А я и решил.

VD> Я бы вот на 1С точно ничего делать не стал.

И опять у тебя все черно-белое. Сколько времени тебе понадобится чтобы написать на дотнете простенький складской учет? И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего. Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.

VD> утопичны или настолько слабо реализованы, что меня не устраивает.

Таки на java очень много успешных проектов, больше чем на дотнет. Так что не так уж и утопично. Вобще — о вкусе устриц можно спорить только с тем кто их ел.
VD> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы.
Ну так рассказывай про свои потребности.
VD> Мне ведь нужно соблюдать генеральную линию партии.
А кому нужно?
VD> Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно.
А что тебе нужно?
VD> Короче, каждому свое. Я (пока) выбрал Нэт.
Для чего?

VD>Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело.

Есть специальные люди для которых подобные задачи — один из основных вопросов профессиональной деятельности. И ценятся такие люди намного больше обычных программистов.
VD> Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги.
Зачем на смену? Уж коли ты начал делать проект на какой то платформе — потом менять поздно. А вот начиная новый проект можно и нужно рассмотреть вопрос выбора платформы, с учетом не только чисто технологических факторов. Я конечно понимаю — для программиста куда проще выбрать одну платформу и всю жизнь на ней писать. Но увы — так не получится. Выбрал бы ты к примеру в свое время весьма передовой FoxPro. Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь.

VD>А про черное и белое... ну вижу я что пытаются на выдернутых фактах создавать негативное впечатление о том что мне нравится.

Я не пытаю создавать никакого впечатления. Я пытаюсь донести свою мысль.

VD> Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы.

И никого не гашу.

VD>Если бы у тебя был конкретный вопрос связанный с решение конкретной проблемы, то и спора бы не было.

Увы, на данном этапе развития дотнета в России почти любой вопрос проще расковырять самому. Специалистов практически нет.

VD> Мы просто попытались бы найти наилучшее решение. Но ты полез в обвинения, ну и получил отпор. В общем, мы мирные люди но наш бронепоезд...


Странно ты как то воспринимаешь. Вот собственно фраза(не твоя) которая мне не понравилась
IT>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java.
А теперь твои фразы
VD>Если .Net станет перенасима хотя бы в серверном варианте, т.е. без клиентского интерфейса (WinForms), то у Явы пропадет последний фиговый листок, но тем кто выбрал .Net это будет по фигу.

VD>Небыло бы Борланда для Явы вообще не создали бы приличной среды разработки.


VD>по сравнению с документацией от той же Явы MSDN — это рай.(MSDN имелся ввиду)


А вот где я кого то обвинял? До сих пор пытаюсь доказать что не все так однозначно. И ничего более. Все остальное — домыслы.
AVK Blog
Re[17]: jsdk.jar
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.03.02 16:58
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>И результат

AVK>407
AVK>515
AVK>688

AVK>Что ж

AVK>1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее.
AVK>2) Похоже что дотнетовкий список реализован на основе массивов
AVK>3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.

А у меня другие данные при запуске того же теста:
1883
1732
2224
Re[18]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 17:34
Оценка:
Здравствуйте DarkGray, Вы писали:

DG>А у меня другие данные при запуске того же теста:

DG>1883
DG>1732
DG>2224
Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.
AVK Blog
Re[13]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.03.02 17:41
Оценка:
Здравствуйте AndrewVK, Вы писали:

VD>>Если очень хочется, можешь написать универсальную реализацию с интерфейсом IList.

AVK>Вот это я и хотел доказать — придется писать ручками с нуля. Больше вопросов нет.

Что доказать? То что ленив? Да мы тум все такие. Фунционильность нужная тебе, я так понял, в Нете есть. Тебя не устраивает производительность, хотя ты же говоришь, что намного дешевле купить более производительный компьютер. Ты говоришь, что в Яве все лучше, но времени выполнения того же теста, на том же железе не приводишь. Написать это дело можно было за два часа. На споры со мной ты убил куда больше. Так что выходит, что ты доказываешь свою лень. :)

AVK>Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше.


Ну, что же значит он лучше спроектирован. По количеству единиц данных сообщение форума близко к накладной. Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную. :)

Я уже давно понял, что нельзя подходить к разным областям деятельности предвзято. Можно создать простую накладную и сложный форум, а можно наоборот. Для того чтобы сравнивать нежно как минимум изучить реализацию того и другого. В конечном счете это просто бессмысленно.

VD>>Если фирма растет, такие изменения происходят постоянно и система постоянно перепроектируется. В некоторых этапах, когда руководство тех. отдела понимает, что количество примочек слишком велико, принимается решение и перепроектируется система. В ином случае фирма или перестает расти, или плюет на систему автоматизации, или дохнет.

AVK>Извини, но ты не прав.

Да ладно извиняться... мирный спор все таки. :)

AVK>Я уже тебе говорил — даже если руководство согласно отдавать IT почти всю прибыль — частая замена информационных систем приведет к полному краху. Ибо людей не переделать.


Так я с тобой почти согласен. В том плане, что полная переделка системы — это тяжелая и ответственная работа. Вот только ты не услышал моих аргументов о том, что в растущей фирме такие переделки идут постоянно (эволюционные изменения, тык сызыть), и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко.

AVK>Если у тебя нет опыта внедрения подобных систем — не стоит на эту тему спорить. Я тебе говорил — там все по другому.


Боюсь если мы начнем "мериться членами", то ты можешь проиграть. :) Так что довай по сути и не будем оценивать опыт друг-друга. Я верю, что у тебя кое-какой опыт есть. Так что поверь, что и я, и IT тоже делали в своей жизни кое что. И если у нас не возникло надобности в Крэе, Сане или Яве — это не значит, что решаемые задачи у нас были слабенькие. В конце концов, тот же IT (как я понимаю) окучивает какую-то Маямскую контору...

AVK>>>И дело даже не во вложеных деньгах. Дело в том что смена информационной системы для крупного предприятия это очень тяжелое испытание. И это чревато потерей денег куда больших нежели стоимость самой разработки.

VD>>Когда выбор стоит между тяжелым решением и прозябанием, зачастую выбирается трудная жизнь, а не легкая смерть. :)
AVK>Ну когда такой выбор стоит — тогда конечно

VD>>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете?

AVK>Нет. Но когда тебе говорят что черное это белое...

Ты пойми. М моей стороны все выглядит так же, но говоришь уже ты. :) Так что давай уж если спорим, то аргументировать свое мнение. Тогда от спора обязательно будет толк. А так действительно получится флэйм. Вот твое следующее письмо мне понравилось. Там ты аргументируешь свое мнение практическим кодом. И заметь она становится ближе к моему. :)

VD>>Да ну? А вот я, IT и MS думаем по другому. MS конечно не помешает замена VB, но он MS был бы не MS если бы в их планы не входил захват всех рынков на которых можно зарабатывать деньги. Не удивлюсь если через пру лет MS начнет обсуждать вопросы разработки драйверов на C#.

AVK>Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.

GC – это часть CLR. CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты, т.е. – это COM 2. COM+ – основанный на COM сервер приложений реализованный в виде сервиса ОС. SOAP – протокол удаленных вызовов через http и XML. Все это действительно не имеет отношения к драйверам. Ну, разве что нет теоретического запрета использования CLR-а в драйверах. Но .Net не == CLR. Статья IT и мои личные опыты показывают, что на MC++ (да и напрямую на MSIL, являющегося ни чем иным, как переносимым ассемблером) можно создавать бинарный байт-код (но не код для код для конкретного процессора) который может делать все, что угодно. Его JIT-вариант ни чем не отличается от машинного кода скомпилированного лучшими оптимизирующими компиляторами. Более того я могу делать вставки реального машинного кода. Это позволяет спокойно писать и драйверы на платформе .Net, при условии что JIT-компилятор будет запускаться в рамках необходимого кольца защиты. В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее. Тоже самое верно и для Явы. MC++ позволяет создавать шаблоны, а на их основе конечные классы для конкретных типов данных. Классы же нет используют красивый, но априори более медленный универсальный стиль основанный на интерфейсах и типе object.

AVK>А за других я бы на твоем месте не стал говорить.


Ты можешь привести конкретное место где я это делал?

VD>>Чтобы понять разницу между Явой И Нэтом нужно написать сотню строк на миксе из MC++ и C#. Я ничего не имею против параллельного развития Явы, но думаю Windows-программистам (коих большинство) ближе будет Нэт. И им будет куда проще преодолеть его подводные камни чем перейти в лагерь сана.

AVK>Я вот большую часть времени писал именно под Windows. Однако что то мне не кажется что дотнет безоговорочно лучше всего и везде.

Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.

VD>>Кстати, а какую скорость показывает твой тест если его запустить на НотСпоте?

AVK>Нет проблем. Тест конечно пришлось немножко переписать. Вот код

AVK>Вот результат


AVK>2312

AVK>141

AVK>Результат старого теста на машине на которой я сейчас пишу


AVK>1547

AVK>156

AVK>Что же — массивы в дотнете быстрее :). Но не на столько чтобы заменить связаные списки.

AVK>Списки медленнее. Это при том что джавовски LinkedList это и очеред и стек в одном флаконе. Я честно говоря думал что у java результаты будут хуже.

Да, правильный алгоритм может дать лучшую скорость и на худшем компиляторе и на худшем железе. У .Net-а конечно можно еще запустить ngen (надеюсь ты релиз тестировал) и выиграть еще процентов 10-20. Но общую картину это не изменит.

Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип). Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: jsdk.jar
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.03.02 17:43
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте DarkGray, Вы писали:


DG>>А у меня другие данные при запуске того же теста:

DG>>1883
DG>>1732
DG>>2224
AVK>Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.

Стек действительно несколько быстрее. Просто не нужно этот тест делать вторым. К тому же можно задать капасити, чтобы не фрагментировать память.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: jsdk.jar
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.03.02 17:44
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте DarkGray, Вы писали:


DG>>А у меня другие данные при запуске того же теста:

DG>>1883
DG>>1732
DG>>2224
AVK>Давай тогда сюда свою програмную и аппаратную конфигурацию. Судя по всему дело в медленной памяти. Потому как практически одинаковая скорость связаных списков и массивов.

Извиняюсь это было в Debug-версии, в Release тоже самое, что и у тебя

640
822
1031
Re[20]: jsdk.jar
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.03.02 17:47
Оценка:
Здравствуйте DarkGray, Вы писали:

DG>640

DG>822
DG>1031

Если поменять местами Stack и ArrayList, то:

621
901
1052
Re[17]: jsdk.jar
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.03.02 17:55
Оценка:
Здравствуйте AndrewVK, Вы писали:

VD>>Как манимум Stack нмного эфективнее создавать на базе обычного массива.

AVK>Я на твоем месте попробовал бы и кинул сюда исходнички и результаты. Скорее всего ты прав. Впрочем попробуем:




AVK>...Смысл теста такой — сначала забиваем стек, затем работаем на его вершине и затем опустошаем. Очередь приведена в качестве стека на основе связаного списка. Понятно что забирает элементы она с другого конца, но для связаного списка конец с которого мы будем выдергивать элементы на скорость влияния не оказывает.


AVK>И результат

AVK>407
AVK>515
AVK>688

Результаты теста зависят от очередности (из-за фрагментированности памяти). К тому же я бы задал капасити заранее. Это уменьшило бы фрагментацию.

AVK>1) Массивы действительно быстрее связаного списка. Впрочем это и понятно. В случае выдергивания элементов с конца нет необходимости передвижки всех элементов, а доступ к массиву быстрее.


Дык. А ты думал тебя тут обмануть хотели?

AVK>2) Похоже что дотнетовкий список реализован на основе массивов

AVK>3) А вот почему самопальный стек на основе ArrayList оказался быстрее — для меня загадка.

Да не быстрее он. Просто память уже фрагментировалась к этому времени. Переставь местами эти тесты и увидишь, что стэк даже быстрее.

А вот мой вариант твоего теста:

using System;
using System.Collections;

namespace Lists
{
  class ArrayStack 
  {    
    public ArrayStack(int Capacity){ al = new ArrayList(Capacity); }
    private ArrayList al;
    public void Push(object obj)
    {
      al.Add(obj);
    }
    public object Pop()
    {
      object obj = al[al.Count-1];
      al.RemoveAt(al.Count-1);
      return obj;
    }
  }

  class IntArrayStack 
  {  
    public IntArrayStack(int Capacity){ this.Capacity = Capacity; }
    int m_iCapacity;
    public int Capacity
    {
      get{ return m_iCapacity; }
      set
      {
        if(value < 0)
          throw new Exception("Capacity не может быть меньше нул!");
        m_Array = new int[value];
        m_iCapacity = value;
      }
    }
    public void Grow(){ Capacity = Capacity * 2; }

    int m_iCount = 0;
    public int Count{ get{ return m_iCount; } }

    private int[] m_Array;
    public void Push(int obj)
    {
      if(m_iCount >= m_iCapacity)
        Grow();
      m_Array[m_iCount] = obj;
      m_iCount++;
    }
    public int Pop()
    {
      m_iCount--;
      return m_Array[m_iCount];
    }
  }

  public class Test
  {
    private const int Capacity = 1100000;
    private const int ITER_COUNT = 1000000;

    static void StackTest()
    {
      Stack s = new Stack(Capacity);
      int st = Environment.TickCount;
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        s.Push(new object());
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        s.Push(new object());
        s.Pop();
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        s.Pop();
      }
      Console.WriteLine("Stack: " + (Environment.TickCount - st));
    }
    static void ArrayStackTest()
    {
      ArrayStack ars = new ArrayStack(Capacity);
      int st = Environment.TickCount;
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        ars.Push(new object());
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        ars.Push(new object());
        ars.Pop();
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        ars.Pop();
      }
      Console.WriteLine("ArrayStack: " + (Environment.TickCount - st));
    }
    static void IntArrayStackTest()
    {
      IntArrayStack  iars = new IntArrayStack(Capacity);
      int st = Environment.TickCount;
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        iars.Push(i);
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        iars.Push(i);
        iars.Pop();
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        iars.Pop();
      }
      Console.WriteLine("IntArrayStack: " + (Environment.TickCount - st));
    }
    static void QueueTest()
    {
      Queue q = new Queue(Capacity);
      int st = Environment.TickCount;
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        q.Enqueue(new object());
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        q.Enqueue(new object());
        q.Dequeue();
      }
      for(int i = 0; i < ITER_COUNT; i++) 
      {
        q.Dequeue();
      }
      Console.WriteLine("Queue: " + (Environment.TickCount - st));
    }

    public static void Main() 
    {
      QueueTest();
      StackTest();
      ArrayStackTest();
      IntArrayStackTest();

      Console.WriteLine("\nStep 2...");
      QueueTest();
      StackTest();
      ArrayStackTest();
      IntArrayStackTest();

      Console.WriteLine("\nStep 3...");
      IntArrayStackTest();
      ArrayStackTest();
      QueueTest();
      StackTest();

      Console.WriteLine("\nPress Enter to exit...");
      Console.ReadLine();
    }
  }

}



Результаты на моей машине:
Queue: 1172
Stack: 601
ArrayStack: 630
IntArrayStack: 61

Step 2...
Queue: 881
Stack: 581
ArrayStack: 611
IntArrayStack: 60

Step 3...
IntArrayStack: 50
ArrayStack: 561
Queue: 891
Stack: 561


Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: jsdk.jar
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.03.02 18:03
Оценка:
Здравствуйте VladD2, Вы писали:


VD>Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.


Не корректно сравнивать IntArrayStack с остальными, т.к. для IntArrayStack не вызывается функция new object() для каждой итерации
Re[14]: Зачатки флейма ".Net vs. Java2" -- не выйдет!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 18:36
Оценка:
Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:


VD>Что доказать? То что ленив?

Нет, то что дотнет сыроват.

VD>Да мы тум все такие. Фунционильность нужная тебе, я так понял, в Нете есть. Тебя не устраивает производительность,

Знаешь, если бы производительность отличалась в 2 раза я бы пережил. Но когда на порядок! Ты вот пузырьковой сортировкой пользуешся? Это из той же оперы.
VD>Ты говоришь, что в Яве все лучше,
Нет, я такого никогда не говорил.

VD> но времени выполнения того же теста, на том же железе не приводишь.

Как же так — я же привел. Плохо смотрел?

VD>Написать это дело можно было за два часа. На споры со мной ты убил куда больше. Так что выходит, что ты доказываешь свою лень.

Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь?

AVK>>Весь местный форум проще и меньше чем процедура проведения скажем расходной накладной у меня, а ведь бывает много больше.

VD>Ну, что же значит он лучше спроектирован.
А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?

VD> По количеству единиц данных сообщение форума близко к накладной.

Нет.
VD> Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную.
Нет.

VD>Я уже давно понял, что нельзя подходить к разным областям деятельности предвзято. Можно создать простую накладную и сложный форум, а можно наоборот. Для того чтобы сравнивать нежно как минимум изучить реализацию того и другого. В конечном счете это просто бессмысленно.

Да нельзя подобные задачи сравнивать. Я тебе потому и привел размер кода одной только проводки чтобы показать что форум и КИС абсолютно несравниваемы.

VD>Так я с тобой почти согласен. В том плане, что полная переделка системы — это тяжелая и ответственная работа. Вот только ты не услышал моих аргументов о том, что в растущей фирме такие переделки идут постоянно (эволюционные изменения, тык сызыть),

Переделки — да. Но не перепроектирование основ.

VD> и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко.

Зато можно еще на год-другой отложить безвременную кончину и этим съэкономить денежек. Впрочем опять мы в какой то оффтопик скатываемся. Давай завязывать на эту тему.

VD>Боюсь если мы начнем "мериться членами", то ты можешь проиграть. Так что довай по сути и не будем оценивать опыт друг-друга. Я верю, что у тебя кое-какой опыт есть. Так что поверь, что и я, и IT тоже делали в своей жизни кое что. И если у нас не возникло надобности в Крэе, Сане или Яве — это не значит, что решаемые задачи у нас были слабенькие. В конце концов, тот же IT (как я понимаю) окучивает какую-то Маямскую контору...

Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах. И переносить его на КИС не стоит. Но если ты занимался именно КИС — расскажи поподробнее, если конечно не тайна. Всегда полезно обменяться опытом.

VD>>>Блин ну какое самомнение. Ты серьезно считаешь, что один видел все на свете?

AVK>>Нет. Но когда тебе говорят что черное это белое...
VD>Ты пойми. М моей стороны все выглядит так же, но говоришь уже ты. Так что давай уж если спорим, то аргументировать свое мнение. Тогда от спора обязательно будет толк. А так действительно получится флэйм.
Знаешь, я на тему серверов не хочу спорить. Давай все же ближе к дотнету. Я специально на остальное не отвечаю, ибо не интересно это никому здесь.
VD> Вот твое следующее письмо мне понравилось. Там ты аргументируешь свое мнение практическим кодом. И заметь она становится ближе к моему.
Так я люблю, если это разъясняет, попробовать. Ибо снимает все вопросы и практически не требует словословия. Факты, так скать в голом виде.

AVK>>Как ты думаешь почему столь уважаемый тобой MS использует CLR, GC, COM+, SOAP? Не иначе для того чтобы драйвера писать.


VD>GC – это часть CLR.

GC — это технология прежде всего.
VD> CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты,
Наврал я немножко. Не CLR я имел ввиду а MSIL и VM для его выполнения

VD>SOAP – протокол удаленных вызовов через http и XML.

html здесь лишний.

VD> Все это действительно не имеет отношения к драйверам. Ну, разве что нет теоретического запрета использования CLR-а в драйверах. Но .Net не == CLR. Статья IT и мои личные опыты показывают, что на MC++ (да и напрямую на MSIL, являющегося ни чем иным, как переносимым ассемблером) можно создавать бинарный байт-код (но не код для код для конкретного процессора) который может делать все, что угодно. Его JIT-вариант ни чем не отличается от машинного кода скомпилированного лучшими оптимизирующими компиляторами. Более того я могу делать вставки реального машинного кода. Это позволяет спокойно писать и драйверы на платформе .Net, при условии что JIT-компилятор будет запускаться в рамках необходимого кольца защиты.

Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.

VD> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее.

Это я заметил с самого начала. И памяти кстати заметно меньше кушает.

AVK>>А за других я бы на твоем месте не стал говорить.

VD>Ты можешь привести конкретное место где я это делал?
Поскипал ты зря. "А вто я, IT и MS думаем по другому." — твои слова?

VD>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.

Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки.


VD>Да, правильный алгоритм может дать лучшую скорость и на худшем компиляторе и на худшем железе. У .Net-а конечно можно еще запустить ngen (надеюсь ты релиз тестировал)

релиз, да еще и с SP1
VD> и выиграть еще процентов 10-20. Но общую картину это не изменит.
Пожалуйста, запустить ngen не сложно

1906
172
(напомню старые
1547
156)
Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно Хотя я догадываюсь почему такой эффект.

VD>Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип).

Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать.
1890
172
То есть эффект = 0. Догадываешся почему?


VD> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.

Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности. Ибо железки ныне дешевеют а труд программеров дорожает. Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность. Но в отличие от некоторых об этих временах совсем не жалею. Я не тебя имею ввиду, просто достал треп что мол программисты программы писать разучились. Сами что такое ассемблер представляют по книжкам и примерчикам — зато с апломбом доказывают что мол если бы не MS все программы были бы написаны на ассемблере, в крайнем случае на голом С, занимали бы 20-30Кб и работали бы со свистом на трешках.
AVK Blog
Re[20]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 18:38
Оценка:
Здравствуйте VladD2, Вы писали:

VD>Стек действительно несколько быстрее.

Который?
VD> Просто не нужно этот тест делать вторым.
Ага, знаешь. Есть такой косяк.
VD> К тому же можно задать капасити, чтобы не фрагментировать память.
Кому? Я честно говоря не понял. Stack или ArrayStack?
AVK Blog
Re[21]: jsdk.jar
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.03.02 18:46
Оценка:
Здравствуйте DarkGray, Вы писали:

DG>Если поменять местами Stack и ArrayList, то:


DG>621

DG>901
DG>1052

Виноват, забыл я про это. Исправляюсь

using System;
using System.Collections;

class ArrayStack {
 private ArrayList al = new ArrayList();
 public void Push(object obj) {
  al.Add(obj);
 }
 public object Pop() {
  object obj = al[al.Count-1];
  al.RemoveAt(al.Count-1);
  return obj;
 }
}

public class Test {
 private const int ITER_COUNT = 1000000;

 public static void Main() {
  ArrayStack ars = new ArrayStack();
  int st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
   ars.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);
//Изменено здесь
  GC.Collect();

  Stack s = new Stack();
  st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Push(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Push(new object());
   s.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   s.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);
//И здесь
  GC.Collect();

  Queue q = new Queue();
  st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Enqueue(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Enqueue(new object());
   q.Dequeue();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   q.Dequeue();
  }
  Console.WriteLine(Environment.TickCount-st);
 }
}



516
484
781

Вот теперь все стало на свои места и вполне предсказуемо. Небольшая разница у StackArray обусловлена наличием промежуточного слоя.
AVK Blog
Re[13]: jsdk.jar
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.03.02 18:55
Оценка:
Здравствуйте AndrewVK, Вы писали:

AVK>Согласен...


Ну, видишь... у нас тоже есть совподающие точки зрения. :)

VD>>Думаю, буджеты многих российских контро имеющих своих разработчиков (и разработки) куда скромнее.

AVK>Россия для IT технологий мягко говоря не показатель. А то что в России труд своих разработчиков может быть дешевле импортных железок, увы это так.

Дык. Я... это в России живу. :shuffle: И все ее ограничения и/или радости на меня влияют. Вот IT (в смысле мужик) он тепарь буджуй, но все равно на писюках живет.

VD>> К тому же ты сам себе противоричишь. Если всегда выгоднее купить более крутую железку, то выбрось свою Яву напиши свою програму абы как на нете и купи кластер за 10 килобаксов (тот что делает в два раза самый лучший Сан).

AVK>Никакая, самая крутая железка не поможет улучшить некоторые характеристики, например управляемость. Я говорил что софт дороже железок к тому что потеря быстродействия и увеличенный расход ресурсов в угоду упрощения разработки и эксплуатации до определенного предела вполне оправдан.

О вот ты и сам сказал ключевое слово "до определенного предела". Т.е. иногда проще софт поправить, а иногда жележку новую прикупить. И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение...

VD>> Так что твои разсуждения о том, что LinkedList тормозит, по меньшей мере странны. :)

AVK>Он не тормозит. Его просто нет :)

Ну, есть же заменитель. В .Net есть почти все, что тебе нужно. Кое чего нет. Ну, так не трудно дописать. Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности.

VD>>Я этих не видел. Но по статьям того же Цимбала основные сетевые решения для Явы серьезнвми конторами пишится на базе CORBA-ы. И по-моему это правильно.

AVK>А MS почему то на CORBA забил. И WS проталкивает. Хотя WS до CORBA в текущем состоянии еще далеко.

Ну, с корбой нужно скорее сравнивать COM и CLR. Но оба этих дела перекрывают по областям применения CORBA. Так как являются и локальными и распределенными компонентными моделями, а не только технологией для сетевого взаимодействия.

VD>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?

AVK>И что?

И то, что для Явы все это будет геморой, а ясного пути интеграции с сервисами ОС вообще нет. Все нужно писать на С через JNI. Для .Net это делается на ура даже напрямую из C# или VB.Net, а на MC++ сожно тварить все что захочешь запаковывая результат в CLR-совместимые обертки.

VD>>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32.

AVK>А ты сравни сложность работы скажем с so модулями? :)

Не понял.

VD>>Не я понимаю, что лично тебе это не нужно, но вот многим другим (мне например) не хочется отказываться от одобств даваемых Виндовс в пользу эфимерной (для меня) переносимости.

AVK>Вот, для тебя. Очень важная оговорка. Все, больше вопросов к тебе нет.

Какой раз у тебя "больше вопросов к тебе нет"? :)

Я говрю за себя, когда речь идет о пристрастиях. Межплатформная переносимость — это пристрастие. Ты веришь, что это спасительная волшебная палачка, я в то что это геморой, даже на Яве или Нэте. Вот и вся разница.

AVK>>>То можно взять через WinAPI

VD>>Какой ценой? Да и далеко не все можно взять. А без JNI и C вообще мало чего получится.
AVK>А JNI это уже не java?

Да не Ява. Это интерфейс между явой и С. В нет интеграция с реальной ОС сделана в разы лучше. Если бы у тебя было много С++-ного (например) кода, ты бы меня поныл.

AVK>Меня последнее время сильно достает безкультурье теперешней молодежи. Поэтому я так нервно и реагирую на слова вроде сосет, отдыхает, продвинутый, ацтой и т.д. Что, в русском языке слов не хватает? Так что извини если обидел.


Иногда, разнообразие не помешает. :) Главное, чтобы из этих слов весь лексикон не состоял. :) Меня, например, "ИМХО" вместо "по-моему" бесит... экономия трех букв... понимашъ. :) Ну, не бить же каждого по кумполу (:) ) за это?

VD>>>>Значит Web-решения вещь не серьезная. :) Вон IT вообще все хочет не Web-сервисах переписать. :)

AVK>>>Серьезная то она серьезная, но деньги там не те.
VD>>Тото я смотрю MS дла Сан занимаются этими "безденежными" технологиями, а крутой 1C окучивает самый богатый рынок! :)))
AVK>Давая Россию поминать не будем.

Давая. :) Но, ПюплСофт тоже до MS не дотягивает, а те кто делает заказные проекты на Яве и подавно.

AVK>>>>>А LinkedList это по сути Queue или Stack но с интерфейсом IList.

VD>>>>А ты что (конкретно) сделать хочешь? Зчем он тебе нужен? И что мешает просто написать это дело самому (так ты хочешь)
AVK>>>Круто! ...
VD>>Нда на вопросы ты отвечать не хочешь...
AVK>На какой? Почему мне не хочется примитивные и практически везде используемые вещи писать ручками? Так я думаю это и так понятно.

Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках. Это GC в .Net и Яве еще картину сглаживает. С обычными хипами связанные списки — это натуральное вредительство. :)

VD>>Я же говорю... менталитет у нас с тобой разный. Я привык писать на языке, а колекции воспринимаю как библитечную реализацию некоторого алгоритма.

AVK>Я вобще то говорю не о языке а о платформе.

Во. И библиотеки я тоже от платформы отделяю. Завтра появятся независимая реализация коллекций и я начну использовать ее. А не появится, свою создам. Мне главное, чтобы технологических препонов не было.

AVK>Ну почему обязательно вот так вот. Я например предпочитаю чтобы 99% моих неспецифических потребностей было уже реализовано, но при этом я могу дописать сам все что мне хочется. Я многого хочу?


Ну, и что связанный список нельзя отнести к 1 проценту? К тому же функциональность его можно воспроизводить другими методами, что ты и продемонстрировал...

AVK>Для чего нужен? Конкретный пример — писал кеш объектов. Размер кеша ограничивался определенным количеством элементов. Если их становилось больше — самые старые выпихивались. Т.е. обычная очередь. Но иногда объекты удалялись принудительно и их нужно было выкинуть из очереди вне очереди (сорри за каламбурчик :). Иногда их нужно было выпихнуть из середины в начало.


Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто). Тут реализация на массиве будет эффективнее. Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее.

AVK>Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать.


Так может DOM использовать. И опять же встает вопрос о частоте произвольного и обычного выкидывания.

VD>> В наших проектах на C++ очень часто необходимо работать со списками, но вот связанные списки там вообще не испльзуются (в чистом виде). Все сделано на универсальных массивах. Практика показала, что грамотный массив работает быстрее чем связанный список элементы которого занимаются через хип.

AVK>Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов.

Не факт. Это может быть плохая реализация. Да и пример бессмысленный. В осмысленном все может быть совсем по другому.

Надо бы сделать рукопашный линкед-лист и посмотреть на его скорость.

VD>>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п.

AVK>Я где то говорил что все вышеперечисленное не нужно?

А это уже я говорил, что перечисленное мною (по-моему) в .Net лучше. :)

VD>>А колекции если мне от них будет нужна максимальная скорость я все равно перепишу сам.

AVK>Точно, на ассемблере.

На объектов вряд ли. Но если будет надо, то и так. 10 строк критического кода можно переписать и для нескольких платформ и даже для разных процессоров.

VD>> Мои реализации все равно будут выстрее, чем то что засунуто в Нэт или Яву.

AVK>А я вот хочу переписывать базовые вещи очень редко. Опять многого хочу?

Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная? Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :)

VD>> Именно по этому я ечень хочу, чтобы в Нэт и Яву добавили Шаблоны как в C++.

AVK>В java в 1.5 точно уже добавят.В дотнет тоже вроде слухи ходили.

Я в курсе. Для Нэта даже был не официальный релиз быты :) от MS-ресерчь. Вот только обещанного тир года ждут. :( А многие еще не понимают всего кайфа этого дела. :(

VD>> Пока же я могу писать шаблоны на MC++, делать на их основе классы для конкретных типов .Нэт и испльзовать их в Шарпе и Васике, а на Яве я как всегда приплыл. И пока что ничего не поделаешь. :( Мои ActiveX-ы никак не засунуть в Яву, а в Нэт они входят как будто для него были написаны. Переносимость же у С (обычного не ++) выше. Так что же на нем писать?

AVK>Если понадобится — будешь и на нем писать.

Ну, если понадобится, то конучно. Вот только очень не хочется. Я на нем уже в свое время по писал... с меня хватит.

AVK>Я видел одну программку — так там на голом С был написан механизм реализующий ООП. А сделано это было для того чтобы работало на одной платформе на которой C++ отсутствовал. Вот такие вот пирожки с котятами.


Гы. Ты видел одну программку. Я сам такие программки писал. Только было это тогда когда достать нормальную реализацию С++ не было никакой возможности. Вот после этого я и не хочу на нем писать. С++ нуда приятнее.

AVK>Это так, не для спора, просто забавный пример извращений.


Ты нас извращенцев не тронь. :)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.