OSDev.org

Hi!
I want to describe my idea which can make operating system more safety, stable and efficacy. I thnik about artificial intelligence. Of course not about chatterbots like ALICE, but about neural networks and similar gadgets.
Neural network can be used in schedluer. It will be able to decide how to run process including informations about number of activated processes, speed of CPU, and type of program (for example program which have an access to tty0 will be run for short time but often).
Expert system can be used in odd situations. For example if exception occurs system will do the best solution. If it slove problem it will get a point. The best solution is chosen using this points. In very strange situations system can use genetics algorithm. Solution will evolve and the best will be chosen. But possibility of checking which solution is the best will be needed.

Of course it is not all. But I only want to bring closer my idea. I'm waiting for opinions.

One of the things that people get most frustrated about when using a computer is not knowing why it is doing something. My concern is that using AI to control fundemental aspects of the OS will make learning and predicting how the system will react much more hard.
It is definately an interesting train of though however. I guess for the sake of robustness you can always fall back on standard methods should your AI encounter problems. Allthough another concern is speed, just what kind of speed impact will a much more costly algorythm entail? Im sceptical as to whether the pros will out way the cons.
One area that i could forsee usefull outcomings is in computer networking. Computers could constantly refine data paths, caches, bandwidth, ect.

I think I will take more time to think this over and come up with some more positive things. Way to think outside the box though

I refuse to use a computer that has more personality than I do.

Well, I think for the special case of scheduling, a neural network will use a lot more cycles then it could save.

I hink it would be a good idea to add Ai functions to an O.s. let me know how it goes if you do it.

Legend wrote:Well, I think for the special case of scheduling, a neural network will use a lot more cycles then it could save.

Yes, neural network is slower than standard algorithms. However, it will better organize CPU time. For example when each proces runs for (for example) 10 ms, and we have 100 processes user will wait up to 1 second when he press a key to time when computer will react. But, when neural network will organize the cpu time, process which communicate with user using tty0 will react faster, because it will be activated often but for short time. I think that short time of reaction is more important. (of course if it will work well).

One of the things that people get most frustrated about when using a computer is not knowing why it is doing something. My concern is that using AI to control fundemental aspects of the OS will make learning and predicting how the system will react much more hard.

If system is really good you won''t think how it work.

Hery Sasta wrote:

Legend wrote:Well, I think for the special case of scheduling, a neural network will use a lot more cycles then it could save.

Yes, neural network is slower than standard algorithms. However, it will better organize CPU time. For example when each proces runs for (for example) 10 ms, and we have 100 processes user will wait up to 1 second when he press a key to time when computer will react. But, when neural network will organize the cpu time, process which communicate with user using tty0 will react faster, because it will be activated often but for short time. I think that short time of reaction is more important. (of course if it will work well).

That behaviour can be avoided easily without using a neural network. Any dumb scheduler that knows about priorities can do this.

Yes, but a neural network will also use seed od CPU and number of working processes to make a decision. So if CPU is slow and there is many processes, each proces will be activated for shorter time but more often. You said that it will be slow. Of course it will be slower than small algorithm which chooses next process and runs it for (for example) 10 ms. But if you compare neural network and more advanced schedluing algorithms. Neural network will be faster. Of course I won't write function that count the value of neutrons in C but in asm. When I will have implmented I will show you difference of lenght of my standard (very simply) algorithm and a neural network.
You can everything write without using artificial intelligence, but sometimes it won't be so efficent.

Hery Sasta wrote:But if you compare neural network and more advanced schedluing algorithms. Neural network will be faster.

I'll be surprised if anyone manages to do achieve this.

Of course I won't write function that count the value of neutrons in C but in asm.

So? I think the difference between a C neural network and ASM neural network will pale when compared to the difference I expect from a ASM neural network to a normal scheduler written in C.

You can everything write without using artificial intelligence, but sometimes it won't be so efficent.

I have to admit, I see AI as an option to improve user interfaces.

So? I think the difference between a C neural network and ASM neural network will pale when compared to the difference I expect from a ASM neural network to a normal scheduler written in C.

So, you think that code in asm is not faster and more efficent than code in C?? Congratulations

Hery Sasta wrote:

So? I think the difference between a C neural network and ASM neural network will pale when compared to the difference I expect from a ASM neural network to a normal scheduler written in C.

So, you think that code in asm is not faster and more efficent than code in C?? Congratulations

