Haiku is not lightweight!

There is a difference about how much is took after boot and how much is needed to run it. A good OS should always use 100% of it’s RAM the same way it should use 100% of it’s bus usage and clock speed if that help to compute faster. The problem arise when it waste the RAM. Does Haiku waste right now, surely as it was never seriously optimized as far as i know. I don’t think it will be 64M like R5 was because it just is more than R5 but i hope 128M will be more possible than the current requirement.

I think if haiku was wrote from scratch without the current disease that plague all OS, called libraries, and lower the place where OO is used to a strict minimum it could be made at around 8M requirement (if you ignore the web browser from this).

For me lightweight is QNX demo disk or Amiga OS, contiki etc… I don’t even rate WindowCE as lightweight.

Haiku has surpassed BeOS in quite a few areas

In addition to that, two extra points:

  • Haiku is still in beta and our approach is to make things work first, and optimize later. So, we could reduce the RAM usage, however…
  • BeOS was designed 25-20 years ago, at a time were RAM was limited. They had to make compromises which make no sense today. What’s the point in making the OS fit in 32MB? Do people seriously intend to run it on machines with 32MB of RAM? Certainly not. While 250MB is maybe larger than we’d like, it’s reasonable to assume anyone running Haiku has at least 512MB of RAM installed (that’s what I had in the first computer I assembled for myself in 2003, and it was built on a budget out of pocket money given by my parents and spared over a year or two, so it was far from the best configuration available at the time already).

So, we have different priorities. There is no point in optimizing Haiku to run with less than, say, 128MB. That will not enable more users. That will not enable a lot of existing users to do more with their computers. So, we have different priorities, and 250MB in the current state (of a beta version with few optimizations) is reasonable.

Also, note that the memory usage decreases a bit on machines with less RAM (or increases with more RAM). That’s a known issue due to inefficient management of free RAM (yes, we need some RAM to store data about the other parts of the RAM). And that is just one single example of things that can be optimized.

5 Likes

All this discussion reminds me of my first BeOS workstation for the 3.0.
Dual pentium-II 266 MHz, Asus P2B-DS motherboard, 4.7 GB hard drive, 256 MB of ram and Ati 128 pro.
Good old time.
Nowadays a Raspberry Pi 4 does not come with less than 2 GB of memory, that’s plenty for Haiku.

There’s a bit of over-reaction for most platforms when people use rose tinted glasses to look at memory usage. A 1920x1080@24 bit colour depth display needs 8Mb of Dram just for a single frame buffer, we dont run 8x8 pixel bitmap fonts no more, we dont display 32x32 pixel icons no more, each 4kb memory page needs to be tracked (therefore a 16Gb computer has 4 million such pages, so even at 32 bytes per page the system needs 128Mb to track that), each disk storage block needs to be tracked and cached, each thread and semaphore needs to be tracked, etc. My first BeOS 4.5 Intel box in 1999 had 512Mb of RAM, and supported much less then, than what Haiku supports today in 512Mb. It’s lean.

3 Likes

May be stressed to death. I have created a mess by forcing Haiku to be the way I want. The fact is they want to be their way and will continue to be their way and focus on developing Web+ only. I want PaleMoon but they don’t want. I can’t force them to work with the PaleMoon community since they don’t want to. That only caused more distant between the two community without got the porting of PaleMoon come true. I’m too tired indeed. I will just back to OpenIndiana which I found comfort with and left Haiku. Please remove this account.

1 Like

I remember running BeOS R4 on a Pentium I machine with 16 MiB of RAM and it ran well.

None of the things mentioned here in this thread justify the increased RAM requirement for Haiku. The reasons put forward, as I read them, are:

– Optimization is not a priority for Haiku right now (fair enough)
– It perhaps never will be (a shame)
– RAM is cheap, and most people have plenty (irrelevant to my argument)
– Super-efficient, clean, cruft-free code is no longer as important for us as it was for BeOS (this is the crux of the argument).

This is one of the several ideological differences between Haiku and BeOS that means the original will always have a special place in my heart, no matter how much Haiku develops. BeOS, as I choose to remember it, was not just an OS, but an software ideology.

Haiku has lost that, and perhaps doesn’t even care that it has.

1 Like

What I remember hearing is that both BeOS and Haiku take advantage of memory and tend to use all of it. What is it about Haiku that people think is not lightweight? There is no crime in using all the memory. I think the real crime is running BeOS or Haiku on uniprocessor systems.

