OSDev.org

devc1 wrote:But whatever I had never tried to understand what is this hashmap. I just create linked lists

This proves my point. You are looking for performance at the micro level, which is the last place performance should be found at. You should first think about basic algorithms. A hashmap will beat a linked list in lookup intensive operations always. Now is a hashmap always faster? No. It's about using the simplest thing that will give you the best performance.

devc1 wrote:but I would want to optimize the Schedule(), malloc() and free()

In those cases, don't optimized code, optimize the algorithm and then the code.

vvaltchev wrote:Then, people start to do benchmarks and look for "low-hanging fruits" to optimize. That's way too late.

Yeah, that's a big problem these days.

My personal philosophy about performance is that instead of "premature optimization is the root of all evil", premature micro-optimization is the root of a lot of evil.

devc1 wrote:I don't (...) know why Windows, languages such as python, and companies are making all these huge and vast performance losses.

Python is actually pretty fast and more than acceptable for some (e.g., I/O bound) applications. I do agree that Python is overused, however.

devc1 wrote:You have a (...) multi-core 4000000000 GHz CPU powered with the latest SIMD technologies and you still can't make fast applications.

You need to know that CPU performance isn't nearly as significant in many applications these days as it was before. Most tasks (such as a web server, a web browser, and other things) are actually I/O bound, meaning that the CPU spends most of its time idle and most time is spent waiting around for memory or the disk, which is significantly slower than CPU. Judicious use of disk and memory is key to fast applications these days. Of course some application's performance is bound by the graphics card (3D rendering, video editors, video games) and others are still CPU-bound (primarily software compilation and scientific number crunching, but even the latter is being moved to GPUs. Look up GPGPU). But most of the time, the disk and memory is the bottleneck.

For info on judicious use of memory, look at this research paper:

https://people.freebsd.org/~lstewart/ar ... memory.pdf

P.S. Mods, could you please split off this discussion?

optimize the algorithm and then the code.

That's what linked lists with the "bsf" (Bit Scan Forward) instruction do. Instead of looping on items, a simple 64 bit bitmap and the bsf instruction will simply sort a present entry. Such as pages, heaps...

In those cases, don't optimized code, optimize the algorithm and then the code.

You're absolutely right.

For info on judicious use of memory, look at this research paper

I already discovered it my self, I maximally try to minimize memory accesses in registers, using these methods my Scheduler was able to record a 5us per task switch on a pretty old laptop.

Devc1,

devc1 wrote: I already discovered it my self, I maximally try to minimize memory accesses in registers, using these methods my Scheduler was able to record a 5us per task switch on a pretty old laptop.

That is not very fast at all. My barely optimized scheduler, in a microbenchmark, achieves 6µs in QEMU, 3µs on a laptop from 2013 and 7µs from 2012.

This post from 2006 measured context-switch times of an old Linux kernel on various CPUs. The fastest among them has a switch time of 0.89µs

This paper shows that the original L4 kernel achieved a 0.75µs context-switch time in 1997. Modern kernels apparently reduce this to 0.09µs on 32-bit x86.

Even if it's a preemptive multiple-priority based scheduler ?
the laptop I am testing it on is from 2008 : ))

But you're right, my new 64-bit scheduler is just garbage. Because my algorithm seems not right, I'll learn more on these priority based scheduling algorithms.

Guys, it looks to me you're mixing up the time consumed by the scheduler to make a decision with the context-switch time. Those things are very different: the context-switch time is the time it requires to switch to the next task (save and store all the registers, page directory etc.), assuming that we already know exactly which one the next task will be. The time consumed by the scheduler to make the decision about which will be the next is a completely different thing.

What’s this discussion got to do with what anyone’s OS looks like?

iansjack wrote:What’s this discussion got to do with what anyone’s OS looks like?

Nothing at all. Actually, we even asked if a moderator could move the discussion to a dedicated topic as it was good per se. I know we shouldn't continue it here but you know... one comment leads to another and so on.

Paused all my kernel development to Fight with 2D Algebra : )

- bezier curve connected with 4 points (in red), the gaps will be filled with LineTo() function.
- Rasterized shape (in blue)

Seems like next technology isn't it ?
An innovation in the design of OSes haha,

Symbolic debugging, and playing with 3D on an Intel 82845G GPU for which I can't find the manual. Fun fact, commands with errors cause the GPU to freeze and I haven't found a way to clear the error without resetting.

Loading programs from the disk and running them in user mode + process/thread garbage collector thread + programs can finally crash and terminate without bringing the whole system down.
I also implemented exiting so programs no longer execute garbage after their execution is done.
Working on argument passing, ELF support, synchronization primitives and virtual 8086 threads as we speak...

Lately I fixed many, many terrible kernel bugs; improved overall performance and worked on some UI components like scrollable areas and layouting.

Your UI looks great, max!

I've ported Skia to my OS, but using identical logic, so my UI still looks the same.

AndrewAPrice wrote:Your UI looks great, max!

Thanks! Did a little fine-tuning but mostly I've been working on the interface that other processes use to create/control components, still a lot to do

Xorg (or rather, Kdrive/Xfbdev) running on my OS, hosting TWM.

Peterbjornx wrote: Xorg (or rather, Kdrive/Xfbdev) running on my OS, hosting TWM.

That wallpaper is burning my eyes But awesome to see something like Xorg running. How big are the requirements for that?