да и пофиг, им и так вроде норм

было бы пофиг, не спорь они о том, что их святой яваскрипт быстрей плюсов))

против адекватных ничего против не имею

было бы пофиг, не спорь они о том, что их святой яваскрипт быстрей плюсов))

да это чет совсем отсталые ребята, не обращай внимания)

эм, а взять свой транспорт с кастомным dialtls?

да вот... придётся своё колесо пилить

а как динамически исполняемый язык может быть априори быстрей условных плюсов?

JIT все дела, но я лично тоже в это не верю

в итоге целый кластер компайл-тайм отптимизаций в нем в приципе недоступен

но на другой стороне есть рантайм-оптимизации, которые недоступны плюсам

было бы пофиг, не спорь они о том, что их святой яваскрипт быстрей плюсов))

монополия она такая..

но на другой стороне есть рантайм-оптимизации, которые недоступны плюсам

рантайм оптимизации ИМХО не дают таких профитов

рантайм оптимизации ИМХО не дают таких профитов

https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html

»The reason is obvious - static compiler can't inline across file boundaries.

https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html

>Overall PyPy is almost 2x faster. This is clearly win for dynamic compilation over static - the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

Всем привет! Можно нубский вопрос закинуть? :)

нельзя

можно не здороваться и не спрашивать. Просто начинай с места в карьер

как это не здороваться?

можно не здороваться и не спрашивать. Просто начинай с места в карьер

Прям как я люблю ???

отвечать человеку который даже не здоровается?

фе

я предлагаю сначало обсудть погоду, потом перейти к сути дела

https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html

on a carefully crafted example я почему то уверен что таких случаев в реальном коде слишком мало чтоб побить стат. компл.

>Overall PyPy is almost 2x faster. This is clearly win for dynamic compilation over static - the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

что такое pypy?

интерпретатор питона на питоне

Короче. Создаю процесс через exec.Command и хочу весь его ввод/вывод перенаправить в TCP сокет. Но при этом пропускать его через свои функции. Я открываю в одно потоке процесс, вешаю его Stdin/out через пайпы на глобальнеы переменные, а потом запускаю другой поток, который читает из out и пишет в сокет

>Overall PyPy is almost 2x faster. This is clearly win for dynamic compilation over static - the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

The reason is obvious - static compiler can't inline across file boundaries.

Это тупо косяк C.

что такое pypy?

еще и с jit

какие проблемы он решает

он ведь по идее медленней должен быть

go компилятор на go вроде тоже существует

The reason is obvious - static compiler can't inline across file boundaries.

file boundaries? так это-ж скорее про C а не про стат. компл. в целом)

но он медленно компилиурет

Читаю примерно так for { message, err := bufio.NewReader(shellOut).ReadString('\n') fmt.Print(message) }

Для теста запускаю на виртуалке с виндой, в качестве комманды обычный cmd.exe И при этом получаю в консоли Microsoft Windows [Version 6.1.7601]

go компилятор на go вроде тоже существует

go компилятор написан на go, начиная с версии 1.5

Это тупо косяк C.

И? Там есть пример с printf, где на каждый вызов парсится format string

go компилятор написан на go, начиная с версии 1.5

пруф

И все. А долже получить полностью Microsoft Windows [Version 6.1.7601] (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены. C:\Users\root>

Что не так-то?

пруф

https://golang.org/doc/go1.5 The compiler and runtime are now written entirely in Go (with a little assembler). C is no longer involved in the implementation, and so the C compiler that was once necessary for building the distribution is gone.

on a carefully crafted example я почему то уверен что таких случаев в реальном коде слишком мало чтоб побить стат. компл.

См graalvm

мне так стыдно

я будто вовсе не го программист

видимо нет

он ведь по идее медленней должен быть

Нет, потому что надо читать внимательно.

я не умею читать внимательно

я серьезно

у меня синдром дифицита внимания

И все. А долже получить полностью Microsoft Windows [Version 6.1.7601] (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены. C:\Users\root>

собери что-то похожее на пример на go playground или gist

непонятно

собери что-то похожее на пример на go playground или gist

Спасибо. 5 сек

go имеет inline функций

go имеет inline функций

это вопрос, утвреждение?

это вопрос, утвреждение?

Утверждение

как оно связано с с? или с js?

Оно связанно с постом выше, в котором c проигрывало питону

собери что-то похожее на пример на go playground или gist

https://play.golang.org/p/tB7U04txSEx

у меня синдром дифицита внимания

это к врачу, не в чат)

это к врачу, не в чат)

