Переквалификация c#-> ??

[АццкоМото]

jvm разруливаем циклические ссылки, а ARC нет, не разруливат, и что да, garbage collectors производительней reference counting.

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

[crypto5]

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

Начните с себя, пожалуйста.

Я очень стараюсь.

Спорить о недостатках C++ и ObjC ни разу не видев живого кода, и имея за плечами хоть 200К+ хоть 1М+ кода на Жабе, конструктивизма беседе никак не прибавит.
[/qoute]
Телепатия, как она есть.

Давайте вместе напишем что-нибудь?

Области интересов не совпадают.

[crypto5]

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

Начните с себя, пожалуйста.

Я очень стараюсь.

Спорить о недостатках C++ и ObjC ни разу не видев живого кода, и имея за плечами хоть 200К+ хоть 1М+ кода на Жабе, конструктивизма беседе никак не прибавит.
[/qoute]
Телепатия, как она есть.

Давайте вместе напишем что-нибудь?

Области интересов не совпадают.

[crypto5]

Начните с себя, пожалуйста.

Я очень стараюсь.

Спорить о недостатках C++ и ObjC ни разу не видев живого кода, и имея за плечами хоть 200К+ хоть 1М+ кода на Жабе, конструктивизма беседе никак не прибавит.

Телепатия, как она есть.

Давайте вместе напишем что-нибудь?

Области интересов не совпадают.

[crypto5]

jvm разруливаем циклические ссылки, а ARC нет, не разруливат, и что да, garbage collectors производительней reference counting.

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

Задача одинаковая - освободить память автоматически не напрягая программиста.

про то, что я вообще не верю в бОльшую производительность GC vs ARC я пейсать не буду, хрен с ним

http://flyingfrogblog.blogspot.com/2011 ... -than.html

[АццкоМото]

Задача одинаковая - освободить память автоматически не напрягая программиста.

Если мы смотрим на задачу настолько общО, то еще выше производительность у кнопки RESET

http://flyingfrogblog.blogspot.com/2011 ... -than.html

я вообще хрен его знает, что они там намеряли

[Интеррапт]

http://flyingfrogblog.blogspot.com/2011 ... -than.html

Я так понимаю, что автор не заморачивался никакой оптимизацией, ну вроде как включить BOOST_SP_USE_QUICK_ALLOCATOR для boost и т.п. Да и boost в этом отношении "тупее", потому как он же не на уровне комплятора работает. А вот в Objective-C компиляция/оптимизация для ARC будет умнее - там, где компилятор увидит, что нет смысла инкрементировать/декрементировать reference counter - то этого сделано и не будет.

[crypto5]

http://flyingfrogblog.blogspot.com/2011 ... -than.html

Я так понимаю, что автор не заморачивался никакой оптимизацией, ну вроде как включить BOOST_SP_USE_QUICK_ALLOCATOR для boost и т.п.

Там в коментах этот вопрос обсудили, получилось быстрее, но все равно в 4 раза медленнее OCaml.

Да и boost в этом отношении "тупее", потому как он же не на уровне комплятора работает. А вот в Objective-C компиляция/оптимизация для ARC будет умнее - там, где компилятор увидит, что нет смысла инкрементировать/декрементировать reference counter - то этого сделано и не будет.

В очередной раз про escape alalysis, джава и возможно ocaml тоже увидят тоже самое.

[Интеррапт]

Там в коментах этот вопрос обсудили, получилось быстрее, но все равно в 4 раза медленнее OCaml.

Уверен, что еще кучу оптимизаций можно нарыть, включая в самом коде. А по честному если, то им нужно было замерять с C++11 где поддержка shared_ptr на уровне компилятора и где компилятор бы соптимизировал ненужные ref counts.

[Интеррапт]

Даже мельком глянув на код, сразу вижу, что авторы почему-то передают shared_ptr по значению даже там, где можно передавать по ссылке. Приличный такой оверхед получается, т.к. постоянно делаются ненужные копии.

[crypto5]

Даже мельком глянув на код, сразу вижу, что авторы почему-то передают shared_ptr по значению даже там, где можно передавать по ссылке. Приличный такой оверхед получается, т.к. постоянно делаются ненужные копии.

Это несправедливый подход, т.к. он не будет работаь в многопоточной среде, но в коментах это тоже попробовали, там есть переписанный код с передачей by reference, все равно отставание получилось значительным.

[Интеррапт]

Даже мельком глянув на код, сразу вижу, что авторы почему-то передают shared_ptr по значению даже там, где можно передавать по ссылке. Приличный такой оверхед получается, т.к. постоянно делаются ненужные копии.

Это несправедливый подход, т.к. он не будет работаь в многопоточной среде, но в коментах это тоже попробовали, там есть переписанный код с передачей by reference, все равно отставание получилось значительным.

Смотря как именно написать, там же не каждый указанный метод будет вызываться из разных потоков, а только несколько (или вообще один?). Так что вполне даже можно соптимизировать. И с чего вы взяли, что код, который использовался для тестирования OCaml - был thread-safe?