By far not the orders of magnitudes of cycles that the neural network will likely use more if you implement it with enough neurons to decide anything useful.

30% more Speed with ASM over C is already very optimistic today. The age of "I implement it in asm and it will be fast" was never that dramatic as it was often described (algorithms always have been more important) and with modern C compilers it fades anyway ...

This is like you implement Bubble Sort in ASM and I implement Heapsort, Mergesort or Quicksort in C - which one will be faster if we sort more then a few dozen items?

Hery Sasta wrote:So, you think that code in asm is not faster and more efficent than code in C?? Congratulations

Ideally, it should be. Realistically, most ASM programming is still done on already existing Operating Systems, which mostly rely on API Calls designed in C. What's more, is that bad programming concepts are bad programming concepts no matter what programming language is used.

So it is like you being a very fast person and some other very slow person arriving to the post office at the same time. You both are the same distance from the door when you notice each other, but you sprint to the door while the other walks. You get there very quick (5-10 seconds) while the other takes a little more time (30 seconds). You come to find out all that extra effort is pointless because you both are standing in line for 30 minutes anyhow. Note that this just emphasizes the speed factor and not the size part of efficiency game (i.e. how fast you would conduct your business at the post office counter).

Hand optimized code generated by Assembly Language experts on the x86 series of computers is *still* a place where the battle can be won. By "won", I mean hands-down, no competition and not a chance to compare. With heavy movement to RISC-based architectures, it is becoming a more futile battle with every new CPU generation.

However, if you can find yourself to be able to conceptualize and crank-out ASM code faster than the equivalent C code (like myself), that is where you break the whole "production futility" barrier and it becomes an important point to consider... either that or you need to get better at C

Legend wrote: This is like you implement Bubble Sort in ASM and I implement Heapsort, Mergesort or Quicksort in C - which one will be faster if we sort more then a few dozen items?

That is like saying I have a durable hand-crafted wrench and you have a production-line ratchet. Which do you think would be faster when asked to replace X amount of bolts in various enclosed spaces? This has to be the most common fallacy I see amongst HLL coders. First, find/design the right tool for the right job, then make it as best you can.

If you were to compare a Bubble Sort algo written in ASM with one written in C, then you would be accurately comparing the efficiency of production and code speed/size between the two programming languages.

To side with you a bit, 5-20 iterations of a particular algorithm won't find you much difference, and most people find themselves in that situation. However, boost that amount up into the thousands per second, like say Memory/Process Management algorithms, and you'll start to notice a difference

Which brings me to the most crucial point of Assembly Language in OS Dev. If you want to make your point as to why ASM should be used, concentrate on those ISR's and other constantly called routines system routines

SpooK wrote:If you were to compare a Bubble Sort algo written in ASM with one written in C, then you would be accurately comparing the efficiency of production and code speed/size between the two programming languages.

Yes, I know, but I saw often enough that relying on implementing something in ASM and expecting automagically a lot of speed comes along with a missing knowledge in algorithms. This is why I make exactly the comparision with the better algorithm in C and the worse one in ASM to point out that the language is not that important and can't fix a slow algorithm.

Which brings me to the most crucial point of Assembly Language in OS Dev. If you want to make your point as to why ASM should be used, concentrate on those ISR's and other constantly called routines system routines

That makes sense, yes, of course. Classify everything as regularly called and not regularly called (for example init code).

SpooK wrote:Which brings me to the most crucial point of Assembly Language in OS Dev. If you want to make your point as to why ASM should be used, concentrate on those ISR's and other constantly called routines system routines

This may sound like a dirty hack, and in some ways it is, but because they only differed by a few bytes, I created the ISRs at boot within a C static char array, no assembly involved. Worked great. So, you don't need assembly for even this.

Legend wrote:By far not the orders of magnitudes of cycles that the neural network will likely use more if you implement it with enough neurons to decide anything useful.

Of course I will try to minimize number of neutrons. If hidden layer is not needed I won't use it. (One neutron also can be called "neural network").

30% more Speed with ASM over C is already very optimistic today. The age of "I implement it in asm and it will be fast" was never that dramatic as it was often described (algorithms always have been more important) and with modern C compilers it fades anyway ...

I think that 20% is a lot.

My idea has at least one big disadvantage (speed). I think that discussion about it makes not sense until I implement neural network in my schedluer and check how long it takes to make a decision.