к какому ?

https://github.com/golang/go/wiki/CompilerOptimizations

Кстати, использовать каналы struct{} - good practice?

Кстати, использовать каналы struct{} - good practice?

типа да

но я лично предпочитаю шоб чуток читабельней было

и делаю bool

шоб done <- true

Кстати, использовать каналы struct{} - good practice?

actually, yes

https://play.golang.org/p/tB7U04txSEx

очень плохой код с глобальными переменными, посмотрите сюда https://stackoverflow.com/questions/38866952/streaming-commands-output-progress-from-goroutine, попробуйте залогировать ошибки в тчении

но, помоему, логика сломана на строке 70-72

но, помоему, логика сломана на строке 70-72

conn = nil connected = false ???

conn = nil connected = false ???

https://play.golang.org/p/ExHo6TUy3Rc

https://play.golang.org/p/ExHo6TUy3Rc

Да не. По логам - эта часть как раз работает

Где-то лок хватаю, не пойму где

ну, если не хотите переписывать :) то delve вам в руки

Переписывать?

Я бы с удовольствием, просто пока непонятно на что переписывать :)

на нормальный код?

на нормальный код?

Я действительно совсем недавно в го, 2-й день. Просто видимо не понимаю, что именно не так со строками 71 - 72? Обычное условие и вызов функции

проблемы в структуре кода и приложения, проблема не в 71-72, проблема в том, что у вас есть клиент и сервер (похоже на что-то такое) и потребитель/писатель в пайп команды, все в каше, поэтому понять, что именно идет не так без отладчика врядли получится

проблемы в структуре кода и приложения, проблема не в 71-72, проблема в том, что у вас есть клиент и сервер (похоже на что-то такое) и потребитель/писатель в пайп команды, все в каше, поэтому понять, что именно идет не так без отладчика врядли получится

А, каша всмысле что в одном месте пихаю в сокет, в другом читаю - понятно. Я не нашел решения, как сделать ассинхронный io для пайпа и событийно читать/писать в него

ну, можно попробовать дочитать, а потом уже начать писать, но это не точно

ну, можно попробовать дочитать, а потом уже начать писать, но это не точно

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

возможно, стоит начать с чего-то попроще? просто писать в stdin и читать из команды? так может и тесты появятся, потом читателя от писателя удастся вычленить, проверить с каждый стороны, а там уже и до клиента и сервера дойдет

Отдельно читать и писать в cmd я погу, в сокет тоже. Вокруг текущей логики есть обвязка, оно все работает. Не работает конкретно свзять cmd с сокетом. Да и даже дело в сокете. Блок происходит на 47-49 строке. Причем комментирование 49-й не помогает

То есть, основная проблема в том, что блокируется процесс, который читает cmd. но почему он блочит - я не понимаю

https://play.golang.org/p/tB7U04txSEx

У тебя код читает 1-ю строку, ты ее и видишь. Чо не так?

Я бы с удовольствием, просто пока непонятно на что переписывать :)

В этом примере - все.

https://play.golang.org/p/tB7U04txSEx

Косяк самый большой в 32-й строке

У тебя код читает 1-ю строку, ты ее и видишь. Чо не так?

Почему одну, он в цикле читает. Должен все вывести

Косяк самый большой в 32-й строке

наверное на 33-й? Да, это гавнецо, уже переделываю на каналы

shell.Run - выполняет команду и закрывается

На момент получения второй строки у тебя процесс уже мертв

Привет всем у кого есть книга Go на практике

А у тебя бесконечный цикл

Привет всем у кого есть книга Go на практике

У всех, кому не лень, вроде

На момент получения второй строки у тебя процесс уже мертв

Почему мертв, cmd должен работать пока ему exit не отправишь

в интерактивном режиме

Почему мертв, cmd должен работать пока ему exit не отправишь

cmd.Run - нет