Slashdot Mirror

For those interested, the IEEE Conference on Computational Intelligence and Games is being hosted by the IT University of Copenhagen, and Mario AI isn't the only competition. There's also simulated car racing, Ms. Pac-man, 2k Bot Prize and the Starcraft RTS AI Competition (!!!).

Actually, good point. This might make the market attractive enough that people like me would consider it worthwhile writing games in their spare time, and possibly expanding into full time. This is what I used to imagine doing when I was a teenager, but at the moment I'm just doing asset management web apps for work and don't really have any projects I'm interested in outside of work (though I am slightly tempted to submit something to the 2010 Simulated Car Racing Championship, I love cars and I love AI.. so it makes sense even though it would be almost trivial to create an AI that can drive round a track quickly if your level of grip stays constant and you have clearly defined track markers).

Doesn't RTLabs, claim to hold a "patent" on running the Linux Kernel as a 'task' under a 'real time' kernel?
http://www.fsmlabs.com/openpatentlicense.html
http://www.aero.polimi.it/~rtai/documentation/arti cles/moglen.html

The winning team was Tower Of Hanoi @ Politecnico di Milano; have a look to the temporary page of the team: team page; some pictures. Last year's edition have been documented too: CTF2004.

Repost of linkage per request. this document

God I wish I could edit posts.

The issue isn't that the context is gone... the issue is that the kernel is executing a non-waiting FPU instruction i.e. "fwait" on returning from the a context that flushes a user thread (i.e. return from signal handler, syscall after execve). Triggers the FPE, except the kernel isn't set up to handle FPEs properly from kernel space in this case. The problem is that the TS flag is set because it's switching tasks, so it receives a different exception, trap 7 (device_not_available). The purpose of that exception is to signal the kernel that a newly created process wants the FPU. So it attempts to set up the FPU... which ends up calling __clear_fpu again... heh... and the original exception isn't cleared yet... whoops.

What's really weird is I found this document, which details the potential problems of trying to use the FPU in a interrupt handler in the Linux kernel.

They brought up the potential of triggering this EXACT PROBLEM... quote "endless trap 7 activation"... only in this case they're talking about writing an interrupt routine, not returning from a signal handler. Still, they already discovered this misbehavior...

Well, you can't really call it that, though. It's was sort of by design (to make task switching faster). But the thing is you have to be ABSOLUTELY SURE that you never raise an FPE when TS is set, and you're NOT a user thread. That's what gets you burned here.

ObDisclaimer: I just finished spending the last 5 months of my undergraduate career fighting tooth and nail with RTAI for my thesis. Before that, I'd spent four years as a QNX consultant. Man, what a difference.

You Ser obviously have absolutly no idea about Real Time Operating Systems. On my PentiumI 166MHz with Linux + RTAI I have max jitter 9usec (110 000/sec), and this is as fast as expensive Real-Time Operating Systems like QNX, or VxWorks can deliver.

RTAI

RTAI Shedulers

RTAI: Real-Time Application Interface

Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec).

Linux with RTAI on 150MHz CPU has no problem with delivering Hard Real-Time with jitter not exceeding 20 usec (It can be much less).

RTAI

RTAI Shedulers

RTAI: Real-Time Application Interface

"For embedded use, Linux must be ported to appropriate processors and modified to work in diskless, resource constrained, and custom hardware environments. Real-time performance capabilities are also often required."

The Linux kernel was never intented to compete with QNX or any other realtime operating system.
Try RTAI. It's a patch to allow hard realtime performance on GNU/Linux systems.

Not necessarily true. I work on research for the university I study at, and the particular branch I work on uses comedi drivers to interface with our pci data acquisition boards. Take a look, it might support what you're using.

Many things people would ordinarily think linux can't do is already, or will one day be possible, so keep looking. A lot of people tend to think you can't do real-time work on Linux, because it's not a real-time kernel "like windows nt", but we do it with a patched RTAI kernel too. My advice is to research what you need, in any operating system. Check out all your options, and choose what's best for you.

Gcc, you jackass.

Beaten by at least both icc and VC++ in speed of generated code and speed of compilation. GCC cannot do precompiled headers. Better than it used to be, yes. (I use and love gcc, but it isn't best-of-breed.)

Glibc, you moron

Hmm. Actually, not sure about this one. Slower on at least some tests, but I've never seen glibc comprehensively benchmarked against competing libcs.

Bash

Not sure, again. Haven't seen any bash vs tcsh/sh benchmarks. Could potentially be faster.

automake

Hmm. Show me a competing system that's slower.

emacs

Um...the competition is what, vi? Emacs is damn well *not* faster.

make

Just ran a quick test -- Solaris make runs about four times as fast as gmake.

tar

Tough to tell. Runs about as fast as Solaris tar. Might be faster.

sed

super sed is faster.

patch

Could be. Haven't seen benchmarks of it.

nethack

Not a GNU project.

cvs

Not a GNU project.

Besides, I said "stunning performance". Linux is significantly faster than the competition, not "neck and neck, and maybe a little bit faster".

who know what it really means

Oh, get off your high horse. If you wanted to have absolute meanings, you should have used Esperanto. The standard use of "hacker" today is "one who breaks into computer systems". There are plenty of archaic uses of lots of English words. Get over it.

You can't stop the evolution of language.