Hi,
we have some performance issues with Glorp over P3 and, after some
investigation, I have a theory that could explain it. And I would like to
know your opinion if it is correct.
To reproduce this issue, you can try something easy. Just create a process
with normal or higher priority that will try to read something from a
socket. And, in parallel, do in a separate thread an operation that takes
all the processor time for several seconds.
````
[
5 seconds wait.
Time now traceCr.
ZnClient new
url: 'https://www.google.com';
get.
Time now traceCr.
] forkAt: 60.
[1000 timesRepeat: [ 10000 factorial ] ] timeToRun
````
(you may try a different safe server address)
The processes run in parallel until the time when the first process tries
to obtain data from the socket. Then it hangs and waits until finishing of
the second process.
My theory is that the VM socket plugin is able to receive incoming data
from the connection and save it into the buffer. In the meantime, the
reading process is waiting on the socket semaphore. But it looks like the
plugin is not able to release the semaphore while the VM is actually doing
something. It needs to wait until the VM has nothing useful to do, and then
it is finally able to release the semaphores so Pharo processes are resumed
and can start to read.
Is my theory right?
Cheers,
-- Pavel
Hello,
Although i will not be able to attend ESUG'22, a friend agreed to
present one of our projects to the innovation award.
**Polyphemus** is a VM related, but public aims at any kind of developers.
Particularly, the video submission talks about how to look at an image
and how to **recover** dead images.
Feel free to contact me if you have any questions !
Enjoy (and vote for Polyphemus!).
5 minutes video, Innovation Technology Award submission:
https://youtu.be/zf3cCtNW830
Repository: github.com/hogoww/Polyphemus/
Additionnal information on image recovery:
https://github.com/hogoww/Polyphemus/blob/main/Documentation/ResurrectingDe…
Cheers !
Hi:
I have a novel idea "Digital Twin applied to Software". See attached slides.
It points to the future of improved programming productivity and
reliability.
Let me know what you think.
Thanks,
Aik-Siong Koh
http://ar-cad.com
Abstract
Digital Twin applied to Software
Aik-Siong Koh
askoh.com
There has been a major dichotomy in computing right from the beginning:
Statically Typed vs Dynamically Typed programming languages. The former
languages produce fast executables but are inflexible to program. The
latter are just the converse. This dichotomy has been frustrating to
programmers who always feel they have to make sacrifices when making a
choice. It also often leads to futile language wars. The Digital Twin
concept was introduced in engineering where a physical system is modeled
digitally in geometry, simulation and other information. The concept has
proven so successful that it is being applied to almost everything in
engineering from simple mouse traps to complex whole cities. It occurred
to the author that this concept can be extended to software too. For
example, execution in C++ is famously fast. But development in C++ is
notoriously difficulty because of language complexity and long build
times. A flexible digital twin can be a program written in Smalltalk
which is famous for live programming. "Development at the speed of
thought" is the motto and is real. What is gained by this duplication?
Firstly, the flexible twin can be use to explore new algorithms,
features, solutions and fix bugs quickly. Only desired codes are
translated to C++ manually or automatically. Secondly, the two programs
can check each other so that bugs are reduced significantly. These two
gains will define future programming productivity and quality. The
Digital Twin concept will also drive the automatic translation of the
flexible language to the fast language.
Bio
Dr Aik-Siong Koh has a PhD from The University of Texas at Austin where
he programed in FORTRAN to simulation mechanical systems. While teaching
at Texas Tech University and Nanyang Technological University, he
developed interest in Multibody Dynamics. To develop his own Multibody
Dynamics simulator, he researched for the most productive programming
language and discovered Smalltalk. The live programming capabilities of
Smalltalk permitted him to build a successful simulator which he then
proceeded to commercialize. His later experience with C++ at Mechanical
Dynamics and MathWorks gave him the idea of Digital Twin for Software.
The inspectors for blocks are now a bit improved:
1) CompiledBlock. This now is more in sync with CompiledMethod and shows
- the homew method code with the block highlighted
- the AST of the block
- the IR if the block
Currently, we compile every non-optimized block to a full block that created by a bytecode from a CompiledBlock (which
itself is stored as a literal).
inspect âCompiledBlock allInstancesâ to see the new inspector:
2) BlockClosure itself, e.g inspect some block in the workspace. This gets more important as we soon will have pre-compiled
subclasses of BlockClosure as method literals (and then just execute pushLiteral: to âcreateâ the block).
A nice way to play with these is:
CompilationContext optionConstantBlockClosure: true.
OpalCompiler recompileAll.
some 2500 of the blocks are now compiled statically.
Inspect:
ConstantBlockClosure allSubInstances
The inspector shows the same (home method with highlight, IR, AST)
But we can do even better:
CompilationContext optionCleanBlockClosure: true.
OpalCompiler recompileAll.
Another 7500 blocks can be statically compiled, inspect
CleanBlockClosure allInstances
These are not yet the default, as we have to carefully analyse the places where we now assume that blocks know the outerContext
and receiver. (in the example above you see one of these: Announcementsâ¦).
You can follow these issues to see what still needs to be done:
[Meta] Steps needed for ConstantBlocks #11933
https://github.com/pharo-project/pharo/issues/11933
[Meta] Steps needed for CleanBlocks #11195
https://github.com/pharo-project/pharo/issues/11195
Marcus
