Как технарю из России стать программером в США за 150К

[crypto5]

Вы там выше просили нечто другое.

Нечто другое это что???? все посты выше...если я не это просил, то что???

Вот эта просьба несколько отличается от просьбы дать доку на устройство менеджера памяти в джава:

Ну тогда ваша очередь признавать что в java нет супер пупер memory manager'а который невозможно реализовать на C++...(хотя если бы он и был в VM то был бы реализован именно на С++ ).

[ddv]

Вы там выше просили нечто другое.

Нечто другое это что???? все посты выше...если я не это просил, то что???

Вот эта просьба несколько отличается от просьбы дать доку на устройство менеджера памяти в джава:

Ну тогда ваша очередь признавать что в java нет супер пупер memory manager'а который невозможно реализовать на C++...(хотя если бы он и был в VM то был бы реализован именно на С++ ).

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

А что касается "local thread area java", то как я изначально и предположил - это попытка исправить проблемы с производительностью garbage collection и это совершенно не нужно в С++. Так что в этом случае вам придется признать, что вы были неправы говоря что
"Проблема только в том что такие менеджеры обычно абстрагированы от системы многопоточности, и не могут эфективно разбивать кучу на области для потоков, а в джаве все с этим хорошо."

[crypto5]

Вы там выше просили нечто другое.

Нечто другое это что???? все посты выше...если я не это просил, то что???

Вот эта просьба несколько отличается от просьбы дать доку на устройство менеджера памяти в джава:

Ну тогда ваша очередь признавать что в java нет супер пупер memory manager'а который невозможно реализовать на C++...(хотя если бы он и был в VM то был бы реализован именно на С++ ).

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

И что? Да я не смог найти доку про то как устроен менеджер памяти в джава, он от этого резко изчез куда то?

А что касается "local thread area java", то как я изначально и предположил - это попытка исправить проблемы с производительностью garbage collection и это совершенно не нужно в С++.

Это ваш еще один крайне сомнительный псевдоаргумент.

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

Что именно здесь неправильно?

[ddv]

И что? Да я не смог найти доку про то как устроен менеджер памяти в джава, он от этого резко изчез куда то?

Опять повторяю...Вы начали это с того что java memory manager лучше чем можно написать на С++ потому что ""Проблема только в том что такие менеджеры обычно абстрагированы от системы многопоточности, и не могут эфективно разбивать кучу на области для потоков, а в джаве все с этим хорошо."

Я захотел узнать чем он лучше и попросил документаую..Так что он не исчез, а подтвердил мои высказывания.

[crypto5]

И что? Да я не смог найти доку про то как устроен менеджер памяти в джава, он от этого резко изчез куда то?

Опять повторяю...Вы начали это с того что java memory manager лучше чем можно написать на С++ потому что ""Проблема только в том что такие менеджеры обычно абстрагированы от системы многопоточности, и не могут эфективно разбивать кучу на области для потоков, а в джаве все с этим хорошо."

Я захотел узнать чем он лучше и попросил документаую..Так что он не исчез, а подтвердил мои высказывания.

Я со всем согласен, за исключением того что последнее предложение кажется мне полным бредом. Менеджер памяти, доку про который я не смог найти, подтвердил ваши высказывания? Лично?

[ddv]

Я со всем согласен, за исключением того что последнее предложение кажется мне полным бредом. Менеджер памяти, доку про который я не смог найти, подтвердил ваши высказывания? Лично?

Если сарказм для вас недоступен, то я могу перевести предложение на псевдо код...

Code: Select all

bool memory_manager_exist = true
bool proof_that_it_is_super_puper_memory_manager = false

bool memory_manager_is_simple = !proof_that_it_is_super_puper_memory_manager &&  memory_manager_exist
bool i_am_right = memory_manager_is_simple

[crypto5]

Я со всем согласен, за исключением того что последнее предложение кажется мне полным бредом. Менеджер памяти, доку про который я не смог найти, подтвердил ваши высказывания? Лично?

Если сарказм для вас недоступен, то я могу перевести предложение на псевдо код...

Code: Select all

bool memory_manager_exist = true
bool proof_that_it_is_super_puper_memory_manager = false

bool memory_manager_is_simple = !proof_that_it_is_super_puper_memory_manager &&  memory_manager_exist
bool i_am_right = memory_manager_is_simple

Скажу чесно, я не улавливаю что же вы хотите сказать. То есть я догадываюсь что ваша цель это вывести что i_am_right == true, но вот метод на мой взгляд не содержит логического обоснования

[ddv]

Скажу чесно, я не улавливаю что же вы хотите сказать. То есть я догадываюсь что ваша цель это вывести что i_am_right == true, но вот метод на мой взгляд не содержит логического обоснования

