|
Member 14968771 wrote: is OS multitasking thing of the past ?
No, but it does require you to write efficient multitasking code. Yet another subject for you to apply your energies towards learning.
|
|
|
|
|
I had my education in the ages when 'timesharing' was something new.
Our textbooks tried to make us believe that it let you behave as if you had an entire machine to ourselves.
All us IT students insisted that timesharing was what made you realize that you did not have the machine to yourself.
|
|
|
|
|
Ubuntu now using VB6 for source. Use Debian.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
theoldfool wrote: Ubuntu now using VB6 for source. Use Debian.
I understand the joke you were making, but...Ubuntu is based on Debian.
|
|
|
|
|
True, Ubuntu took Debian and "improved it", I think Microsoft helped them.
I rest my case. 
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
theoldfool wrote: I think Microsoft helped them
|
|
|
|
|
You'll have to get rid of any I/O if you want 100% CPU.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Member 14968771 wrote: What makes the CPU to run 100% or more ? Assembly language ??
Ultimately, yes, sorta, kinda, maybe, in that everything eventually gets down to machine code. Even things running in a JVM or CLI environment have to, at some point, run on the host CPU.
But that's a lot of overhead, especially if you're seeing it constantly. I'm looking at my Ubuntu 21.10 VmWare instance with 2 CPU and 2 G of ram and top shows 99.7 % idle. I am using about 1.0 G of ram, but 600MB of that is buffered/cache so it's essentially available for program use. That's with the system otherwise idle - only a single GUI login and a terminal running top.
What tools are you using to get your CPU usage? Maybe take a look at atop or glances, both of which provide more detail than top or htop.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Ah well then. You know what they say about a poor workman and his tools ...
Keep Calm and Carry On
|
|
|
|
|
Your code may, directly or indirectly, require access to some common resource that is, for synchronization purposes, locked by some other process, so you have to wait for that other process to release it.
It is not uncommon that processes hold onto their resources for a long time. Ages ago, I was working on an OS (not "*nix-like") that for any write operation required the process to reserve the file system root, i.e. the entire file system. Only a single file write could be active at any one time (!).
In database systems, you frequently see programs locking entire tables (or even the entire database!) while they are doing all their processing, which may take a long time. Some database systems doesn't give you any other option than locking tables, so software ported from systems offering tuple/predicate locking may cause terrible performance with other database systems (until applications are rewritten to do their work without keeping tables locked).
Obviously, the same goes for other system resources. Some software put locks on I/O devices, system data structures (note: 'system' doesn't necessarily mean 'operating system'!) etc. far beyond the actual time they need it.
You may empathize with these developers, "sort of". Only sort of. It is convenient reserving everything you need beforehand, so that you can be sure it is all available, perform all your operations on all your resources, and then release everything. First, you keep your operations code free of any resource management code. Second, you are relieved of the analysis job of determining when you really need the different resources. Third: You avoid the problem of getting halfway in your work, and then having to handle the situation that you have to wait for some resource to become available.
There are lots of code out there that is rather 'uneconomical' in their occupation of common resources. I do suspect that other applications, utilities, demons, servers, whatever ... more commonly is to blame than the OS. If you are competing with others for shared resources, you will have the same competition even if you code in assembler. A purely CPU-consuming application will run at full speed. However, what you believe is a 'purely CPU-consuming application' may at closer inspection turn out to not be.
|
|
|
|
|
|
Ugh.
I despise Disney as a corporate entity. Never mind they entertainment they produce (and I use that term loosely), it's all about selling crappy plastic merchandise to those who cannot make a rational purchasing decision.
The Disney-branded Visa cards at the bottom of that page made me vomit in my mouth a little. 
|
|
|
|
|
|
|
i have yet to understand StarLink business model . is it not much more expensive than that which we receive from terrestrial sources . as i have read it explained it is intended for those who presently do not have internet access . it is my assumption those w/o such access are of low economic means so good luck Elon . 10,000 satellites amazing . is this as crazy as colonizing Mars . thanx for suggesting the video i found it enlightening
|
|
|
|
|
It is meant for people who do not have access to high speed Internet, can you say dial-up? Many of those people have the means.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
For example, all the shipping (from container vessels to yachts) and all air traffic starve for fast reliable internet. Some of them are now paying hundreds of thousands of dollars annually for a slow connection.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Wow! So much info! Amazing video 
|
|
|
|
|
I heard the SQL is better.
I'm sorry
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
 Punished again.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
What base joke!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Single Step Debugger wrote: I'm sorry
And so you should be. I hope you plan to explain yourself, or we'll need to terminate this relationship.
|
|
|
|
|
I can't believe I SELECTed that.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
