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

[ddv]

Про делегаты?

Что именно? Я признал что они являются некоторыми аналогами указателей на функции..и?

[fruit6]

как насчет открыть отдельную тему в вопросах IT? базар про 150K был гораздо более увлекателен

[crypto5]

Мне просто стало интерестно как ФИЗИЧЕСКИ возможно сделать то что вы описали в Windows. По-моему это просто невозможно.

Ну так может вы напишите в чем именно заключаются ваши сомнения?

[ddv]

Ну так может вы напишите в чем именно заключаются ваши сомнения?

Элементарно. Как user space приложение может расчитать возможность попадания какого то участа памяти в cache процессора при том что есть диспетчер задач который не подвластен ему.

[nightmare2]

как насчет открыть отдельную тему в вопросах IT? базар про 150K был гораздо более увлекателен

Ну так скажите че нить по теме (150k).
Как по-вашему, достойны C#-повцы получать столько же сколько и C++-совцы.

[crypto5]

Ну так может вы напишите в чем именно заключаются ваши сомнения?

Элементарно. Как user space приложение может расчитать возможность попадания какого то участа памяти в cache процессора при том что есть диспетчер задач который не подвластен ему.

Оно может рядом мер существенно повысить эту вероятность, например генерить меньше memory barrier инструкций.

[Zombie416]

Но место то они все равно в памяти расходуют...

Они место на диске расходуют, в основном. Причем мало места (bytecode сильно компактнее чем x86). В памяти оказывается уже откомпилированный код конкретного метода, причем только тот который (часто)используется, и JIT может его тасовать как угодно. Последствия для производительности могут быть любые, как в плюс, так и в минус.

Это ровно тоже самая концепция как garbage collection, которая "сама" борется с heap fragmentation. С последствиями как в плюс, так и в минус.

[ddv]

Они место на диске расходуют, в основном. Причем мало места (bytecode сильно компактнее чем x86). В памяти оказывается уже откомпилированный код конкретного метода, причем только тот который (часто)используется, и JIT может его тасовать как угодно. Последствия для производительности могут быть любые, как в плюс, так и в минус.

Похоже что многие java программисты и вправду уверенны, что VM обладает экстрасенсорными и паронормальными возможностями,т.к. может "учитывать" не используя память , реализовывать RTTI механизмы не загружая информацию о классах в память, угадывать место расположение виртуальных методов после выкидывания ненужных вместе с информацией о полной структуре класса...и т.п.

[crypto5]

Про делегаты?

Что именно? Я признал что они являются некоторыми аналогами указателей на функции..и?

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

[ddv]

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

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

[zzhou]

Hibernate - очень элегантное и удобное решений, которое преотлично работает в массе больших проектов и отлично экономит силы разработчиков.

То есть вы не спорите с тем, что это внешняя библиотека, к тому же еще и от стороннего разработчика?

О. Началось приписывание слов. Узнаю общение на форуме.

Где я сказал что Hibernate - стандартная библиотека? Мне начали рассказывать про внешние библиотеки для XML и БД для C++ - я и привёл Hibernate - как пример того, что делают на Яве. Кстати, на C++ его вообще нетривиально реализовать - он полагается на reflection и генерацию байткода на лету.

[zzhou]

Как по-вашему, достойны C#-повцы получать столько же сколько и C++-совцы.

С++ разработчикам за работу можно вообще не платить - им достаточно своего чувства превосходства от теоретической возможности написать велосипед, который давно реализован в Java VM и работает там с кодом написаном студентом из Индии.

[nightmare2]

Как по-вашему, достойны C#-повцы получать столько же сколько и C++-совцы.

С++ разработчикам за работу можно вообще не платить - им достаточно своего чувства превосходства от теоретической возможности написать велосипед, который давно реализован в Java VM и работает там с кодом написаном студентом из Индии.

[crypto5]

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

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

Не признаю

Кроме того я все равно был прав - "масив указателей на функции в с# реализовать нельзя", можно только массив делегатов, а это не тоже самое...близко, но не тоже.

Конечно не то, делегаты ведь намного лучше, т.к. они type safe, не понимаю чем вы так гордитесь!

[Zombie416]

Похоже что многие java программисты и вправду уверенны, что VM обладает экстрасенсорными и паронормальными возможностями,т.к. может "учитывать" не используя память , реализовывать RTTI механизмы не загружая информацию о классах в память, угадывать место расположение виртуальных методов после выкидывания ненужных вместе с информацией о полной структуре класса...и т.п.