Ок...тогда может быть начнем сначала? Вы согласны с тем что memory manager java НЕ более эффективный чем в С++ даже в много поточных приложениях?

[crypto5]

Скажу чесно, я не улавливаю что же вы хотите сказать. То есть я догадываюсь что ваша цель это вывести что i_am_right == true, но вот метод на мой взгляд не содержит логического обоснования

Ок...тогда может быть начнем сначала? Вы согласны с тем что memory manager java НЕ более эффективный чем в С++ даже в много поточных приложениях?

Не согласен

[ddv]

Что до производительности, есть вполне очевидная вещь, что если есть два динамически собираемых модуля A и B, в одном из которых есть нечто вроде

Code: Select all

namespace A { class X { public: static int Y(int z) { return z+5; }} }

Если модуль B откомпилирован, то A::X::Y(10) будет занимать кучу времени. В то время как в случае если A и B managed, вызов скорее всего будет inline.

Во-первых, это только в случае динамического связывания, которого в С++ на несколько порядков меньше чем в С#. Кроме того, в managed еще хуже...там даже в рамках одного модуля этого не делается...Я специально в отладчике посмотрел код.

Code: Select all

 class Test
    {
        public int calc(int x, int y)
        {
            return x + y;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Test tc = new Test();
            int ii = tc.calc(1, 2);
            Console.WriteLine(ii);
        }
    }
}

Code: Select all

            int ii = tc.calc(1, 2);
00000060  push        2 
00000062  mov         ecx,dword ptr [ebp-30h] 
00000065  mov         edx,1 
0000006a  cmp         dword ptr [ecx],ecx 
0000006c  call        dword ptr ds:[00169954h] 
00000072  mov         dword ptr [ebp-24h],eax 
00000075  mov         eax,dword ptr [ebp-24h] 
00000078  mov         dword ptr [ebp-8],eax 

static тоже не влияет..я проверял

[ddv]

Не согласен

И по вашему его невозможно реализовать на С++?

[crypto5]

Не согласен

И по вашему его невозможно реализовать на С++?

Я не знаю..

[ddv]

Я не знаю..

Давайте докажем такую возможность от противного. Предположим что его нельзя написать на С++. Но ведь java VM написана на asm/C/C++...из этого следует что и этот memory manager тоже написан на смеси этих языков...из чего следует что его можно было бы применить и в С++, а это противоречит изначальному условию что его нельзя написать на С++.
Значит его можно написать на С++.

Теперь по поводу полезности такого memory manager в С++. Предположим что он ооочень полезен для С++...тогда наверняка его уже кто нибудь написал бы за столько лет. Значит он уже или есть и мы просто незнаем,т.к. мы у нас нет документации на описание такого memory manager....или он просто бесполезен и поэтому его никто не пишет. Тут конечно не точное логическое доказательтво, но , по моему, более вероятное чем предположение о том, что все такие тупые и ленивые что не могут реализовать такой полезный memory manager для С++.

Что в моих словах вам кажется не логичным?

[Zombie416]

Я специально в отладчике посмотрел код.

А этого делать ненужно. Отладчик для managed apps - это штука такая, "you never know what you're gonna get"

Сделайте две assemblies, одну с кодом вроде:

Code: Select all

using System.Runtime.CompilerServices;
namespace A
{
    public class X
    {
        // [MethodImpl(MethodImplOptions.NoInlining)]
        public static int Add(int x, int y) { return x+y; }
    }
}

А вторую - бенчмарк:

Code: Select all

using System;
using System.Diagnostics;

namespace simple
{
    class Program
    {
        static void Main(string[] args)
        {
            int z=0;
            var start = Stopwatch.StartNew();
            for (long i = 0; i < 1024L * 1024 * 1024; ++i)
                z = A.X.Add(z,z);
            Console.WriteLine("Elapsed:"+start.ElapsedMilliseconds);
            Console.WriteLine("Press Enter");
            Console.WriteLine(z); // so it's not optimized out
            Console.ReadLine();
        }
    }
}

А потом сравните время исполнения с включенным и выключенным inlining Add (без отладчика). Будет отличаться в разы. При запуске в отладчике время будет одинаковым.

При этом время исполнения будет одинаково, независимо от того находится Add в том же модуле что Main, или в отдельном.

[Zombie416]

Вы на самом деле такой или только претворяетесь? Я писал что по вашему нужно угадывать РАСПОЛОЖЕНИЕ виртуального метода!!! Вы хоть слышали про таблицу виртуальных методов? Если вы выкинете такой метод в рантайме, то у вас ничего не сойдется и вы не найдете нужный метод на нужном месте.

О чем вы писали я уж затрудняюсь сказать, все больше о том что вы не понимаете как работают managed языки и не хотите понимать. Про таблицу виртуальных методов я слышал, не притворяюсь, нет