А несправедливый подход - это использовать 3rd party library (в данном случае boost), даже не настроить ее толком и сравнивать со встроенным garbage collector, выдав броский заголовок "Boost's shared_ptr up to 10× slower than OCaml's garbage collection".

И вообще - такой тест для меня имел бы смысл, если бы использовался встроенный shared_ptr из C++11, чтобы оптимизатор мог оптимизировать все что нужно.

[crypto5]

Даже мельком глянув на код, сразу вижу, что авторы почему-то передают shared_ptr по значению даже там, где можно передавать по ссылке. Приличный такой оверхед получается, т.к. постоянно делаются ненужные копии.

Это несправедливый подход, т.к. он не будет работаь в многопоточной среде, но в коментах это тоже попробовали, там есть переписанный код с передачей by reference, все равно отставание получилось значительным.

Смотря как именно написать, там же не каждый указанный метод будет вызываться из разных потоков, а только несколько (или вообще один?). Так что вполне даже можно соптимизировать. И с чего вы взяли, что код, который использовался для тестирования OCaml - был thread-safe?

Мне кажется функциональная парадигма окамла не подразумевает написание thread unsafe кода в принципе, нету состояний которые меняются разными тредами, все работает через message passing.

А несправедливый подход, это использовать 3rd party library и сравнивать со встроенным garbage collector. Такой тест для меня имел бы смысл, если бы использовался встроенный shared_ptr из C++11.

А какие по вашему бенефиты "встроенности" shared_ptr в С++11 в аспекте производительности?

[vladich]

Мне кажется функциональная парадигма окамла не подразумевает написание thread unsafe кода в принципе, нету состояний которые меняются разными тредами, все работает через message passing.

В OCaml там все совсем не так здорово как кажется - http://stackoverflow.com/questions/6588 ... -abilities
Он далеко не чисто функциональный, И standard library там не thread safe, так что "из коробки" там thread safety нет.
Правда его рантайм вроде как однопоточный вообще, так что это должно быть пофигу, наверное.

[crypto5]

Мне кажется функциональная парадигма окамла не подразумевает написание thread unsafe кода в принципе, нету состояний которые меняются разными тредами, все работает через message passing.

В OCaml там все совсем не так здорово как кажется - http://stackoverflow.com/questions/6588 ... -abilities
Он далеко не чисто функциональный, И standard library там не thread safe, так что "из коробки" там thread safety нет.
Правда его рантайм вроде как однопоточный вообще, так что это должно быть пофигу, наверное.

Ну это то о чем я говорю, народ поднимает процессы которые пуляют друг в друга мессаджами, разделенного состояния нету. Так же и в ерланге, и в scala/akka

[dotcom]

Области интересов не совпадают.

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

[Интеррапт]

А какие по вашему бенефиты "встроенности" shared_ptr в С++11 в аспекте производительности?

Тем что компилятор может соптимизировать reference counting, например, вообще его не использовать в каких-то случаях.

[АццкоМото]

А какие по вашему бенефиты "встроенности" shared_ptr в С++11 в аспекте производительности?

Тем что компилятор может соптимизировать reference counting, например, вообще его не использовать в каких-то случаях.

Хотя идея в целом здравая, я не думаю, что дело в этом. Сам reference counting настолько дешев, что получить его отставание в 10 раз можно только каким-то очень креативным подходом. А креативный подход заборет и компилятор, к бабке ходить не нужно

[crypto5]

А какие по вашему бенефиты "встроенности" shared_ptr в С++11 в аспекте производительности?

Тем что компилятор может соптимизировать reference counting, например, вообще его не использовать в каких-то случаях.

Ок, я вот накидал небольшой тест, который пытается напрягать память, если есть желание можете заимплементить альтернативную версию на ObjectiveC, C++, C++11 с ARC, и можно померятся у кого быстрее.
Если есть какие-то замечания и поправки к тесту, я выслушаю и внесу изменения.

Code: Select all

public class GCTest {
  public static void main(String args[]) {
    int COUNT = 100;
    // init
    Data data[] = new Data[COUNT];
    for(int i = 0; i < COUNT; i ++) data[i] = new Data(i);
    Data current = data[0];
    // process
    for(long iter = 0; iter < 100000000; iter ++) {
      int nextIndex = (current.payload + 1) % COUNT;
      Data newNode = data[nextIndex];
      data[nextIndex] = new Data((current.payload + newNode.payload + 1) % COUNT);
      current = newNode;
    }
  }
}

class Data {
  public int payload;
  
  Data(int payload) {
    this.payload = payload;
  }
}

Code: Select all

$ javac GCTest.java 
$ time java -server GCTest

real	0m2.153s
user	0m2.000s
sys	0m0.190s

[Интеррапт]

Ок, я вот накидал небольшой тест, который пытается напрягать память, если есть желание можете заимплементить альтернативную версию на ObjectiveC, C++, C++11 с ARC, и можно померятся у кого быстрее.

