The Nokia N900's OS, Maemo 5, is based on Debian and uses apt as its package manager. You can add http://repository.maemo.org/extras/ and related repositories right in the application manager UI (which is just a fancy interface for apt). The OS updates can even be done with apt-get dist-upgrade. You can even install a chrooted real Debian environment and pull random packages from the Debian repositories. And yes, pulling stuff off of apt-get is beautiful.

I didn't write the original post. I chimed in to say that you don't actually have to specify the threads and details of communication with GHC's parallelization extensions.

There is no general purpose programming environment that I know of that completely automates parallel execution. Also, with ANY programming environment, you can make a very inefficient program if you do things unwisely. For that matter, some programming environments or styles are very different and it takes rewriting to adapt existing code properly.

It's all about how easy and effectively the tools make it to do what you want. I think that GHC is among the leaders in concepts for parallel programming. The actual runtime performance is pretty good too, especially if you are willing to put some work into it.

With DPH, I am under the impression (I've used it very little so far, so maybe I'm wrong) that you use the parallel arrays pervasively within the program (any place a strict finite list would do) and the compiler will do most of the work in determining when parallel execution is worth it. Also, Erlang's recommend style of many small processes scales very easily; the runtime will decide when to call through and when to allocate those processes to separate threads. These aren't quite automatic, but it's a LOT closer than the traditional thread & semaphore model.

I've programmed quite a bit in Haskell. GHC is the most popular compiler by far and it implements all the latest parallelization and concurrency extensions (The last standard, Haskell 98, doesn't specify anything in this area).

There are two approaches to using multiple cores in GHC:

Concurrency; which ranges from explicitly created threads (either OS threads or lightweight runtime scheduled threads or some combination) that communicate through channels or locked variables or another traditional method, to STM.

The other is parallelism. Whereas the concurrency methods all use monads to sequence and control operations and produce code that looks more like that of an imperative language, parallelism is done entirely in pure functional code. The short description of pure functional is that all data is immutable. This is very useful for parallel execution because it greatly simplifies evaluation dependencies. You don't have to worry about modifying things in the right order or change conflicts because nothing is allowed to be mutated in the first place. This enables non-strict evaluation, which means that the various values in a program (even those nested in data structures) can be evaluated at any time during program execution, and in any order (as long as they are evaluated by the time they're needed). Parallel approaches include:

• Simple use of par and seq . seq ties the evaluation of one term to another, to force a term to be evaluated immediately even if it isn't strictly needed yet. par creates a "spark" to evaluate a value. This spark may be executed by a different runtime thread than is currently running. Together, you can specify one value to be evaluated locally and another to be potentially evaluated by another CPU. This will work well if the values are reasonably expensive to evaluate (otherwise the overhead of creating the spark, while small, will be greater than the benefits) and independent. Can easily be used with e.g. evaluating all the elements in a list in parallel; runtime threads will pick up and execute the sparks as they are created.
• Parallel strategies. Create an evaluation strategy that mirrors the layout of your program, identifying the parts that can benefit from executing in parallel.
• Data parallel Haskell is an upcoming method that allows you to define parallel array structures that the compiler can see through to determine vectorized evaluation strategies.

In short, none of Haskell's methods of parallelization require you to be aware of threads or synchronization.

Windows NT 3.1 actually introduced Win32 first in 1993, with limited user accounts, profiles and the registry (which was the standard location for configuration). The documentation for Windows 95 marked a lot of Win32 APIs as not available, but it still specified that all application configuration should go into separate user and machine registry hives depending on the scope of the setting. Microsoft published guidelines and made them a requirement for getting the Windows 95 logo, but Microsoft has never had the power to force ISVs to do things a certain way. One choice that didn't help was that Win95 didn't implement any security to keep the OS small and simple, which hid a lot of application design problems down the road.

There are a lot of programs that have problems on newer Windows OSes that were written for earlier versions, but examples of applications that have problems even though they followed the guidelines for the OS version they were written for are extremely rare.

I once went looking to see if there was a way to do it from within the application code itself - something like mlock()/mlockall() in posix - and I couldn't find an equivalent, which may just be a reflection of my own inexperience with the Windows API but I figured I would throw that out there anyway.

The function you're looking for is VirtualLock. You may also look into increasing the process's minimum working set with SetProcessWorkingSetSize. This requires SeIncreaseBasePriorityPrivilege.

A process that is scanning through a file is supposed to use the FILE_FLAG_SEQUENTIAL_SCAN hint so that the cached pages are recycled first, but that doesn't always happen. It also doesn't help that csrss will ask the kernel to minimize a process's working set when its main window is minimized.

I don't know that it's documented in detail anywhere. The beginning priority seems to be based on the process's priority (5 for normal apparently) and is adjusted by usage heuristics and superfetch. There is a overview here. It may help to raise the priority of FF to AboveNormal if it seems like its pages are being discarded unnecessarily.

What the other posters said in reply to your other post about the OS not really knowing what memory belongs to what tab, instead having a page level view of things, is correct. When the CPU accesses a page, it sets a flag in the page descriptor that the page was accessed. The memory manager checks these flags periodically to see what pages are being used. When the MM thinks the process has too many pages, it takes away those that haven't had that flag set in a while. I guess the frequency of usage has some effect on the priority, but I'm not sure.