World's fastest Haiku box

Well I just built a new machine with the latest Intel 8 core Sandy Bridge CPU and 8GB RAM and it booted Haiku. But the video and network didn't work and I think there were interrupt issues that slowed it down. With that fixed and with Haiku installed on the SSD I got for this system as well it should be pretty darn fast. And since I got a deal on the CPU and SSD total cost was only around $600. No need to waste money on overpriced Mac hardware.

My friend went with a board that supports the latest 12 core AMD cpus (for 48 cores) however he went with the 8 core ones for the value... for now.

Also The Apple software really can use the machine he said the difference between his machine and a quad core machine is immense.

Intel may be faster at single threaded stuff but there is a reason AMD dominates on supercomputers :) cost/performance is much better.

SMP support is also available in Linux, BSD, Haiku, Windows NT family, etc. Not just on MacOS X. Depends on which applications are used and how well they are multi-threaded. Without knowing what software or use for the system it is impossible to say anything.

I will say that is a very powerful system and hopefully he is using lots of multi-threaded software on it.

I don't recall the software he was running it for a friend that was in a hurry and didn't have time to wait weeks on his quad core to finish.

As far as what he runs he I know for a fact he is getting his bang for his buck LOL... he had it building all of the redhat repos from scratch mostly vanilla with some important fixes but I think scientfic Linux fixed up what he wanted working mostly as well as the slow release of centos 6 heh. Apparently at one point he even ran out of ram trying to build too many kernels at once which is mind boggleing but it happened O.o

Its overall the most impressive box I have ever seen though he built one for someone else with far more resources along the lines of 32-48 cores and 256Gb ram and 3x SLI

My mind has been on other things tonight and well I need sleep and am not getting it so I end up posting here... heh good night all and no I didn't hallucinate this post I am sure.

Personally I would sink my money in a TYAN board.... I have an ancient one (2x300Mhz) that runs like a tank it was an amazing board its day. Tyan Thunder 2 ATX very similar to the board the BeOS demos ran on though a few Mhz faster.

So haiku is limited somehow? I'm not sure i follow sure there is scalability issues but I'm not sure I follow what you are saying directly with regard to haiku. I guess it could be similar to how IO performance was hampered on BeOS due to the suboptimal block size which was being used.

Yes for professional use on MacOS X or Windows or as Linux server makes perfect sense but Haiku lacks the applications to make real use of a system like this.

Also, Final Cut Pro is made by Apple for MacOS X so no other choice for the OS. =)
You will not see FCP software on Windows.

Windows and MacOS X control most of the desktop market with 80% & 15% respectively or close to that. That's why you see most commercial software on those two OSes. ie, because they are popular and have most of the desktop OS market.

There still is some software available for Linux (open-source type) which do similar jobs.
http://en.wikipedia.org/wiki/Comparison_of_video_editing_software
http://en.wikipedia.org/wiki/Comparison_of_3D_computer_graphics_software

So a couple of options are still available but just not the big name ones. These shorts done with Blender look interesting but of course Blender not popular video editing choice like FCP.
http://en.wikipedia.org/wiki/Blender_3D#Use_in_the_media_industry

Soft-affinity would be an improvement even on the very common dual-core systems. But there are lots of other problems. Locks for example. To scale from one CPU to two or more, the locks ensure that access to critical data structures and code paths is serialised. But this serialisation becomes a bottleneck for the most frequently accessed structures as you scale up further.

indeed on Linux it was the BKL (big kernel lock) which was introduced when SMP support was added and only recently has it been removed and replaced with mutexes I believe.

From what I gather a mutex is better than a lock as it doesn't stall other things it only protects acess to the component that requires serialization?

Sure whats the time to clear the lock ? IE how much time is spent in terms of clock cycles on aquiring and releasing locks ? its about %20 of a threads cpu demend IIRC.

Look into Amdahls law.

Anyways I think gpgpu is a way better way to go, it doesn't make sense to parrellel alot of operation becuase the overhead exceeds the performance benefit. the things we need to process faster anyways can be done better on a gpu style processor anyways and given the changes that AMD and Nvidia plan to bring to the table soon, programming for them will get alot easier in the future.

"lock" and "mutex" are synonyms in this context, they're both just names for a method to control access to a data structure or subroutine, usually on a voluntary basis (ie the programmer is responsible for ensuring they "take the lock" before accessing the protected data).