Мне трудно сказать в чем уверены Java программисты, есть большое количество разных JVM, но информации в сети предостаточно. Java HotSpot была интересной штукой еще 10 лет назад, и стала работать с тех пор гораздо быстрее http://java.sun.com/products/hotspot/do ... Id=1082375

В .NET угадывать виртуальные методы не нужно, они явно обозначаются программистом. Как и легко определить неиспользуемые private методы, что позволяют многие средства даже без компиляции вообще (C# / Java синтаксис гораздо моложе и проще чем C++). И да, информация о типах, ака metadata, содержится в исполняемом модуле отдельно от кода классов. И да, .NET в подавляющем большинстве случаев компилирует по методам (если иначе не указано хинтами), и при a=false

Code: Select all

 if (a) b();

код b() будет жить на диске долго, и никогда не будет сконвертирован в машинный код.

Что до производительности, есть вполне очевидная вещь, что если есть два динамически собираемых модуля 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.

Вот что заметно, так это что отдельные C++ - only программисты почему-то относятся к этому языку как к священной корове, не допуская что компиляторы бывают и у других языков. А если это C++ Windows-only программисты, то и самая мысль что программа может распространяться не в виде жестко откомпилированных в машинный код модулей, а требовать доводки на месте кажется кощунственной. Хотя при этом принимают чуть меньшую степень такой доводки, ака динамическую сборку, как должное. Чудеса, да и только. Но проходит со временем

[ddv]

Не признаю

Ну тогда требую ссылку на оригинал...Нет ссылки - нет разговора.

[ddv]

В .NET угадывать виртуальные методы не нужно, они явно обозначаются программистом.

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

[ddv]

. И да, информация о типах, ака metadata, содержится в исполняемом модуле отдельно от кода классов.

Вот вот...только во время исполнения она содержится и в ПАМЯТИ...и занимает МЕСТО независимо от того используется или нет.

[zzhou]

В .NET угадывать виртуальные методы не нужно, они явно обозначаются программистом.

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

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

[crypto5]

Не признаю

Ну тогда требую ссылку на оригинал...Нет ссылки - нет разговора.

Я совсем ничего не понял, вы написали какую то ерунду, потом попросили зачем то меня эту ерунду "признать", а теперь еще требуете каких то документальных доказательств? Я потерялся если чесно.

[zzhou]

. И да, информация о типах, ака metadata, содержится в исполняемом модуле отдельно от кода классов.

Вот вот...только во время исполнения она содержится и в ПАМЯТИ...и занимает МЕСТО независимо от того используется или нет.

1. А никто (по крайней мере - я) не утверждает что Ява использует меньше памяти. Мы больше про быстродействие кода говорим.
2. Типовая утечка памяти в C++ приложении заберёт больше памяти чем все загруженые но бесполезные классы в приложении на Яве(на всякий случай сообщу - в память грузятся только классы, которые реально используются)
3. Подозреваю, С++ программа тоже содержит мусор в exeшнике - и его иногда грузит в память.

[ddv]

Я совсем ничего не понял, вы написали какую то ерунду, потом попросили зачем то меня эту ерунду "признать", а теперь еще требуете каких то документальных доказательств? Я потерялся если чесно.

НУ так я вам напомню..вы писали

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

я вас попросил

У вас есть ссылка но оригинал где описывается данный memory manager?

после чего вы попытались перевести стрелки и уйти от ответа

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

Более того, вы начали со мной спорить что на С++ написать такой memory manager нельзя, а в ответ на мое высказывание что можно потребовали предоставить пример такого...только вот какого вы сами не смогли сказать.
Так что или найдите ссылку на "ХОРОШИЙ java memory manager" который "можут эфективно разбивать кучу на области для потоков" или признайте что вы ошиблись

[ddv]

1. А никто (по крайней мере - я) не утверждает что Ява использует меньше памяти. Мы больше про быстродействие кода говорим.

Не вы,а Zombie416 спорил со мной:

Они место на диске расходуют, в основном. Причем мало места (bytecode сильно компактнее чем x86). В памяти оказывается уже откомпилированный код конкретного метода, причем только тот который (часто)используется, и JIT может его тасовать как угодно.

[crypto5]

Так что или найдите ссылку на "ХОРОШИЙ java memory manager" который "можут эфективно разбивать кучу на области для потоков".

Вы там выше просили нечто другое. А кучу разбивают на подкучи для тредов все известные мне менеджеры памяти для джава, и на эту тему можно погуглить по запросам: "local thread heap java" & "local thread area java".

[ddv]

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

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