The collected works of ShadeOfBlue - Page 5

R4k and up have three privilege levels -- kernel, user, and supervisor (but nobody actually used that one ). Two are enough to implement a secure OS.


FAT is a really simple filesystem; making an IRIX module for it should take about a week or two. Remind me again sometime in July


That's much more complicated

The current USB implementation is completely undocumented, so the cleanest thing to do would be to port the USB stack from NetBSD or something similar. This is a lot of work, since someone has to rewrite the parts dealing with announcing new devices to the kernel, making entries for them under /hw and so on.


A quick disassembly of the module would show if it only has stubs or actually implements something. Reverse engineering the API is probably too much work and it would be easier to just port FUSE to IRIX.




Also, to speed up booting, you can put an "exit 0" after the first few lines of comments in /etc/init.d/sendmail and /etc/init.d/esp (or availmon or something...). Even if you chkconfig those off, they will still print a message and run some crap which takes some time at boot and shutdown. There are some other files like that, but I always forget what they are

They're in a hidden directory in each source subdirectory. This is normal for an autotools-generated makefile.


It looks like a dependency line in the makefile got truncated somehow. Have you set the ncargs systune variable to 262144 before running ./configure and all that? If you haven't, increase it and run "make distclean" then "./configure" etc.


Learn LaTeX, you will never want to use anything else

Try a newer GDB, there have been some changes to the debugging format in gcc 4.something.

The Model M was supposedly a "cost-reduced" version of the Selectric keyboard and the Cherry key switches are a "cost-reduced" version of the buckling-spring ones in the Model M

I have one of these keyboards . It's not a Selectric by any stretch and it looks kinda cheap, but it's well made, takes up little space, works well with SGIs, and is comfortable to type on. It looks much better if you replace the three Windows keys with blank ones


Wow, that code is really ancient
For comparison, here's how a modern Fortran program can look like: http://www.liv.ac.uk/HPC/HTMLF90Course/HTMLF90CourseNotesnode62.html


These early computers were interesting, everyone made their own CPU architecture back then

The patent applications were much more substantial that the crap that gets accepted today. For example, for the HP 9830A computer, HP put _everything_ you needed to know how to build the machine in the patent application. This includes all the schematics and even the source code for the ROMs. Here's a PDF of it: http://www.google.com/patents/US4012725.pdf .

There's this HP-HIL to PS/2 adapter , but it's very expensive.


I've always wanted to build my own PDP-8/S
The PDP-8/S is interesting because it had only 519 logic gates and its CPU processed only 1 bit at a time instead of the full 12 bits (it was slow, but physically small-ish).
If somebody has any links to a schematic for it (preferably using new CMOS/TTL SSI/MSI logic, not individual transistors), please let me know =)

Most of the old equipment I've seen was also designed to be serviced, so there are many extra markings & test points on the PCBs, and dedicated service manuals etc. Now it's just expected to throw the entire thing away and buy a new one if a single capacitor fails

The build quality of most new devices is also very bad. I managed to save an HP 9830A , built in 1972, from being thrown away (however, those idiots threw away the plotter before I could get to it ). The machine is over 40 years old and is _still_ working perfectly! I bet no electronic device made today will last that long.

Tempting! One computer and the tape punch would be more than enough, though

Surface shipping for those two would probably be affordable if the Chinese post office still offers that option... I'll send you a PM in June and we'll see if it's feasible

Sorry, I mixed up surface mail with freight

The PDP is about 50kg (110 lbs) and the tape punch about 20kg (44 lbs), right?

However, it has a linear power supply, so that is probably about half its weight. If the PSU is easily removable, the PDP could be split into two packages and sent by mail (it might exceed the max. dimensions, though).


Thanks, I'll keep my fingers crossed


It's strange that companies don't donate such things to a museum, especially since in most countries, they have to pay for someone to recycle the stuff... That HP plotter was older than the people who threw it away, so I guess they didn't even know what it was for, maybe that's the reason.

This is true only for C++ code, you can mix C code without any problems, so:

MIPSpro C program + GCC C libraries = ok
MIPSpro C++ program + GCC C libraries = ok
GCC C++ program + MIPSpro C libraries = ok
MIPSPro C++ program + GCC C++ libraries = not ok
GCC C++ program + MIPSpro C++ libraries = not ok