The BKL is a strategy used in many once uni-processor Unix systems to bootstrap SMP support, it is sometimes also called a "giant lock". All access to the kernel is initially wrapped with a single lock (the BKL) so that only one CPU at a time can be running kernel code, but as many CPUs as are available can be running userspace code.

Although this is a good start, it's a long way from ideal. Large improvements can be made by releasing the BKL in common code paths and taking a mutex that's more specific. For example by having separate locks for SCSI controllers and TCP/IP, one CPU can be sending a TCP/IP packet while another is reading data from disk. Having a separate mutex for each network card would allow several CPUs to be sending a TCP/IP packet simultaneously, at the cost of making the networking code slightly more complex. The term for using each mutex to protect only a very specific codepath or data structure is "fine-grained locking". Such work began on Linux almost straight away in the Linux 2.0 kernel series.

In the last five years or so there haven't really been many more opportunities to improve performance through fine-grained locking in Linux. The BKL retreated to the dustier corners of the kernel, like VT switching (when you press Ctrl-Alt-F2) or ioctl() calls. It was no longer a bottleneck, and for a while it seemed as though it was mostly harmless.

Ultimately replacing even these more obscure uses with various finer grained locks was desirable because the BKL makes interdependencies within the kernel trickier to understand. It's a recursive lock and it's automatically released when sleeping, so determining whether the lock is always held when calling a particular routine could be very difficult. Removing it altogether completed the job which began when it was introduced, Linux is now probably the most scalable OS kernel that ever existed.

To get there though, something quite different had been happening meanwhile.

Yes but at least for now desktop users do not have to worry except for Intel i7 EE which is 6C/12T (or 6 physical, 12 logical CPUs). AMD desktop CPUs are 6 core & less and most Intel 4 core + HT (ie, 8 logical) or less.

From what I have seen, with 8 CPUs it seems to still run good. Only with benches can see if SMP holds up or not and how well.

Also, since this is just code it can always be fixed with the right programmers. So, even if an issue today, that could change later on by some developer improving the code.

As for Linux scalability, well, if I ever need a system with 256 cores then I will keep that in mind. Or even with 16 or more cores but for now I am happy using my 2C/4T systems. In future we may have 8, 12 & 16 core on desktop but who can say when that will happen. The i7 EE is selling for $1,000 so too expensive and may take 2 years to drop to a better price.

Use installoptionalpackage clockwerk to install and try that out Andrew. Clockwerk was included with A1 & maybe A2 but was not part of A3.

I don't really know enough about the innards to know for sure, but its likely comparable through benchmarking I have done to windows linux in most of the smp heavys apps that are around, mainly handbrake.

As to gpgpu, GCN and Cuda adress many of the problems your hinting at and when a good programming model is developers things like audio DSP, video DSP, etc etc etc will show massive improvements. Actually some already do BTW.

Its just a matter of a good programming model, which BTW Haiku has a very good opportunity as a fiarly clean unencumbered system to make that happen.So if Haiku wants to really make that jump, that big leap, they can likely given the rough construction of the OS and the API's make the jump go gpgpu processing post R1 or even a dev version and likely really do it right. Currently its sort of a hacky add on everywhere else unless its custom written software for a specific purpose and super computers are showin g just how power the GPU can be.

However some apps won't benefit, highly serialiazed GUI's won't but haiku does well there already, its the heavy lifting for audio,video, etc types of processing where those workloads make the most sense to be on the gpu in the first place.

Look around the world is changing.

I'm not sure exactly what you mean by a 'native' Blender, are you talking a pure native Blender equivalent? Haiku native equivalents of such specialized software like Blender, Inkscape, etc seems very unlikely to happen, even if Haiku were to attract lots of developers. I'd say this kind of software really works best as cross-platform projects.

If it's about making Blender look/feel native I think Blender is a poor candidate for that given it uses it's own OpenGL-driven interface.

Inkscape (which I mentioned) would be a much better candidate for being made to look/feel native. Still I'm not sure someone would find it worth doing it even there. Maintaining non-official ports is hard work enough I gather, so I'd be glad just to have the ports at all.

Yes AMD is going for a more open and versitale approach whereas cuda is very vendor specific. Makes a great case to support it.

I am talking about having userland apis and kernel structures etc to make the gpgpu paradigm more effective. A closer tie in vrs a user space and a good programming method and design to make it work. Opencl is a start IIRC gallium plans to support opencl at some point.