А теперь попробуйте подумать почему даже виртуальные методы совершенно необязательно компилировать в машинный код сразу, а можно подождать до собственно вызова. И private методы которые никогда не вызываются вполне можно обнаружить и выбросить независимо от того виртуальные они или нет. И почему RTTI/metadata и машинный код - вещи совершенно параллельные и слабо друг от друга зависимые.

[ddv]

И private методы которые никогда не вызываются вполне можно обнаружить и выбросить независимо от того виртуальные они или нет.

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

И почему RTTI/metadata и машинный код - вещи совершенно параллельные и слабо друг от друга зависимые.

Это в С++ они паралелльные, а для .NET это основная информация.

[Zombie416]

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

reflection на private методы может и не работать.

Это в С++ они паралелльные, а для .NET это основная информация.

В нативно откомпилированном C++ просто metadata победнее.

И опять-таки не надо противопоставлять C++ и .NET, это апельсины и яблоки. C++/CLR - вполне себе нормальный компилятор, настолько же стандартный насколько это вообще возможно у майкрософтовских компиляторов. Только что код не x86 выплевывает, а более нечто более portable и с более развитыми средствами динамической компоновки.

[ddv]

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

reflection на private методы может и не работать.

Работает - я пробовал.

[Zombie416]

Работает - я пробовал.

Рантаймов может быть великое множество, оптимизировать они могут совершенно по-разному, и что reflection над private частями работает никто не обещал. В Silverlight, например, не будет работать.

[crypto5]

Я не знаю..

Давайте докажем такую возможность от противного. Предположим что его нельзя написать на С++. Но ведь java VM написана на asm/C/C++...из этого следует что и этот memory manager тоже написан на смеси этих языков...из чего следует что его можно было бы применить и в С++, а это противоречит изначальному условию что его нельзя написать на С++.
Значит его можно написать на С++.

Вы упускаете ряд прекондишнов, например то что в случае с джавой присутствует уборщик мусора(не нужно отслеживать ситуации когда другой тред пытается прибить локально закешированный обьект), а в случае с С++ его нету, то что в случае С++ ваш менеджер памяти должен уметь линковаться с произвольной библиотекой тредов, а в случае джавы вполне известно какой код реализует треды, и можно эксплуатировать его возможности или оптимизировать под себя, ну и я подозреваю что в С++ и джаве heapens-before правила могут быть разными.

Теперь по поводу полезности такого memory manager в С++. Предположим что он ооочень полезен для С++...тогда наверняка его уже кто нибудь написал бы за столько лет. Значит он уже или есть и мы просто незнаем,т.к. мы у нас нет документации на описание такого memory manager....или он просто бесполезен и поэтому его никто не пишет. Тут конечно не точное логическое доказательтво, но , по моему, более вероятное чем предположение о том, что все такие тупые и ленивые что не могут реализовать такой полезный memory manager для С++.

Я читал где то про такие реализации, но они были интегрированы с конкретной библиотекой тредов, видимо не соответствовали каким то стандартам, и обычному С++ программисту юзающему glibc видимо бесполезны.

Что в моих словах вам кажется не логичным?

Нет!

[ddv]

то что в случае С++ ваш менеджер памяти должен уметь линковаться с произвольной библиотекой тредов, а в случае джавы вполне известно какой код реализует треды

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

[crypto5]

то что в случае С++ ваш менеджер памяти должен уметь линковаться с произвольной библиотекой тредов, а в случае джавы вполне известно какой код реализует треды

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

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

[crypto5]

А, вот нашел, фейсбук таким занимался:

[ddv]

то что в случае С++ ваш менеджер памяти должен уметь линковаться с произвольной библиотекой тредов, а в случае джавы вполне известно какой код реализует треды

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

Мой профанский взгляд заключается в том что вы счас нафантазировали.

Т.е. вы считаете что необходимые ЛЮБОМУ memory manager выделения памяти у операционной системы, mutexes, events, atomic operations и т.п. не зависят от операционной системы и архитектуры процессора? А если зависят - значит он жестко привязывается к архитектуре. Можно написать кроссплатформенный, но в любом случае он должен будет в каждом конкретном случае использовать специфические вызовы системы.

[crypto5]

то что в случае С++ ваш менеджер памяти должен уметь линковаться с произвольной библиотекой тредов, а в случае джавы вполне известно какой код реализует треды

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

Мой профанский взгляд заключается в том что вы счас нафантазировали.

Т.е. вы считаете что необходимые ЛЮБОМУ memory manager выделения памяти у операционной системы, mutexes, events, atomic operations и т.п. не зависят от операционной системы и архитектуры процессора? А если зависят - значит он жестко привязывается к архитектуре. Можно написать кроссплатформенный, но в любом случае он должен будет в каждом конкретном случае использовать специфические вызовы системы.

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