Google Recruiter

[crypto5]

Помоему достаточно недальновидно проецировать реалии .нет-а на джаву. К тому же люди которые писали ваш гейт наверное приложили определенные усилия что бы минимизировать вызов ГЦ.

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

[АццкоМото]

получается что 9/10 полезной работы при которой производительность будет в 4 раза больше (тут еще нужно учесть тот факт, что на машине обычно 4 камня, а gc собирается 1им (остальные потоки просто тормозятся), так что кеш остальных потоков не "попортится")

Все, я сдаюсь. Если джава спокойно подменяется дотнетом, экономия в военное время достигает четырехкратной, а gc=неизбежное зло, то я уже ничего не смогу объяснить.
Вы прыгаете с одного на другое, забываете о чем шла речь и в качестве бронебойных аргументов приводите какие-то никому неизвестные примеры "своего гейта", о сложности и нагрузке которого ни у кого нет ни малейшего понятия. Вы опереруете совершенно прелестными аргументами типа "прибить каждый поток к своему камню", совершенно игнорируя, что не всегда это возможно, а потоков могут быть тысячи
Не, я так больше не могу. Удачи вам в четырехкратном экономии пропускной способности памяти. В песочницах гыгы

ЗЫ. Отдельной строкой доставило на машине обычно 4 камня
Не, я бы понял еще с трудом "у машины обычно 4 колеса". Но это - в мемориз

[Alexandr]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

[Alexandr]

Помоему достаточно недальновидно проецировать реалии .нет-а на джаву. К тому же люди которые писали ваш гейт наверное приложили определенные усилия что бы минимизировать вызов ГЦ.

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

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

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

так я согласен с этим, скажем так, имхо, джавистам (большинству) полезно знать о наличие кешей и в целом как они работают в общих чертах
ну и процентам 5% джавистов все же полезно знать чуть побольше о выполняемой среде, опять же, имхо

[crypto5]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

В некоторых случаях без тысячи потоков тяжело обойтись(например нужно делать много запросов к сторонним БД с latency 10ms, а их драйвера не поддерживают интерфейс на неблокирующих сокетах).

[crypto5]

Помоему достаточно недальновидно проецировать реалии .нет-а на джаву. К тому же люди которые писали ваш гейт наверное приложили определенные усилия что бы минимизировать вызов ГЦ.

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

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

Та не сойдет, оптимизированный по работе с памятью код может работать в тысячу раз быстрее чем неоптимизированный.

[Alexandr]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

В некоторых случаях без тысячи потоков тяжело обойтись(например нужно делать много запросов к сторонним БД с latency 10ms, а их драйвера не поддерживают интерфейс на неблокирующих сокетах).

ну так мы вынуждены создавать эти тысячи потоков от безысходности, о какой-нибудь серьезной производительности тут вообще речь не идет, хотя для той задачи которую вы описали может и достаточно
если дело происходит под Windows, то лучше такое сделать на C++ на фиберах и в одном потоке (сам опыта не имею, но вроде так можно)
хотя лучше просто выкинуть такую базу (если есть такая возможность)

[crypto5]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

В некоторых случаях без тысячи потоков тяжело обойтись(например нужно делать много запросов к сторонним БД с latency 10ms, а их драйвера не поддерживают интерфейс на неблокирующих сокетах).

ну так мы вынуждены создавать эти тысячи потоков от безысходности, о какой-нибудь серьезной производительности тут вообще речь не идет, хотя для той задачи которую вы описали может и достаточно
если дело происходит под Windows, то лучше такое сделать на C++ на фиберах и в одном потоке (сам опыта не имею, но вроде так можно)
хотя лучше просто выкинуть такую базу (если есть такая возможность)

А что такое фибер?

[Alexandr]

Помоему достаточно недальновидно проецировать реалии .нет-а на джаву. К тому же люди которые писали ваш гейт наверное приложили определенные усилия что бы минимизировать вызов ГЦ.

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

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

Та не сойдет, оптимизированный по работе с памятью код может работать в тысячу раз быстрее чем неоптимизированный.

это опять общие фразы
best effort на C# будет отличаться от best effort на Java на вполне конкретный процент,
приблизительно прикинуть в общем случае можно глянув бенчмарки того и другого

[crypto5]

Помоему достаточно недальновидно проецировать реалии .нет-а на джаву. К тому же люди которые писали ваш гейт наверное приложили определенные усилия что бы минимизировать вызов ГЦ.

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

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

Та не сойдет, оптимизированный по работе с памятью код может работать в тысячу раз быстрее чем неоптимизированный.

это опять общие фразы
best effort на C# будет отличаться от best effort на Java на вполне конкретный процент,
приблизительно прикинуть в общем случае можно глянув бенчмарки того и другого

А где выше про best effort было?

[Alexandr]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

В некоторых случаях без тысячи потоков тяжело обойтись(например нужно делать много запросов к сторонним БД с latency 10ms, а их драйвера не поддерживают интерфейс на неблокирующих сокетах).

ну так мы вынуждены создавать эти тысячи потоков от безысходности, о какой-нибудь серьезной производительности тут вообще речь не идет, хотя для той задачи которую вы описали может и достаточно
если дело происходит под Windows, то лучше такое сделать на C++ на фиберах и в одном потоке (сам опыта не имею, но вроде так можно)
хотя лучше просто выкинуть такую базу (если есть такая возможность)

А что такое фибер?

http://msdn.microsoft.com/en-us/library ... s.85).aspx

вот в этой книжке http://www.amazon.com/Concurrent-Progra ... 032143482X описан простой пример как самому контекст переключать и организовать что-то вроде user mode "thread" scheduling

[crypto5]

дык, и вам удачи с серверным приложением, у которого тысячи потоков