This is because MIPSpro and GCC use different function naming for C++ code, but the naming of C functions is the same.

The optimizer in GCC 4.7.1 is at least as good as the one in MIPSpro (and actually substantially better on some numerical code I tried it on, YMMV), so there's really nothing bad about compiling a C library with GCC anymore

There were incompatibilities with passing structures smaller than 16 bytes, but that was in GCC 3.3, which is ancient. I haven't experienced this problem with 4.7.1.

How?

Miod is right. No standards-compliant C compiler should require backslashes in this situation.

Why? The compiler doesn't care about whitespace at all. So, the following two programs are identical, as far as the compiler is concerned:

and

Compile them both with c99; if it fails to compile the second example, then the compiler doesn't follow the standard.

inst shows these internal package names by default and I think there's an option to have that same behaviour in swmgr.

You can see which subsystem contains a specific file by doing a "versions long | fgrep /usr/nekoware/lib/libz.so". Then to get the subsystem version do a "versions -n neko_zlib.sw.lib".

"versions -n long | fgrep /path/to/file" might also work, but I'm away from my SGIs at the moment, so I can't check.

There are lots of errors here.

First, if you want to add a search path for libraries, you use "-L", not "-I". "-I" is for adding a search path for C/C++ header files and is ignored while linking. Also, there's no need to add "-L/usr/lib32", it's searched by default.

"-mips1" is only for R2000/R3000 and requires the older O32 ABI. You shouldn't be using this on any modern SGI, it slows things down. Use "-mips4" if you're on a R5000 or newer, "-mips3" otherwise.

From a previous post it looks like you're compiling this without any optimization flags, which is a really bad idea. Add "-O2" to the compile line.

After you make these changes, it should work better

Try this:


This will compile all the .c files and link them into a "glchess" executable.

Did it say which library was O32?

IRIX 6.2 supports the N32 ABI, so it would be best to make sure all the libraries you are linking to are N32 rather than O32.

The SGI freeware packages should have separate subsystems for O32 and N32 libraries. Make sure that all the prerequisite packages have the N32 subsystem installed.
Then it should Just Work(TM)

-O3 can actually create slower code. It helps a lot if the code is C++ and uses STL, or does a lot of numerical math, but in other cases it can be about 5-10% slower (this is mainly because it unrolls too many loops, so less code fits in the L1 cache).
It's best to experiment


You're linking them with the wrong libraries. */lib is for O32, */lib32 is for N32. You're telling the linker to look for O32 libraries, so it's no surprise that's all it finds.

If you have all the appropriate libraries installed (N32 subsystems of their freeware packages), the single compile&link line I posted a while ago should work. You don't need to use "make", just copy & paste that line.

If you want to do it manually with "ld", tell it to look in */lib32 and not in */lib. Also, there are no libraries in /usr/bin, so remove "-L/usr/bin"

Not if you're linking manually with ld

Use gcc to link the files:

This will automatically link it with libc and any other common runtime files it may require.

The order of the libraries is also important. Did you use the exact line I posted?

I've never peeked inside a running Mac Pro, but on the old PowerMacs they had a red LED next to the RAM turned on all the time. On those machines it was harmless and didn't really mean anything if it was on. They probably did this as a warning that the machine is running and you shouldn't replace RAM or something.

I've seen this on both Sawtooth and MDD PowerMacs.

Looks like they've changed the meaning of that LED on the newer models

This is true. The email client is a good example of how multithreaded programs should be written.


This is partially true. It works great for IO-bound tasks, but for CPU-bound tasks it's different.

In a 3D renderer, you can trivially parallelize rendering by splitting rendering of individual lines of the output image into separate threads. However, if you ignore how many cores the system has and spawn all the threads at once, the OS scheduler will try to execute them all at the same time, there will be a lot of context switching and the program will run slower than if it knew how many cores it has.

This is an example where spawning all the threads is a bad idea, but only because the scheduler is not a batch job scheduler. If the OS had a separate scheduler for such tasks, it would be as you say.

