Hi Guys,

Once upon a time, in a magic computer, a lovely virtual princess was waiting in 
a cooperative process for a strong and handsome virtual prince to awake her... 
Unfortunately, the prince was a cooperative one and he was waiting for the door 
to open, and the key was held by the princess... 

Do you like Fairy Tales?

Here is another one, from Goethe: Once upon a time, an old sorcerer departed 
his workshop, leaving his apprentice with programs to execute. Tired of waiting 
tasks waiting in queue to access one of the 4 CPUs of his computer, the 
apprentice enchanted a virtual machine to do the work, using preemptive 
programming in which he was not fully trained. The apprentice soon realised 
that he couldn't control the tasks because he did not know the magic required 
to do so. The apprentice began to split the CPU in two with a magic mouse, but 
each of the pieces becomes a whole CPU that was splitting again and again in 
the virtual space, until the power supply became red hot!  When all seemed 
lost, the old sorcerer returned and quickly reduced the number of preemptive 
tasks to a more reasonable number! 

Do you believe it? If you have been assisting to the training day I gave during 
the 2019 Tour, you remember that we have discussed about that, and we have seen 
examples on the practical use of preemptive workers, the use of the Signal 
object, how to handle this typical Catch-22 situation, etc. We have also seen 
that the preemptive multithreading was useful to gain speed only in some very 
very specific cases (Remember the demo K_PreemptiveVsCooperative)

Sorry for those of you who still believe in him, but Santa doesn't exist. 
Virtual cores are NOT actual cores. And even if you get zillions of cores, 
there is still only ONE bus to access to memory. So, don't dream, multiplying 
the number of cores will NOT multiply the speed of every database operations. I 
mean, it will not be slower, but (cores * 8) ≠ (speed * 8). And this is even 
much more true in case of hyper threading. And obviously even much much moe 
true in case of a VM.

So let's try to be crystal clear:

> So what you are saying is that if you are deploying 4D Server in a VM there 
> is not need to try and use preemptive mode. You get no benefit from doing 
> that. It’s a waste of time?
Wrong. It will be a benefit in terms of speed, even not as large as you dream, 
because the system will optimise the use of each possible core. And a benefit 
in term of smoothness of execution, because no process will freeze the others.

> The whole benefit of preemptive mode is to allow 4D to assign a process to a 
> core.
Wrong. What I explained is that 4D does NOT assign a process to a core, but 
assigns a process to a THREAD, and the System assigns cores to Threads. The 
same Thread can be switched from core to core by the System, you don't even 
have to know.

> But in the case of a VM the actual, physical cores are managed by the VM.
Wrong. The VM talks to the System, and the System manages cores. In fact, just 
imagine that a machine can run several VM at the same time.

If you have been at the 2019 Tour, remember J_OtherObjects example, where I 
show that if you use cooperative processes, with one executing an excruciating 
method, then the Forms on use are kind of frozen. Then, by switching to 
preemptive mode, the same awfully blocking method doesn't impact on interface 
while running. 

So please, don't mix Processes, Threads, and Cores. Preemptive programming is a 
real plus from many points of view, including it helps 4D to optimise it's own 
internal optimisation processing. And also, remember that Preemptive 
programming is like food, it's necessary, but stay reasonable...

Regarding the other question:
> Yes, you're correct, currently the move from binary to Project format is one 
> way, whether this will become bi-directional I don't know.

> This was asked to JPR at the last 4D World Tour show and his response was 
> “why would you want to do that?” And then he proceeded to explain that to 
> implement a feature like that would require many hours of engineering time, 
> and QA time and then it would have to be maintained into the future. 
> So he said are no plans for a “project folder back to a single .4DB file” 
> feature. Only way to have the happen is to convince 4D it is a needed and 
> necessary feature. 
Thank you, Tim, it's exactly what I said (plus the accent) and it's still the 
current status.

> But, I still need to fully understand exactly why 4D is not eliminating the 
> interpreted structure binary .4DB file completely at this time? Maybe 4D plan 
> to do so eventually? Was this question asked at the last tour? If we are 
> given the Project feature then we should be all in and have no option but to 
> embrace it and source code repos such as Git, since, pretty much every other 
> programming language is doing it this way.
AFAIK, if you use the Project mode, you don't need any binary, for everything 
is in text files (.json, .xml, .txt, .4DProject, .css, . 4DCatalog , .4dm, 
.4DForm, etc.) The .4DB is not necessary.

My very best,

4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to