В некоторых случаях без тысячи потоков тяжело обойтись(например нужно делать много запросов к сторонним БД с latency 10ms, а их драйвера не поддерживают интерфейс на неблокирующих сокетах).

ну так мы вынуждены создавать эти тысячи потоков от безысходности, о какой-нибудь серьезной производительности тут вообще речь не идет, хотя для той задачи которую вы описали может и достаточно
если дело происходит под Windows, то лучше такое сделать на C++ на фиберах и в одном потоке (сам опыта не имею, но вроде так можно)
хотя лучше просто выкинуть такую базу (если есть такая возможность)

А что такое фибер?

http://msdn.microsoft.com/en-us/library ... s.85).aspx

вот в этой книжке http://www.amazon.com/Concurrent-Progra ... 032143482X описан простой пример как самому контекст переключать и организовать что-то вроде user mode "thread" scheduling

А в чем профит?

[Alexandr]

А где выше про best effort было?

просто мне там в вину поставили то, что я пример на C# привел, так вот этот пример и был оптизирован настолько насколько я смог и позволяло время на проект, соответственно если речь о Java, то я тоже предполагаю, что это будет best effort, потому что в противном случае вообще смысл теряется

под best effort можете понимать - оптимизировать насколько можно за вменяемое время

[crypto5]

А где выше про best effort было?

просто мне там в вину поставили то, что я пример на C# привел, так вот этот пример и был оптизирован настолько насколько я смог и позволяло время на проект, соответственно если речь о Java, то я тоже предполагаю, что это будет best effort, потому что в противном случае вообще смысл теряется

под best effort можете понимать - оптимизировать насколько можно за вменяемое время

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

[Alexandr]

А в чем профит?

в 99% никакого, гораздо важнее, чтобы быстрее задачу сделать и не плодить зоопарка из технологий
в 1% - когда потоков станет насколько много, что кусок памяти съедаемый внутренними структурами и стеками потоков станет насколько большим настолько, что это станет существенным + context switch стоит относительно немало, т.е. когда у вас будет потоков насколько много, что 1000+ потоков будут просыпаться одновременно и пытаться там что-то отправить и уже не будут помещаться в отведенное время

[crypto5]

А в чем профит?

в 99% никакого, гораздо важнее, чтобы быстрее задачу сделать и не плодить зоопарка из технологий

И как ваши fibers спасут от зоопарка технологий?

в 1% - когда потоков станет насколько много, что кусок памяти съедаемый внутренними структурами и стеками потоков станет насколько большим настолько, что это станет существенным

Ну так под fiber помоему пониманию тоже стек выделяется и какие то структуры наверное.

+ context switch стоит относительно немало, т.е. когда у вас будет потоков насколько много, что 1000+ потоков будут просыпаться одновременно и пытаться там что-то отправить и уже не будут помещаться в отведенное время

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

[Alexandr]

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

а зачем нужно, чтобы оно было оптимизировано?

так никакие оптимизации и не нужны, вопрос звучал просто, что быстрее последовательный или произвольный доступ к 1000 интовому массиву
вопрос затравка на поговорить о memory hierarchy, не более

[crypto5]

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

а зачем нужно, чтобы оно было оптимизировано?

так никакие оптимизации и не нужны, вопрос звучал просто, что быстрее последовательный или произвольный доступ к 1000 интовому массиву
вопрос затравка на поговорить о memory hierarchy, не более

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

[Alexandr]

И как ваши fibers спасут от зоопарка технологий?

не спасут, наоборот добавят

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

по моему легче драйвер подкрутить, ну или базу такую выкинуть нафик

[Alexandr]

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

а зачем нужно, чтобы оно было оптимизировано?

так никакие оптимизации и не нужны, вопрос звучал просто, что быстрее последовательный или произвольный доступ к 1000 интовому массиву
вопрос затравка на поговорить о memory hierarchy, не более

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

для большинства задач прям уж миллисекунды не нужны, недаром даже бекэнд (обслуживающие) HFT систем на жабе, но есть куча серверных задач на жабе, где нужно все же писать достаточно эффективно (т.е. best effort за вменямое время)
меня нисколько не удивляет, что в стартапе автору задавали такие вопросы

[vladich]

Собственно, есть вполне себе HFT на джаве (не только обслуживающие системы). Просто вызовы GC там сведены к нулю тем что все работает на примитивных типах и вся необходимая память выделяется один раз при старте приложения. На мой взгляд это некое извращение, но тем не менее такое есть. И оптимизировать там не милли, а микросекунды надо.

[crypto5]

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

по моему легче драйвер подкрутить, ну или базу такую выкинуть нафик

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

[crypto5]

Собственно, есть вполне себе HFT на джаве (не только обслуживающие системы). Просто вызовы GC там сведены к нулю тем что все работает на примитивных типах и вся необходимая память выделяется один раз при старте приложения. На мой взгляд это некое извращение, но тем не менее такое есть. И оптимизировать там не милли, а микросекунды надо.

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

[vladich]

Собственно, есть вполне себе HFT на джаве (не только обслуживающие системы). Просто вызовы GC там сведены к нулю тем что все работает на примитивных типах и вся необходимая память выделяется один раз при старте приложения. На мой взгляд это некое извращение, но тем не менее такое есть. И оптимизировать там не милли, а микросекунды надо.

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

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

[olis]

Собственно, есть вполне себе HFT на джаве (не только обслуживающие системы). Просто вызовы GC там сведены к нулю тем что все работает на примитивных типах и вся необходимая память выделяется один раз при старте приложения. На мой взгляд это некое извращение, но тем не менее такое есть. И оптимизировать там не милли, а микросекунды надо.

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

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

А какой смысл тогда вообще Java использовать?