I used BeOS R4, R4.5 & R5 on a dual Pentium Pro 180 system with 192 MB ram. I could play Quake just as well as my friends running Linux and Win2k. Today, we are just lacking Hardware Acceleration. If we had that Haiku would seem more lightweight.

I’ve ran R5 on plenty of hardware, including Pentium 1’s, and it was not comfortable without at least 96MB or so, otherwise it was hitting the VRAM hard, that was before starting anything like a web browser which would consume even 128MB.

Debatable, compared to any of the *NIX operating systems and even windows Haiku is still efficient, clean, and garbage free. Just look at X11, a shit show of 30 year old hacked on spaghetti code that serves virtually no purpose now since any of the window managers today has a compositor that takes over all the tasks that X11 used to perform, but X11 is still there and still required, just complicating things.

I have to laugh, I looked at OpenIndiana just now, the min, install is 494 MB in size and the full install is 1.6 GB in size, yet there are people complaining about the size of Haiku!

1 Like

I agree.

Optimization takes development resources (i.e. programmer hours, which are a precious resource)

“Be, Inc” was a company founded by venture capital that could (I assume) hire full-time programmers to sit and optimize for the low-end hardware of the era. Haiku’s developers are probably mostly working in their “spare” time.

In general, if you want to make and finish good software, redirecting valuable limited programmer hours ‘this way or that’ on every little whim is ineffective strategy. Suddenly throwing programmer hours at optimizing for machines with less than 128MB RAM in a world where virtually none of the target market has so little RAM doesn’t seem like a sensible use of programmer hours to me … I’d rather see time spent getting to a ‘stable version 1’ that can do useful things.

If a programmer enjoys doing memory optimization, and that’s how they want to spend their spare time, well, fine, no harm.

But to expend development resources, the question is, is it more important than other features that would give ‘more bang for the buck’ toward making Haiku a usable, useful, stable operating system for most of the target users? I doubt it. My lowest-end device in the house has 4GB RAM. I threw 4GB at my Haiku VM as I have 88GB of RAM across my main dev machines. I would hate to see Haiku’s version 1 release date be pushed further back in order to have programmers save just a few tens of megabytes of RAM.

This thread, and some of the comments, feel a bit troll-y.

1 Like

We should consider Haiku on real Hardware and not on virtual machines :sunglasses:

1 Like

Short answer: Haiku is not BeOS. It does not based on the old Sources, it was rebuild and optimized. There are many differences between Be and Haiku today.

2 Likes

If you want it, start to port it. No one hold you back to do this. Haiku is open source and people need software. I prefere a web+ browser because it is more native. If you have not the expierience, start a haikuports source tree with parlemoon and of one have interest, can help you.

2 Likes

It’s easy to say this when it’s not you that has to spend ~3-12 months of your “spare time” (inbetween normal work and life priorities) to sit and optimize code … it’s easy to just be critical and yell at someone else’s project when you don’t know anything about coding and demand they use their time this way or that. (To be clear, I don’t work on Haiku but I have worked on both open source and commercial projects.)

I’ve been programming since 1992. My first computer had 1MB RAM and a 20MB hard disk. In 20MB we fit the OS, games, development environment, word processor, drawing program, source code, utilities, drivers and more - even a little pr0n. So I know what tight, efficient code means, and I also understand how bloated OSs like Win10 or smartphone OSs are. In those days, I had to write much of my code in assembly language in order to achieve good performance and tight memory usage, and even to do basic things like draw pixels to the display efficiently required painful, lengthy assembly language procedures … back then most of the applications and OSs had large portions written in assembly language. Almost certainly, the original BeOS had portions hand-optimized in assembly language. This is enormously expensive and draining in terms of programmer hours - it takes days or weeks or months to develop and optimize in assembly language what may take minutes to code using eg standard libraries (which may use more memory or be slower but on today’s hardware are mostly ‘efficient enough’). Companies like Be Inc likely had full-time experienced developers being paid full-time salaries to do this kind of coding. The Haiku developers are the ones who best understand how to prioritize their own time. It’s not a “difference in philosophy”; skilled programmers aren’t a dime a dozen.

1 Like

he sais correct. you don’t. you are a linux “veteran” but I am an XP one. so I probably know better about XP. I used 32 bit XP a lot, then 64 bit XP. honestly, I stopped using it often only recently. Even if you go and sum up all the kernel memory and user mode OS components working sets, you will get numbers around less than 100MB of the OS consumed memory. I still remember this constant 11MB of nonpaged pool on a fresh start. plus ~30-50MB for paged ones. plus couple of megs for kernel images. components like lsass, csrss, winlogon, even on 7 take up 3-7MB each. and there are a half of a dozen of them. so where did you get 1GB from?
and don’t forget - Windows (and XP’s too) graphical subsystem is incomparably better, than the linux’s zoo. by efficiency (just compare CPU utilization on UI activity! I need to yet see a linux that would load CPU as negligibly as Windows on such tasks. this “lightweightness” is even more important for me).