The reason why it's slower is because all those CPU-bound threads compete for execution at the same time. Every time the scheduler swaps a thread it must save its registers and load registers of the new thread, this is called a context switch. A good scheduler will also take cache into account. If a thread has been doing some work on core 2, that core's L1 and L2 caches have data which that thread needs. If you now give that core another thread to execute, that data will eventually be replaced with the new thread's data. When the original thread resumes execution on that core, the core will have to reload all the data from main memory, which is very slow. Now imagine this repeats for every CPU-bound thread. If you spawn just the right number of threads, every thread will get its own core and things will run faster because they won't compete with each other. Even if a CPU-bound thread is interrupted by an IO-bound thread, it won't cause as much damage because IO-bound threads typically don't need a lot of cache, so our renderer thread will still have its working data in the cache the next time it gets scheduled.

For HPC workloads a batch scheduler is best, but for general desktop use the time-sharing one we have now is better. If you want to run long CPU-bound tasks on this kind of system, you need to compromise. Knowing how many cores the system has enables you to simulate a batch scheduler on top of a time-sharing one. It's a kludge, but it's what we've got

An interesting project would be to add a batch job scheduler to UNIX. Then the OS could worry about these things and knowing how many cores the system has wouldn't be necessary anymore. On HPC systems this is typically done in userspace, but a kernel-based solution might be faster.


This is an IO-bound task, so you are correct, splitting it up into that many pieces would be much slower

I suppose. However, if you're reimplementing the functionality of OpenMP and similar lower-level libraries, then you need to know how many cores the system has at runtime. There's no other way to do these things, because the kernel lacks a proper batch job scheduler.

But this is a kludge, really. For example, on the new AMD processors, they lie about the number of cores -- their "8-core" processor only has 4 proper cores (with FPUs and everything) and an additional 4 integer units. So if you try to run an FPU-heavy workload on one of these processors, it will run slower with 8 threads than with just 4. This is why I think a batch job scheduler should be part of the kernel, there are simply too many different architectures.

A practical example... The c-ray benchmark is flawed because it doesn't take into account how many cores the system it's running on has. If you spawn one thread for every line, the threads will fight each other and the program will run slower. The proper way of doing parallelization in c-ray would be to ditch the manual pthread implementation and just use OpenMP. With just one line of C, it would run properly and wouldn't have to know how many cores the system has. Also, there would be no overhead on single processor systems -- simply compile without the "-mp" switch and voila.



Memory is still the main bottleneck, apart from I/O, yes
This is why processors have caches, but for random memory access patterns, they don't do much.

Also, on the Octane, both processors share the same bus. I forgot the exact bandwidth of that bus, but it was around 1GB/s. If both processors need something they don't have in the cache, that's effectively half a GB/s for each CPU, which is kind of slow today (but not when the Octane was released).


This is exactly how modern GPUs work They have thousands of independent tiny cores, which work on a stream of data.

However, only a few problems can benefit from such an architecture. You often need to have some sort of communication between various cores.

SGI also had reconfigurable FPGAs that you could attach to an O3k or Altix system. That was a pretty good idea, but probably too expensive to be of much use.


Of course
Most of the old computers used in HPC, e.g. Crays, didn't have multitasking. There was just a simple interface for the batch job dispatcher, so the system ran only one program at a time.

Now HPC systems use Linux and have a similar job dispatcher implemented in userspace. At least this is how things work in the larger systems I've seen.



True, but spawning processes and switching between them is slow. This is why most libraries used in HPC use threads.


This thread has really veered off course

I've tested the script on a MacBook Pro with 10.6.8 and it works fine:

Those errors are because of a missing function prototype for gtk_file_chooser_button_new_with_backend().

By default (if you forget the prototype or leave out types in the implementation), every C function returns an int, so this is the reason for the last two errors. The first error says what I just wrote, but in a shorter way

It's possible to crash the program if the functions used inside an OpenMP block aren't thread-safe. Sometimes it's also necessary to manually specify which variables are shared and private, so that the compiler can handle accesses to them properly. Another thing is that MIPSpro doesn't support the latest OpenMP version, they're one or two versions behind, so that might be a possible reason.

A quick check would be to compile it with the gcc 4.7.1 I built (the older Nekoware package had broken OpenMP support). If it works fine, it's probably a version problem, but if it doesn't, it's probably related to the IRIX C/C++ library.

As with all multithreaded programs, there are a number of other possible causes



We probably think the same thing but use different definitions of multitasking

