This is a creation in Article, where the information may have evolved or changed.
I
Lua,erlang,go The language of this process, or so-called lightweight "processes", though they make the execution of the program controllable, if they open 1000 threads at a time, they can actually run only 1 threads at once, and they don't take advantage of multicore. Suppose: let these languages be compared to Java with a real threading concept that leverages multicore CPUs. If you deal with 1000 tasks at a time because the first few languages do not utilize multicore CPUs, will processing speed be much slower than Java? How to understand this.
Looking for a lot of information, they only introduced: the process of Lua or Erlang, just to let the program become controllable this advantage, but did not introduce: if this is not the real "threading" language to handle the task, whether it will handle the slow and so on.
You can look at the LUA source code, such as the LUA process, and I can find the thread that lua_newthread this implementation, actually using the stack to implement.
And: Cloud wind skynet this server-side framework, using the Actor model, which is mainly used in the process, the actual development, and did not I say that the problem. So I want to know: What I understand is wrong.
There's a bug called Design so 12:55:05
What's your question?
There's a bug called Design so 12:57:10
You can't take advantage of multiple resources, right?
There's a bug called Design so 12:58:08
The simplest to write a program to try to know, the process of writing a dead loop to see, can you run the CPU to 100%
Lukey 13:01:41
I'm just using go.
Lukey 13:01:45
Really good.
Wang Zhe trumpet 13:02:20
LUA's "co-process" is not a thread, after all, the 1000 must be sequential execution, strictly speaking, it is executed in a certain thread environment, eliminate its own consumption, it consumes another part in the management of these processes and code jumps, as to whether the use of multi-core, Depending on the upper-level language, the performance of the thread can be distributed to multicore.
Wang Zhe trumpet 13:03:21
Golang at the beginning of the design is multi-core, so the setting of the upper language for the multi-core environment, many things in the Golang for multi-core has been specifically optimized.
Wave 13:07:03
What I want to ask is ... You're struggling with Ctrip's use of multicore, what are you doing?
Wang Zhe trumpet 13:07:42
This is something that needs to be considered at the language design level.
There's a bug called Design so 13:08:06
Logically, you need to think about it.
Wang Zhe trumpet 13:08:07
Have not yet seen which language also requires you to manually consider the multi-core
Wang Zhe trumpet 13:08:24
Like what?
There's a bug called Design so 13:08:56
At least know when to use the process, when to use the thread, and when to use the association.
Wave 13:09:35
You don't even know that.
Wang Zhe trumpet 13:09:49
This I think more of the program performance above the Thing
Wang Zhe trumpet 13:09:57
Rather than considering multicore
Wang Zhe trumpet 13:10:25
One problem is not only one solution, we want the optimal solution
There's a bug called Design so 13:10:45
If you don't know whether a language's association can be assigned to multicore processing, it's even those who don't know.
Wang Zhe trumpet 13:10:48
Process, thread this solution is not optimal, I think there is some room for discussion
There's a bug called Design so 13:18:28
One LUA VM corresponds to an OS thread
There's a bug called Design so 13:18:49
Skynet should be a multi-core resource used by multiple LUA VMS
Beijing | Arrears 13:32:23
Do you use multicore compilers to consider it? You have no meaning in the language level.
There's a bug called Design so 13:41:23
I think that whether it is the editor language level, or the framework level, or the logical level, you need to consider, in order to write a good program