А GC хоть раз включился во время выполнения этого теста?

[vladich]

Мне кажется функциональная парадигма окамла не подразумевает написание thread unsafe кода в принципе, нету состояний которые меняются разными тредами, все работает через message passing.

В OCaml там все совсем не так здорово как кажется - http://stackoverflow.com/questions/6588 ... -abilities
Он далеко не чисто функциональный, И standard library там не thread safe, так что "из коробки" там thread safety нет.
Правда его рантайм вроде как однопоточный вообще, так что это должно быть пофигу, наверное.

Ну это то о чем я говорю, народ поднимает процессы которые пуляют друг в друга мессаджами, разделенного состояния нету. Так же и в ерланге, и в scala/akka

Мне казалось "функциональная парадигма" не имеет отношения к "поднимать процессы и пулять друг в друга месседжами". В однопоточной среде конечно трудно написать thread unsafe код, только это опять же не имеет отношения к функциональной парадигме. Там вроде как thread safety должна выходить действительно из-за отсутствия shared state, а не из-за того что мы физически рантайм ограничиваем одним тредом, как это в оКамле происходит.

[АццкоМото]

Я считаю, нужно докинуть еще пару ноликов в iter < 100000000 и быть уверенным, что GC таки включился Хотя я слышал, что у каждого гуглера по 100 терабайт оперативки, так что и это не факт

[Интеррапт]

Я считаю, нужно докинуть еще пару ноликов в iter < 100000000 и быть уверенным, что GC таки включился Хотя я слышал, что у каждого гуглера по 100 терабайт оперативки, так что и это не факт

Так тест вообще как бы не особо честный. Получается, что java vm навыделяет кучу памяти (которая у java таки довольно быстрая операция), а потом целиком весь процесс закроется похерив всю эту память и не дав GC возможности ее очистить.

[crypto5]

Я считаю, нужно докинуть еще пару ноликов в iter < 100000000 и быть уверенным, что GC таки включился Хотя я слышал, что у каждого гуглера по 100 терабайт оперативки, так что и это не факт

Так тест вообще как бы не особо честный. Получается, что java vm навыделяет кучу памяти (которая у java таки довольно быстрая операция), а потом целиком весь процесс закроется похерив всю эту память и не дав GC возможности ее очистить.

Code: Select all

time java -server -verbose:gc GCTest
2013-05-06T11:35:18.151-0700: 0.104: [GC 16448K->296K(62848K), 0.0012980 secs]
2013-05-06T11:35:18.171-0700: 0.125: [GC 16744K->272K(79296K), 0.0012930 secs]
2013-05-06T11:35:18.219-0700: 0.172: [GC 33168K->280K(79296K), 0.0012650 secs]
2013-05-06T11:35:18.260-0700: 0.214: [GC 33176K->304K(112192K), 0.0011560 secs]
2013-05-06T11:35:18.354-0700: 0.307: [GC 66096K->288K(112192K), 0.0013680 secs]
2013-05-06T11:35:18.435-0700: 0.388: [GC 66080K->280K(175616K), 0.0014010 secs]
2013-05-06T11:35:18.621-0700: 0.574: [GC 131864K->268K(175616K), 0.0019760 secs]
2013-05-06T11:35:18.782-0700: 0.736: [GC 131852K->284K(307200K), 0.0007870 secs]
2013-05-06T11:35:19.151-0700: 1.104: [GC 263388K->268K(307264K), 0.0021510 secs]
2013-05-06T11:35:19.476-0700: 1.429: [GC 263372K->252K(392768K), 0.0007920 secs]
2013-05-06T11:35:19.933-0700: 1.887: [GC 348860K->268K(375744K), 0.0011300 secs]

real	0m2.179s
user	0m2.060s
sys	0m0.140s

ГЦ включился 11 раз.

[crypto5]

Мне кажется функциональная парадигма окамла не подразумевает написание thread unsafe кода в принципе, нету состояний которые меняются разными тредами, все работает через message passing.

В OCaml там все совсем не так здорово как кажется - http://stackoverflow.com/questions/6588 ... -abilities
Он далеко не чисто функциональный, И standard library там не thread safe, так что "из коробки" там thread safety нет.
Правда его рантайм вроде как однопоточный вообще, так что это должно быть пофигу, наверное.

Ну это то о чем я говорю, народ поднимает процессы которые пуляют друг в друга мессаджами, разделенного состояния нету. Так же и в ерланге, и в scala/akka

Мне казалось "функциональная парадигма" не имеет отношения к "поднимать процессы и пулять друг в друга месседжами". В однопоточной среде конечно трудно написать thread unsafe код, только это опять же не имеет отношения к функциональной парадигме. Там вроде как thread safety должна выходить действительно из-за отсутствия shared state, а не из-за того что мы физически рантайм ограничиваем одним тредом, как это в оКамле происходит.

Ок, пусть это будет не функциональная парадигма, а парадигма актеров. Мне все равно какие термины использовать.