I meant that in the same way we have multitasking on standard computers today -- a time-shared execution of multiple different programs. First Crays didn't have that, but a single program could still use more than one processor, the later ones ran UNIX anyways.

I've seen it called that too, but the newer literature seems to prefer "multitasking" (e.g. http://en.wikipedia.org/wiki/Multitasking#Preemptive_multitasking.2Ftime-sharing ).

Would you consider the textbook used in MIT's Operating Systems I class a few years ago to be authoritative enough?

According to Operating System Concepts, 7th edition , multitasking and time sharing are one and the same thing [p. 16] (also, under the index entry for "multitasking" it says "see time sharing"). It defines it as an extension of multiprogramming, where switches between jobs occur frequently and not only when a job is waiting for I/O or another task, so that the users can interact with every running program. It later divides it into preemptive and cooperative multitasking (as is done on the Wikipedia page).

This is the accepted definition in use today.

35 years ago, the word "terminal" was primarily used to describe a physical machine, but now when someone says "I'll open a terminal", it means he'll start a terminal emulator program, not that he'll take apart a VT100.

I don't decide how people choose to name or rename concepts

Some drives have a "delayed start" jumper, so they don't trip the circuit breaker if they're used in large disk arrays

If you check the drive's documentation, you should see if it has any such jumpers and if they're set on your drive.

I actually agree with most of your points (and thanks for the detailed explanations)
The low-level OS stuff I've worked on was dominated by UNIX-like systems, so this has skewed my view of operating systems in general. To be frank, I didn't like that book either, is there a better one you could recommend?

The broad and general description I used was simply because that is what the vast majority of the systems used today implement, so this is what people reading this forum are most familiar with. As you say, it is not correct to lump everything together like that, but this is a public forum, not a scientific article
The Wikipedia link was never meant as a proper proof, but as an example of such usage (which is why I preceded it with "e.g.").


So now that we've cleared up the terminology and almost completely derailed the thread, perhaps we can return to the original topic of the number-of-CPUs detection script

jwp : on IRIX you can also use "sysconf NPROC_ONLN" to get the number of CPUs currently online. This way you don't have to parse the hinv output, so it's a little bit faster and will now also work on mixed-CPU Origins, where hinv reports processors as:

It's OK
Writing makes it harder to convey the tone and English isn't my first language. I'm sure if we had this discussion in person, there would have been no friction.


I like that Maurice Bach's book, it's well written.


HP also made some pretty awesome patents for their hardware -- all information on how to build the machine was in there, including ROM contents with disassembly. I recently saved a fully working 9830A from being thrown away and am slowly going through its patent application to see how it works internally. It's similar to the early HP minicomputers, except it has a much slower CPU, simpler I/O, and a BASIC interpreter in its ROM (this dialect of BASIC is actually much nicer that what was available on home computers, it's more similar to Fortran and can do matrix multiplication etc.).


I like doing that, but some hardware is very hard to find nowadays or it's too large to ship. Emulators exist, but not for every system, so the less popular ones slowly fade away, which is sad.

This is a bit trickier to fix, since IRIX doesn't have MAP_ANON. The first comment here shows you how to fix this.

So, instead of using -1 as the file descriptor and MAP_ANON in the flags, you manually open /dev/zero (mfd in that comment is an int) and use that file descriptor. You should also close() that file descriptor after the munmap() call, otherwise it will leak resources if it's called too often.

EDIT: I see we really jumped on this one

It should, but I'm not 100% sure, since SGI yanked the manpages for anything older than 6.5 from Techpubs

Moved to the HP/DEC forum

I think we're mixing up the current situation on UNIX systems and elsewhere .

What I said before was that on a UNIX system , if a CPU-bound program knows how many CPUs the system has, it can run better than if it just spawns hundreds of threads willy-nilly. This is a measurable fact, not speculation. GUI programs are IO-bound (waiting for user input), so they won't benefit from knowing the number of CPUs.

The script made by jwp is for UNIX systems, so it makes sense to talk about those in this thread

I'll now address a few of the points you made...


1. Responsiveness while running CPU-bound background jobs
The responsiveness issues you describe can be fixed by running the CPU-intensive stuff at a lower priority (higher nice(1) value). If you run the rendering job at a nice value of 20, then every UI app will get priority over the rendering job and there shouldn't be any sluggishness. You could also try boosting the priority of UI apps (lowering their "nice" value with renice(1) ).

