Node, почему есть ограничение однопоточности?

Question

[Сергей Алексеев]

Добрый день, можете объяснить почему нода однопоточная, почему она не многопоточная?

Answer 1

[Андрей]

v8 однопоточный. Кластеризацию можно делать ноды.

Node cluster

Comments

[Сергей Горностаев]

А почему он однопоточный?

[Andrey Tsvetkov]

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

[youngmysteriouslight]

Сергей Горностаев, Как работает JS: обзор движка, механизмов времени ...
В начале каждого раздела есть краткое описание причин текущего положения дел. Прочтите их, если не хочется всю статью целиком читать.

[Сергей Горностаев]

youngmysteriouslight, думаю, что-то вроде этого автор вопроса и ожидал получить в ответе.

[Сергей Горностаев]

Andrey Tsvetkov, на месте автора я бы задал вопрос "А почему Java, Erlang и Go, например, смогли решить эти проблемы, а Node нет."

[Andrey Tsvetkov]

А почему Java, Erlang и Go, например, смогли решить эти проблемы, а Node нет

для GO не рекомендуется использовать многопоточность и рекомендуют выставлять GOMAXPROCS в единицу. Если этого не делать, то есть большая вероятность замедлить приложение.

[rustler2000]

Andrey Tsvetkov, а можно узнать источник сего бреда?

[Andrey Tsvetkov]

rustler2000, к чему источники? вы после начнёте оспаривать авторитетность источника или ещё чего-нибудь. Просто возьмите и напишите тест, в котором задействуйте главную киллер-фичу GO - каналы. И испытайте с разными значениями GOMAXPROCS.
Если сами не осилите написать, то можете использовать код моего теста:

spoiler

package main

import (
	"runtime"
	"time"
	"sync"
	"fmt"
)

func main() {
	runtime.GOMAXPROCS(1)
	start := time.Now()
	ch := make(chan bool, 10)
	wg := sync.WaitGroup{}
	for n := 0; n < 10; n++ {
		go func(ch <- chan bool, wg *sync.WaitGroup) {
			wg.Add(1)
			for _ = range ch {

			}
			wg.Done()
		}(ch, &wg)
	}
	for i := 0; i < 1e8; i++ {
		ch <- true
	}
	close(ch)
	wg.Wait()
	fmt.Println(time.Since(start))
}

[rustler2000]

Andrey Tsvetkov, но этоже даже не тест - вы делает spmc на одной не lock free queue и ожидаете что оно будет горизонтально масштабироваться без потерь на разные физические ядра? может вы еще ожидаете что читающие горутины в данном случае равное количество чтений произведут?

[stratosmi]

Andrey Tsvetkov,

на месте автора я бы задал вопрос "А почему Java, Erlang и Go, например, смогли решить эти проблемы, а Node нет."

Потому что сразу были спроектированы с расчетом на это.
И развивались с расчетом на это.

[stratosmi]

Andrey Tsvetkov,

для GO не рекомендуется использовать многопоточность и рекомендуют выставлять GOMAXPROCS в единицу. Если этого не делать, то есть большая вероятность замедлить приложение.

Да, во времена версии то ли 1.0, то ли 1.1.
Сейчас актуальна версия 1.10.
И много что в корне переделано в Go.
Одно из последний в серии этих переделок - в версии 1.5 ( это было 3 года назад ). Одна из сложнейших для многопоточности частей - сборка мусора - в корне переделана и сейчас прекрасно держит множество потоков на большой нагрузке и даже без фриза.

[stratosmi]

Andrey Tsvetkov,

Если сами не осилите написать, то можете использовать код моего теста

Хе-хе.
Ваш тест только и делает, что синхронизирует потоки. И на этом и тормозится.
Он синтетический.
В реальной жизни потоки независимо делают нечто более-менее объемное. И лишь иногда синхронизируются.