1GB for install is another story. I faced with this behavior - intel graphics driver complains that it doesn’t have memory and starts to show 4 bit colors. but it’s in no way an “OS requirement”.

Haiku’s method of package management will use more memory. It still isn’t that bad and Haiku uses a lot less memory than the average Windows 10, macOS or Linux setup.

There may be things that can be improved, and I personally have interest in improving things like memory usage, but there is definitely a point of diminishing returns. Haiku is all volunteer based at the moment, and the volunteers have limited time and they must prioritize work based on value to themselves and the project in general. At the moment it makes more sense to improve Haiku than to minimize memory usage.

With all that said, there has been a lot of work by waddlesplash to improve kernel performance for things like compiling. That has more benefits than memory use reduction.

Lastly, I am confident Haiku is much more usable on older hardware than other systems, even without things like GPU acceleration.

5 Likes

I don’t view them exactly the same:

  • Optimization is a priority. It is not the first one, but when we notice a problem, we do fix it. Using 250MB of RAM isn’t a big problem in the current world, and we already did some work to get there.
  • RAM is cheap, irrelevant to your argument maybe, but relevant to our users.
  • Clean code is valued a LOT more in Haiku than it was in BeOS.
  • Cruft-free, we do as well as we can with the constraints we set ourselves of being binary-compatible with BeOS. Of course BeOS is 20 years old now and that means it comes with some cruft.
  • Super-efficient often goes in opposition to clean code and architecture. I think C++ allows us to make a very good compromise between the two, as it’s possible to write the code in nicely separated modules and have the compiler optimize a lot of it into very efficient code. There are two drawbacks to this: C++ is not the perfect language to do this (in particular one has to use a lot of templates and avoid the typical object-oriented way, at the expense of losing some forward compatibility and ABI stability), and we are still using gcc2 for compatibility with BeOS (modern versions of gcc are a lot better at optimizing things - but at the expense of longer compile times, which I think is ok in the modern world and especially because it bothers only the developers and not the users).

If you read the project tagline that I put in my first reply here, “lightweight” is not there. But “fast” is. And being fast involves sometimes using more memory in order to be less CPU intensive. So, optimization is still there, but the goal is not the same.

3 Likes

You complain of memory used then you want Haiku devs to port a browser that is everything but lightweight. Not very logical. Obviously, in that matter, same features included, a native browser will always be more efficient.
Did you ask whoever is M$ CEO to drop Edge for Chromium anyway? Or did you ask to Google CEO to drop Chrome for Firefox? I’d like to see answers… Come on. Show them. We all need a good laugh.

Templates help optimization? I didn’t know that, but specifically when it comes to memory footprint I would have guessed there’s extra cut and paste code.

For me it’s kind of a good thing that the API is old school C++. The layout stuff being the obvious exception, and maybe the one place where it’s likely to ever be worth it.

I’m surprised that the memory footprint comes up as an issue here. If that’s what we have to complain about, I would think it means Haiku is nearing perfection.

1 Like

Templates allow inlining of the generated code, which in some case is useful to optimizations. It’s noticeable because usually it’s useful in cases where doing the same thing in C requires a lot more work (with macros which tend to become unreadable even faster than templates).

The typical example is when you’re implementing a linked list. You do it by having a List class, that contains “objects”. There are two ways to do this: your list can be a template:

class List<T object>;

Or it can be that the list can only contain subclasses of some “Object” type.

Since the code to manage a linked list is very simple, the template version will usually be better. It inlines pretty much everything, and the compiler can then optimize it to be as fast as if you had written your code in C, shuffling pointers directly (or with macros). On the other hand, the version where elements must subclass some common type will have its code compiled only once, and everything using such a list will have to go through function call overhead and probably virtual methods, which can end up being quite a lot of overhead if, for example, iterating the list requires calling a function each time you want the “next” element.

This does not mean everything should be done with templates, however, in some cases, indeed the code duplication will use a lot of memory and there is no good reason for it. I think that’s the way C++ does things: it gives us a lot of tools, and lets us decide which one is appropriate in each case (which is not always an easy or obvious decision).

1 Like