However, you must set the nice value manually, since the kernel has no clue which program does what. IIRC, Maya runs the rendering processes at a lower priority, so the user can still work normally on the rest of the scene at the same time. And this actually works, people use it this way.

If you're compiling something in the background and you don't use "nice" to start those jobs at a much lower priority, they will run at the same priority as nedit and firefox and the rest of the stuff you've started. As far as the kernel is concerned, these tasks are equally important, so it won't favour nedit and firefox.



2. CPU-bound programs spawning as many threads as they can
Now if a renderer starts 2160 threads (one for each line in a typical 4K image), it will burden the system needlessly, especially if you run it at the same priority as your GUI apps. It doesn't matter if the threads are created a few milliseconds apart, that's not the issue here (thread creation is cheap). Context switches are expensive, it simply makes no sense to spawn that many threads, because then the system will spend too much time switching between them (the threads will fight each other for CPU time!) instead of doing work, it is inefficient (I've explained this in more detail in a previous post). This is not speculation, I know this because I've written parallel renderers before and I measured that spawning threads for every line in the output image was much slower and used more memory. This is why no proper renderer does that. Look at Maya or any other good 3D suite, every single one will check how many cores the system has. There is much less overhead if the program spawns only as many threads as there are CPUs and then distributes work between them. Every scientific app using OpenMP works like this. The OpenMP library checks the number of cores available and then spawns the appropriate number of worker threads.

The only scenario where spawning all the jobs at once would make sense is if the kernel provided a batch job scheduler. So you could simply put your tasks into a global queue and the kernel would work on one or more tasks from that queue (depending on number of CPUs) whenever the system is idle.

In a time-sharing OS that doesn't provide this functionality, spawning lots of CPU-bound threads will result in lower overall performance (the threads will fight each other) and consume more resources (you need memory for every thread's stack at the very least) than simply checking how many CPUs are available and using an appropriate number of threads.



3. Using an Origin as a desktop machine & behaviour of IRIX's scheduler
Origins are not desktop machines. The behaviour you've seen (one CPU more loaded than the other) is normal. This is because the scheduler also takes cache locality into account, along with a lot of other metrics (on NUMA systems it is also aware of the system's topology which also influences the decisions it makes). Having one CPU loaded more that the others is not an indication of a crappy scheduler.

If you have lots of short-lived tasks, it makes no sense to spread them out to other CPUs and thrash their caches. IRIX will actually distribute threads to other CPUs once it figures out they will run for more than a few seconds (or if the main CPU is very busy). Also, if you re-run a single program many times, IRIX will try to run it on the same CPU, because that CPU already has the data that program needs in its cache, which is why it would be inefficient to run it on a different CPU. If the kernel didn't care about cache locality and just tried to keep every CPU busy, it would be similar to one of those parts boxes with multiple drawers and having one of each screw type in every single drawer, because it's a waste to keep drawers empty. Finding a specific screw would be very slow

What you want is something like BeOS, a single-user desktop OS. IRIX was made to run on everything from workstations with a single CPU and one user to servers with 1024 CPUs and thousands of users; it's difficult to have optimal performance in every scenario and for every workload. Adding a batch job scheduler to the kernel would help a bit with background jobs such as rendering and compiling (and then those programs wouldn't need to know how many CPUs the system has). But even as it is now, if you lower the priority of such tasks, the system should remain quite responsive. I'm not saying it's perfect, it could use improvements, but it's not a complete disaster




I hope it's clearer now why checking the number of available CPUs is a perfectly normal thing for a CPU-bound program to do on a UNIX system

pbzip is IO-bound, so what you said is true. But for most CPU-bound tasks, the number of CPUs you have _is_ the optimal number of threads!

Path tracing (a rendering algorithm) is a task which scales linearly with the number of CPUs available (for all practical purposes... on a NUMA system with 256 cores and more you need to tweak memory placement as well to maintain the speedup, but that's not really important to this discussion). For this task, spawning as many threads as there are CPUs _is_ optimal. If you know a better solution to this that doesn't involve knowing the number of CPUs, then please say so

There are plenty of other CPU-bound workloads which have the same behaviour.



And which application has the focus on a multi-user system?



So what you're saying is that the kernel should have a magic crystal ball and use that to determine which process you find more important?

But still, the kernel will age the priority of processes if it figures out they're CPU-bound. The longer a CPU-bound process runs, the less important it becomes to the scheduler. So it should favour IO-bound processes (including GUI).

However, when you're compiling something, the compiler also does IO operations, which causes the kernel _not_ to lower its priority, which explains why you would experience responsiveness issues in this scenario.

Adjusting the nice value of a process will hint the kernel that the process is either less or more important from the start and will keep the system responsive.


If you want to use a UNIX system, help the kernel and run the background tasks at a lower priority, and the system will work exactly as you want it to

If you want the OS to handle UI tasks in a special way, then UNIX is not what you should be using. On UNIX, every one of your processes is equally important to the kernel, unless you tell it otherwise or it figures it out on its own.

IRIX also has a special scheduling class for (soft) real-time processes. If the GUI used that, you wouldn't see any issues with responsiveness. However, SGI must have decided against that for some reason and they use real-time priorities only for recording video and similar tasks.



What would be a good approach then? You've agreed that spawning one thread for each image line isn't the right thing to do, so what is the optimal number of threads for a renderer if you can't get the number of CPUs?



It's possible to lower the priority of individual OpenMP threads, so in that case it works just fine on workstations. Within the same app you just check if the user ran the simulation/render job from the GUI or from the command-line and adjust priorities so it doesn't get in their way. Or you could just always use a lower priority. This is similar to the Maya example in my previous post.



Did you read the rest of my explanation? Spreading threads to other CPUs just because they're free would give you worse overall performance, including GUI apps.

The unresponsiveness isn't caused by the thread placement policy.


It would also be inefficient for the usage scenario you describe. If you want the kernel to treat your programs preferentially, then just tell it so!


Both of those OSes were made for much simpler hardware where cache locality and similar concepts didn't matter as much as they do today. If you changed their schedulers to take that into account, they would run even better on new hardware, thread placement isn't responsible for sluggishness. For a single-user machine, I agree, an OS like those would be better.

Speaking of schedulers... I took another look at Miser , the batch system on IRIX. It's not a fully-userspace implementation, as I had previously thought, but it has a kernel component too. It runs batch jobs from various user-defined queues whenever the system is idle. This kind of batch system is exactly what I had in mind when I talked about this in a previous post.

Next time, try using "nice gmake -j2" instead of just "gmake -j2". If you're still not happy with the responsiveness of the system, try using Miser. I've used IRIX even under heavy loads and have never experienced the kind of responsiveness issues you describe. It works well enough for me.

Did you experience similar UI responsiveness issues on other SGIs you have?



It is useful if you want to ssh into your machine from another location. On single-user OSes like BeOS or classic Mac OS, you'd have to run a VNC server and then you wouldn't get a separate session, you'd just control the session that's currently active.

If you don't need that, then yes, it would be a bit faster and more responsive


That's what I wrote. The last version of IRIX is used in both scenarios and everything in between.

Even in the Personal Iris era you had the Power Series racks with 8 CPUs and multiple users, so a single-user OS like you describe wouldn't have been useful there.

A big reason why it took off is that you had the same OS on both the low-end workstations and large servers, same behaviour everywhere. This made it easy to develop and test software for it.


You might like Plan 9, it was designed from ground up to fix the kludge that UNIX has accumulated over the years. However, since most people think that UNIX-like systems are good-enough (or aren't bothered enough to look for alternatives), it doesn't get much attention.

Another problem with alternative operating systems like BeOS and such is that they lack software. An OS without software is useless. If every program you need to do your work is only available on UNIX or crappier alternatives, then you don't really have much of a choice

I just stumbled upon this on eBay:




http://www.ebay.co.uk/itm/380687061536

It's on one of the "General & Platform Demos" CDs as part of the general demos distribution

I'm not sure if it's exactly v1.9, but there's a chance it could be newer than what's on ID's website.

It should
You don't even need to format it with xfs, since dd overwrites the filesystem anyways.

On an O3k the CD is connected via Firewire, so the system knows how to boot from it. If SGI kept this feature in the O300 and Tezro machines, it should be possible to boot IRIX CD images this way or even have the system disk on a CF card and use it as an SSD without the huge cost of SATA->SCSI adapters and similar.